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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Fri, 2026-07-17 at 13:48 +0000, Saenz Julienne, Nicolas wrote:
> Hi Joerg, I'm a bit late to the discussion hope it helps nonetheless,
> 
> On Tue Jun 9, 2026 at 2:37 PM CEST, Jörg Rödel wrote:
> > CAUTION: This email originated from outside of the organization. Do
> > not click links or open attachments unless you can confirm the
> > sender and know the content is safe.
> > 
> > > The idea of the userspace scheduling was that you're not forced
> > > to use it - the kernel can always choose to override it if it's
> > > using an accelerated implementation of planes (and of plane
> > > switching). But it also leaves some leeway to different
> > > accelerated implementations, each of which can pick their own
> > > algorithm.
> > > 
> > > Conceptually I'd rather keep the possibility of userspace
> > > scheduling. But maybe it doesn't add much.
> > 
> > My preference is to keep plane scheduling at one place (in the
> > kernel) to keep it simple. But if you see a need for user-mode to
> > interact there as well (only really works for VSM), then I can add
> > it.
> 
> The responsibility split we had in mind when we built a VSM emulation
> prototype [1] was to keep all VTL policing in user-space. This
> includes VTL switching, Cross VTL IPIs, Intercepts (Memory, MSRs,
> Insns, CPU regs), VTL aware SMP bring-up, etc. Even with KVM Planes
> in place, my thinking was to keep it as such. While all this could be
> implemented in the kernel, in practical terms, I think it'll be
> easier to get VSM support upstream the more we move the
> implementation into user-space.

I looked at the kernel bit.  The vsm/dev branch contains 72 patches
over 6.12 which is quite a lot ...

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.

> More importantly, I think the area of Virtualization Based Security
> would benefit from a versatile Planes implementation. Forcing
> specific plane switching semantics might prevent the introduction VSM
> alternatives or extensions. Heki and lVBS come to mind here.
> 
> > I read a bit more about VSM and it seems their prioritization of
> > VTLs is a bit more complicated. VTL0 has the least privileges but
> > boots first, then sets up VTL1. But VTL1 is only higher-privileged
> > once it is locked by VTL0. Another way to look at it is that VTL0
> > de-prioritizes itself.
> > 
> > The patches here are built around the assumption that plane0 is the
> > highest privileged one and is always runnable. Running any lower-
> > privilege plane must be triggered by the guest. This is clearly not
> > sufficient for VSM, the question is how to solve that.
> 
> I'd suggest inverting the priorities, with higher planes being more
> privileged. It'll make introducing higher privilege levels easier.
> This is especially useful with VSM, where it's not possible to know
> how many levels will be enabled before launching the VM.

I already addressed this in a different reply

https://lore.kernel.org/kvm/570f82e8b8bc968a31a4ba859145f6c324e41247.camel@HansenPartnership.com/

but basically I think hierarchical privilege will be too limiting.  I
agree we need to have enough primitives to bring up hierarchical VSMs
if that's what the guest wants (Windows definitely will) but this
shouldn't be the only thing we can arrange planes as.  The mutually
distrusting model has a lot going for it in terms of security
properties.

Regards,

James