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

[Jörg Rödel]

Hi James,

On Fri, Jul 17, 2026 at 10:35:10AM -0400, James Bottomley wrote:
> So this all depends how the planes are started.  If you're starting
> them from an IGVM file that loads the most privileged code and then
> runs the guest in a different plane, absolutely, it can work as you
> describe.  However, the common use case for serviceable security
> enclaves is you start the kernel first (necessarily in plane 0) and
> then bring up the enclaves later which means the planes > 0 are
> technically higher privilege since they're running hidden security
> code.  HOWEVER, there's no reason at all to trust a security enclave
> that's doing something like guarding private keys to be able to poke
> anywhere it wants in the guest ... that's a security breach waiting to
> happen, so it would really be better if the model were not
> hierarchical, but more akin to the ability to seal planes off from each
> other, so the kernel can start the enclave, which would then set itself
> and the communication area up, but then the plane 0 kernel would remove
> access to most memory from the enclave.
> 
> In this sealing model, there's no absolute privilege levels; each plane
> would decide what the other planes can see of its memory space and, on
> security grounds, we'd likely configure the enclaves to have the least
> possible privilege.
> 
> Now, Windows applications expect VSM to be strictly hierarchical in
> terms of privilege, but if we create a sealing primitive as described
> above, we can get it to build the strict VSM privilege hierarchy in the
> hyper-v driver.

I mostly agree with this and have to say that my statement in the cover letter
about plane hierarchies was a bit broad.

The main assumption this patch-set makes about plane 0 is that it is the plane
which does the IRQ scheduling. Say a VM has Plane 0,1, and 2. A VCPU runs plane
2 and KVM wants to inject an IRQ into plane 1 of that VCPU. Now KVM needs the
VCPU to decide whether it wants to run plane 1 to handle the IRQ or continue
with plane 2 because it currently has higher-priority work to do.

This decision is made on plane 0 in this patch-set, which it needs to be for
VMPLs. Does VSM have a similar concept for IRQ scheduling between VTLs or will
the hypervisor take care to run a VTL when it has IRQs?


-Joerg