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:

quoted

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.

quoted

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.

quoted

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/ (local)

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