linux-kernel - Re: [PATCH 01/29] Documentation: kvm: introduce "VM plane" concept

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2db90a8a-0cd7-be70-06d2-3475ba391cc7@amd.com>
Date: Mon, 21 Apr 2025 13:43:11 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
 kvm@...r.kernel.org
Cc: roy.hopkins@...e.com, seanjc@...gle.com, ashish.kalra@....com,
 michael.roth@....com, jroedel@...e.de, nsaenz@...zon.com, anelkz@...zon.de,
 James.Bottomley@...senPartnership.com
Subject: Re: [PATCH 01/29] Documentation: kvm: introduce "VM plane" concept

On 4/1/25 11:10, Paolo Bonzini wrote:
> There have been multiple occurrences of processors introducing a virtual
> privilege level concept for guests, where the hypervisor hosts multiple
> copies of a vCPU's register state (or at least of most of it) and provides
> hypercalls or instructions to switch between them.  These include AMD
> VMPLs, Intel TDX partitions, Microsoft Hyper-V VTLs, and ARM CCA planes.
> Include documentation on how the feature will be exposed to userspace,
> based on a draft made between Plumbers and KVM Forum.
> 

> @@ -7162,6 +7262,44 @@ The valid value for 'flags' is:
>    - KVM_NOTIFY_CONTEXT_INVALID -- the VM context is corrupted and not valid
>      in VMCS. It would run into unknown result if resume the target VM.
>  
> +::
> +
> +    /* KVM_EXIT_PLANE_EVENT */
> +    struct {
> +  #define KVM_PLANE_EVENT_INTERRUPT	1
> +      __u16 cause;
> +      __u16 pending_event_planes;
> +      __u16 target;
> +      __u16 padding;
> +      __u32 flags;
> +      __u64 extra;
> +    } plane_event;
> +
> +Inform userspace of an event that affects a different plane than the
> +currently executing one.
> +
> +On a ``KVM_EXIT_PLANE_EVENT`` exit, ``pending_event_planes`` is always
> +set to the set of planes that have a pending interrupt.
> +
> +``cause`` provides the event that caused the exit, and the meaning of
> +``target`` depends on the cause of the exit too.
> +
> +Right now the only defined cause is ``KVM_PLANE_EVENT_INTERRUPT``, i.e.

With the SVSM and VMPL levels, the guest OS will request to run VMPL0 to
run the SVSM and process an SVSM call. When complete, the SVSM will
return to the guest OS by requesting to run the guest VMPL. Do we need
an event for this plane switch that doesn't involve interrupts?

> +an interrupt was received by a plane whose id is set in the
> +``req_exit_planes`` bitmap.  In this case, ``target`` is the AND of
> +``req_exit_planes`` and ``pending_event_planes``.
> +
> +``flags`` and ``extra`` are currently always 0.
> +
> +If userspace wants to switch to the target plane, it should move any
> +shared state from the current plane to ``target``, and then invoke
> +``KVM_RUN`` with ``kvm_run->plane`` set to ``target`` (and
> +``req_exit_planes`` initialized accordingly).  Note that it's also
> +valid to switch planes in response to other userspace exit codes, for
> +example ``KVM_EXIT_X86_WRMSR`` or ``KVM_EXIT_HYPERCALL``.  Immediately
> +after ``KVM_RUN`` is entered, KVM will check ``req_exit_planes`` and
> +trigger a ``KVM_EXIT_PLANE_EVENT`` userspace exit if needed.

I'm not sure I follow this. Won't req_exit_planes have a value no matter
what when running a less privileged plane. How would KVM know to
immediately exit?

Thanks,
Tom

> +