Thread (73 messages) 73 messages, 6 authors, 22d ago

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

From: Paolo Bonzini <pbonzini@redhat.com>
Date: 2026-06-08 17:59:18
Also in: kvm, kvm-riscv, kvmarm, linux-mips, lkml, loongarch

On Mon, Jun 8, 2026 at 7:52 PM Jörg Rödel [off-list ref] wrote:
On Mon, Jun 08, 2026 at 06:47:54PM +0200, Paolo Bonzini wrote:
quoted
On 6/8/26 16:42, Jörg Rödel wrote:
quoted
The algorithm is to always run the lowest runnable plane. Plane
switches are done by stopping the current plane and setting another
runnable.
This was left arbitrary in my version because for example Hyper-V VTLs use
highest-runnable instead.  It also made pure userspace scheduling possible,
though that may not be very important in the grand scheme of things.
IIRC what Hyper-V does is always the run the highest-privileged runnable level,
no?  Maybe in their numbering level 0 has the least privileges?
Yes, exactly.
Anyway, I am happy to make changes here, also based on input from the VSM side.
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.
quoted
Did you drop it because it didn't work, or just for simplicity?
The user-space scheduling worked, my 6.17 planes implementation used it. But
there are some problems with it going forward, because TDX Partitioning (and
likely ARM CCA Planes as well) do not allow arbitrary switches forced by the
hypervisor. All they allow is a forced switch to the highest privileged plane,
the SVSM on SNP will force the same constraints by making lower-privilege VMSAs
not-runnable when it executes.
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.

Paolo
So exposing an interface for user-space to chose which plane to run does seem
to gain some weird, platform dependent semantics going forward. TDX and CCA
also require in-kernel switching as they can switch planes without a VMEXIT, so
I decided to have it from the start.


-Joerg
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help