lkml.org 
[lkml]   [2021]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v5.1 27/34] KVM: SVM: Add support for booting APs in an SEV-ES guest
    From
    Date
    On 1/7/21 12:13 PM, Paolo Bonzini wrote:
    > On 04/01/21 21:20, Tom Lendacky wrote:
    >> From: Tom Lendacky <thomas.lendacky@amd.com>
    >>
    >> Typically under KVM, an AP is booted using the INIT-SIPI-SIPI sequence,
    >> where the guest vCPU register state is updated and then the vCPU is VMRUN
    >> to begin execution of the AP. For an SEV-ES guest, this won't work because
    >> the guest register state is encrypted.
    >>
    >> Following the GHCB specification, the hypervisor must not alter the guest
    >> register state, so KVM must track an AP/vCPU boot. Should the guest want
    >> to park the AP, it must use the AP Reset Hold exit event in place of, for
    >> example, a HLT loop.
    >>
    >> First AP boot (first INIT-SIPI-SIPI sequence):
    >>    Execute the AP (vCPU) as it was initialized and measured by the SEV-ES
    >>    support. It is up to the guest to transfer control of the AP to the
    >>    proper location.
    >>
    >> Subsequent AP boot:
    >>    KVM will expect to receive an AP Reset Hold exit event indicating that
    >>    the vCPU is being parked and will require an INIT-SIPI-SIPI sequence to
    >>    awaken it. When the AP Reset Hold exit event is received, KVM will place
    >>    the vCPU into a simulated HLT mode. Upon receiving the INIT-SIPI-SIPI
    >>    sequence, KVM will make the vCPU runnable. It is again up to the guest
    >>    to then transfer control of the AP to the proper location.
    >>
    >>    To differentiate between an actual HLT and an AP Reset Hold, a new MP
    >>    state is introduced, KVM_MP_STATE_AP_RESET_HOLD, which the vCPU is
    >>    placed in upon receiving the AP Reset Hold exit event. Additionally, to
    >>    communicate the AP Reset Hold exit event up to userspace (if needed), a
    >>    new exit reason is introduced, KVM_EXIT_AP_RESET_HOLD.
    >>
    >> A new x86 ops function is introduced, vcpu_deliver_sipi_vector, in order
    >> to accomplish AP booting. For VMX, vcpu_deliver_sipi_vector is set to the
    >> original SIPI delivery function, kvm_vcpu_deliver_sipi_vector(). SVM adds
    >> a new function that, for non SEV-ES guests, invokes the original SIPI
    >> delivery function, kvm_vcpu_deliver_sipi_vector(), but for SEV-ES guests,
    >> implements the logic above.
    >>
    >> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    >
    > Queued, thanks.

    Thanks, Paolo!

    Tom

    >
    > Paolo
    >

    \
     
     \ /
      Last update: 2021-01-07 20:55    [W:4.434 / U:0.248 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site