On Mon, Jun 08, 2026 at 07:58:43PM +0200, Paolo Bonzini wrote: > Related to this, let me know if you want me to pick up again the > common part, especially with Sashiko being hard at work on it.
Yeah, that might be good, let me think a bit about it and discuss in tomorrows PUCK call. > 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. 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. 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? When VSM switches to VTL2 first, then planes could just use a marker for the highest-privilege plane (which can be non-zero). In the other case the solution is likely to make the direction in which the vcpu->common->vcpus[] array is traversed configurable. -Joerg
