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.

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.

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.

The answer depends on how IRQ delivery affects VTL scheduling in VSM. If a
VM has VTL0 (currently running), VTL1, and VTL2 (highest privilege), and an IRQ
becomed pending for VTL1, does Hyper-V schedule VTL1 directly or does it switch
to VTL2 (highest privilege) first to let it schedule VTL1?

The hypervisor can trigger a 0->1 switch directly with "interrupt" as
the entry reason.

Nicolas

[1] See the repositories and branches referred to here:
    https://github.com/vianpl/qemu-kvm-dev-env