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

quoted

quoted

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 ...

Yes, and on top punting most of VSM's implementation into user-space,
it's incomplete.

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

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.

Nicolas

[1] https://lore.kernel.org/kvm/20260716181456.402786-1-pbonzini@redhat.com/ (local)