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

[Saenz Julienne, Nicolas]

On Fri Jul 17, 2026 at 5:56 PM CEST, James Bottomley wrote:
>> > > 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@xxxxxxxxxx/