Re: [PATCH 35/60] kvm: Add VCPU plane-scheduling state and helpers

On Fri, 2026-07-17 at 17:33 +0000, Saenz Julienne, Nicolas wrote:

On Fri Jul 17, 2026 at 5:56 PM CEST, James Bottomley wrote:

[...]

quoted

However, from a quick skim, the main thing is that you used
multiple KVM structures to manage the planes which means each plane
naturally gets its own address space.  In the current planes model
so far there's only one address space (or two if you have SMM). 
SNP doesn't need anything above this because the VMPL protection is
naturally managed inside the guest (so not really visible to the
host) but a VTL implementation will.  So I think the big question
becomes how are we going to achieve address space separation for
planes?  It's tempting to say simply one address space per plane
and make SMM its own plane with different switching but it's an
awful lot of overhead especially as most VMs won't even use planes,
so it looks like there has to be a more opportunistic model for
planes address spaces.

While adress spaces are per VM, KVM memory attributes are per plane.
It should be enough to implement VSM's memory protections as well as
the enclaves design you mentioned. We have a series in-flux
implementing RWX memory attributes [1].

We might get this to work if we're careful.  It just means when two
planes agree on chunks of memory to seal and share it's helpful if
they're guest physically contiguous.

The only thing that's not feasible "naturally" with attributes are
memory overlays or any situation where we'd need to change the
backing memory of a guest physical address range just for a single
plane. From a VSM perspective it's fine. The only use-case from a VSM
perspective are memory overlays (and those, from my experience, are
useless). I don't know that's a deal-breaker the mutually distrusting
model.

I don't think so.  I don't see it as a problem that the guest physical
memory map looks the same to every plane even if the page protections
might be different.  This is slightly different from SMM where the smm
memblock is missing from the guest map, so it might be the case that we
don't need different address spaces to cope with this.

Regards,

James