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

[James Bottomley]

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:
[...]
> > 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