1. 15 Dec, 2020 28 commits
    • Tom Lendacky's avatar
      KVM: SVM: Provide support for SEV-ES vCPU loading · 86137773
      Tom Lendacky authored
      An SEV-ES vCPU requires additional VMCB vCPU load/put requirements. SEV-ES
      hardware will restore certain registers on VMEXIT, but not save them on
      VMRUN (see Table B-3 and Table B-4 of the AMD64 APM Volume 2), so make the
      following changes:
      
      General vCPU load changes:
        - During vCPU loading, perform a VMSAVE to the per-CPU SVM save area and
          save the current values of XCR0, XSS and PKRU to the per-CPU SVM save
          area as these registers will be restored on VMEXIT.
      
      General vCPU put changes:
        - Do not attempt to restore registers that SEV-ES hardware has already
          restored on VMEXIT.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <019390e9cb5e93cd73014fa5a040c17d42588733.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      86137773
    • Tom Lendacky's avatar
      KVM: SVM: Provide support for SEV-ES vCPU creation/loading · 376c6d28
      Tom Lendacky authored
      An SEV-ES vCPU requires additional VMCB initialization requirements for
      vCPU creation and vCPU load/put requirements. This includes:
      
      General VMCB initialization changes:
        - Set a VMCB control bit to enable SEV-ES support on the vCPU.
        - Set the VMCB encrypted VM save area address.
        - CRx registers are part of the encrypted register state and cannot be
          updated. Remove the CRx register read and write intercepts and replace
          them with CRx register write traps to track the CRx register values.
        - Certain MSR values are part of the encrypted register state and cannot
          be updated. Remove certain MSR intercepts (EFER, CR_PAT, etc.).
        - Remove the #GP intercept (no support for "enable_vmware_backdoor").
        - Remove the XSETBV intercept since the hypervisor cannot modify XCR0.
      
      General vCPU creation changes:
        - Set the initial GHCB gpa value as per the GHCB specification.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <3a8aef366416eddd5556dfa3fdc212aafa1ad0a2.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      376c6d28
    • Tom Lendacky's avatar
      KVM: SVM: Update ASID allocation to support SEV-ES guests · 80675b3a
      Tom Lendacky authored
      SEV and SEV-ES guests each have dedicated ASID ranges. Update the ASID
      allocation routine to return an ASID in the respective range.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <d7aed505e31e3954268b2015bb60a1486269c780.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      80675b3a
    • Tom Lendacky's avatar
      KVM: SVM: Set the encryption mask for the SVM host save area · 85ca8be9
      Tom Lendacky authored
      The SVM host save area is used to restore some host state on VMEXIT of an
      SEV-ES guest. After allocating the save area, clear it and add the
      encryption mask to the SVM host save area physical address that is
      programmed into the VM_HSAVE_PA MSR.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <b77aa28af6d7f1a0cb545959e08d6dc75e0c3cba.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      85ca8be9
    • Tom Lendacky's avatar
      KVM: SVM: Add NMI support for an SEV-ES guest · 4444dfe4
      Tom Lendacky authored
      The GHCB specification defines how NMIs are to be handled for an SEV-ES
      guest. To detect the completion of an NMI the hypervisor must not
      intercept the IRET instruction (because a #VC while running the NMI will
      issue an IRET) and, instead, must receive an NMI Complete exit event from
      the guest.
      
      Update the KVM support for detecting the completion of NMIs in the guest
      to follow the GHCB specification. When an SEV-ES guest is active, the
      IRET instruction will no longer be intercepted. Now, when the NMI Complete
      exit event is received, the iret_interception() function will be called
      to simulate the completion of the NMI.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <5ea3dd69b8d4396cefdc9048ebc1ab7caa70a847.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      4444dfe4
    • Tom Lendacky's avatar
      KVM: SVM: Guest FPU state save/restore not needed for SEV-ES guest · ed02b213
      Tom Lendacky authored
      The guest FPU state is automatically restored on VMRUN and saved on VMEXIT
      by the hardware, so there is no reason to do this in KVM. Eliminate the
      allocation of the guest_fpu save area and key off that to skip operations
      related to the guest FPU state.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <173e429b4d0d962c6a443c4553ffdaf31b7665a4.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      ed02b213
    • Tom Lendacky's avatar
      KVM: SVM: Do not report support for SMM for an SEV-ES guest · 5719455f
      Tom Lendacky authored
      SEV-ES guests do not currently support SMM. Update the has_emulated_msr()
      kvm_x86_ops function to take a struct kvm parameter so that the capability
      can be reported at a VM level.
      
      Since this op is also called during KVM initialization and before a struct
      kvm instance is available, comments will be added to each implementation
      of has_emulated_msr() to indicate the kvm parameter can be null.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <75de5138e33b945d2fb17f81ae507bda381808e3.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      5719455f
    • Tom Lendacky's avatar
      KVM: x86: Update __get_sregs() / __set_sregs() to support SEV-ES · 5265713a
      Tom Lendacky authored
      Since many of the registers used by the SEV-ES are encrypted and cannot
      be read or written, adjust the __get_sregs() / __set_sregs() to take into
      account whether the VMSA/guest state is encrypted.
      
      For __get_sregs(), return the actual value that is in use by the guest
      for all registers being tracked using the write trap support.
      
      For __set_sregs(), skip setting of all guest registers values.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <23051868db76400a9b07a2020525483a1e62dbcf.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      5265713a
    • Tom Lendacky's avatar
      KVM: SVM: Add support for CR8 write traps for an SEV-ES guest · d1949b93
      Tom Lendacky authored
      For SEV-ES guests, the interception of control register write access
      is not recommended. Control register interception occurs prior to the
      control register being modified and the hypervisor is unable to modify
      the control register itself because the register is located in the
      encrypted register state.
      
      SEV-ES guests introduce new control register write traps. These traps
      provide intercept support of a control register write after the control
      register has been modified. The new control register value is provided in
      the VMCB EXITINFO1 field, allowing the hypervisor to track the setting
      of the guest control registers.
      
      Add support to track the value of the guest CR8 register using the control
      register write trap so that the hypervisor understands the guest operating
      mode.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <5a01033f4c8b3106ca9374b7cadf8e33da852df1.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      d1949b93
    • Tom Lendacky's avatar
      KVM: SVM: Add support for CR4 write traps for an SEV-ES guest · 5b51cb13
      Tom Lendacky authored
      For SEV-ES guests, the interception of control register write access
      is not recommended. Control register interception occurs prior to the
      control register being modified and the hypervisor is unable to modify
      the control register itself because the register is located in the
      encrypted register state.
      
      SEV-ES guests introduce new control register write traps. These traps
      provide intercept support of a control register write after the control
      register has been modified. The new control register value is provided in
      the VMCB EXITINFO1 field, allowing the hypervisor to track the setting
      of the guest control registers.
      
      Add support to track the value of the guest CR4 register using the control
      register write trap so that the hypervisor understands the guest operating
      mode.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <c3880bf2db8693aa26f648528fbc6e967ab46e25.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      5b51cb13
    • Tom Lendacky's avatar
      KVM: SVM: Add support for CR0 write traps for an SEV-ES guest · f27ad38a
      Tom Lendacky authored
      For SEV-ES guests, the interception of control register write access
      is not recommended. Control register interception occurs prior to the
      control register being modified and the hypervisor is unable to modify
      the control register itself because the register is located in the
      encrypted register state.
      
      SEV-ES support introduces new control register write traps. These traps
      provide intercept support of a control register write after the control
      register has been modified. The new control register value is provided in
      the VMCB EXITINFO1 field, allowing the hypervisor to track the setting
      of the guest control registers.
      
      Add support to track the value of the guest CR0 register using the control
      register write trap so that the hypervisor understands the guest operating
      mode.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <182c9baf99df7e40ad9617ff90b84542705ef0d7.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      f27ad38a
    • Tom Lendacky's avatar
      KVM: SVM: Add support for EFER write traps for an SEV-ES guest · 2985afbc
      Tom Lendacky authored
      For SEV-ES guests, the interception of EFER write access is not
      recommended. EFER interception occurs prior to EFER being modified and
      the hypervisor is unable to modify EFER itself because the register is
      located in the encrypted register state.
      
      SEV-ES support introduces a new EFER write trap. This trap provides
      intercept support of an EFER write after it has been modified. The new
      EFER value is provided in the VMCB EXITINFO1 field, allowing the
      hypervisor to track the setting of the guest EFER.
      
      Add support to track the value of the guest EFER value using the EFER
      write trap so that the hypervisor understands the guest operating mode.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <8993149352a3a87cd0625b3b61bfd31ab28977e1.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      2985afbc
    • Tom Lendacky's avatar
      KVM: SVM: Support string IO operations for an SEV-ES guest · 7ed9abfe
      Tom Lendacky authored
      For an SEV-ES guest, string-based port IO is performed to a shared
      (un-encrypted) page so that both the hypervisor and guest can read or
      write to it and each see the contents.
      
      For string-based port IO operations, invoke SEV-ES specific routines that
      can complete the operation using common KVM port IO support.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <9d61daf0ffda496703717218f415cdc8fd487100.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      7ed9abfe
    • Tom Lendacky's avatar
      KVM: SVM: Support MMIO for an SEV-ES guest · 8f423a80
      Tom Lendacky authored
      For an SEV-ES guest, MMIO is performed to a shared (un-encrypted) page
      so that both the hypervisor and guest can read or write to it and each
      see the contents.
      
      The GHCB specification provides software-defined VMGEXIT exit codes to
      indicate a request for an MMIO read or an MMIO write. Add support to
      recognize the MMIO requests and invoke SEV-ES specific routines that
      can complete the MMIO operation. These routines use common KVM support
      to complete the MMIO operation.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <af8de55127d5bcc3253d9b6084a0144c12307d4d.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      8f423a80
    • Tom Lendacky's avatar
      KVM: SVM: Create trace events for VMGEXIT MSR protocol processing · 59e38b58
      Tom Lendacky authored
      Add trace events for entry to and exit from VMGEXIT MSR protocol
      processing. The vCPU will be common for the trace events. The MSR
      protocol processing is guided by the GHCB GPA in the VMCB, so the GHCB
      GPA will represent the input and output values for the entry and exit
      events, respectively. Additionally, the exit event will contain the
      return code for the event.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <c5b3b440c3e0db43ff2fc02813faa94fa54896b0.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      59e38b58
    • Tom Lendacky's avatar
      KVM: SVM: Create trace events for VMGEXIT processing · d523ab6b
      Tom Lendacky authored
      Add trace events for entry to and exit from VMGEXIT processing. The vCPU
      id and the exit reason will be common for the trace events. The exit info
      fields will represent the input and output values for the entry and exit
      events, respectively.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <25357dca49a38372e8f483753fb0c1c2a70a6898.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      d523ab6b
    • Tom Lendacky's avatar
      KVM: SVM: Add support for SEV-ES GHCB MSR protocol function 0x100 · e1d71116
      Tom Lendacky authored
      The GHCB specification defines a GHCB MSR protocol using the lower
      12-bits of the GHCB MSR (in the hypervisor this corresponds to the
      GHCB GPA field in the VMCB).
      
      Function 0x100 is a request for termination of the guest. The guest has
      encountered some situation for which it has requested to be terminated.
      The GHCB MSR value contains the reason for the request.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <f3a1f7850c75b6ea4101e15bbb4a3af1a203f1dc.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      e1d71116
    • Tom Lendacky's avatar
      KVM: SVM: Add support for SEV-ES GHCB MSR protocol function 0x004 · d3694667
      Tom Lendacky authored
      The GHCB specification defines a GHCB MSR protocol using the lower
      12-bits of the GHCB MSR (in the hypervisor this corresponds to the
      GHCB GPA field in the VMCB).
      
      Function 0x004 is a request for CPUID information. Only a single CPUID
      result register can be sent per invocation, so the protocol defines the
      register that is requested. The GHCB MSR value is set to the CPUID
      register value as per the specification via the VMCB GHCB GPA field.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <fd7ee347d3936e484c06e9001e340bf6387092cd.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      d3694667
    • Tom Lendacky's avatar
      KVM: SVM: Add support for SEV-ES GHCB MSR protocol function 0x002 · 1edc1459
      Tom Lendacky authored
      The GHCB specification defines a GHCB MSR protocol using the lower
      12-bits of the GHCB MSR (in the hypervisor this corresponds to the
      GHCB GPA field in the VMCB).
      
      Function 0x002 is a request to set the GHCB MSR value to the SEV INFO as
      per the specification via the VMCB GHCB GPA field.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <c23c163a505290a0d1b9efc4659b838c8c902cbc.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      1edc1459
    • Tom Lendacky's avatar
      KVM: SVM: Add initial support for a VMGEXIT VMEXIT · 291bd20d
      Tom Lendacky authored
      SEV-ES adds a new VMEXIT reason code, VMGEXIT. Initial support for a
      VMGEXIT includes mapping the GHCB based on the guest GPA, which is
      obtained from a new VMCB field, and then validating the required inputs
      for the VMGEXIT exit reason.
      
      Since many of the VMGEXIT exit reasons correspond to existing VMEXIT
      reasons, the information from the GHCB is copied into the VMCB control
      exit code areas and KVM register areas. The standard exit handlers are
      invoked, similar to standard VMEXIT processing. Before restarting the
      vCPU, the GHCB is updated with any registers that have been updated by
      the hypervisor.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <c6a4ed4294a369bd75c44d03bd7ce0f0c3840e50.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      291bd20d
    • Tom Lendacky's avatar
      KVM: SVM: Prepare for SEV-ES exit handling in the sev.c file · e9093fd4
      Tom Lendacky authored
      This is a pre-patch to consolidate some exit handling code into callable
      functions. Follow-on patches for SEV-ES exit handling will then be able
      to use them from the sev.c file.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <5b8b0ffca8137f3e1e257f83df9f5c881c8a96a3.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      e9093fd4
    • Tom Lendacky's avatar
      KVM: SVM: Cannot re-initialize the VMCB after shutdown with SEV-ES · 8164a5ff
      Tom Lendacky authored
      When a SHUTDOWN VMEXIT is encountered, normally the VMCB is re-initialized
      so that the guest can be re-launched. But when a guest is running as an
      SEV-ES guest, the VMSA cannot be re-initialized because it has been
      encrypted. For now, just return -EINVAL to prevent a possible attempt at
      a guest reset.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <aa6506000f6f3a574de8dbcdab0707df844cb00c.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      8164a5ff
    • Tom Lendacky's avatar
      KVM: SVM: Do not allow instruction emulation under SEV-ES · bc624d9f
      Tom Lendacky authored
      When a guest is running as an SEV-ES guest, it is not possible to emulate
      instructions. Add support to prevent instruction emulation.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <f6355ea3024fda0a3eb5eb99c6b62dca10d792bd.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      bc624d9f
    • Tom Lendacky's avatar
      KVM: SVM: Prevent debugging under SEV-ES · 8d4846b9
      Tom Lendacky authored
      Since the guest register state of an SEV-ES guest is encrypted, debugging
      is not supported. Update the code to prevent guest debugging when the
      guest has protected state.
      
      Additionally, an SEV-ES guest must only and always intercept DR7 reads and
      writes. Update set_dr_intercepts() and clr_dr_intercepts() to account for
      this.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <8db966fa2f9803d6454ce773863025d0e2e7f3cc.1607620209.git.thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      8d4846b9
    • Tom Lendacky's avatar
      KVM: SVM: Add required changes to support intercepts under SEV-ES · f1c6366e
      Tom Lendacky authored
      When a guest is running under SEV-ES, the hypervisor cannot access the
      guest register state. There are numerous places in the KVM code where
      certain registers are accessed that are not allowed to be accessed (e.g.
      RIP, CR0, etc). Add checks to prevent register accesses and add intercept
      update support at various points within the KVM code.
      
      Also, when handling a VMGEXIT, exceptions are passed back through the
      GHCB. Since the RDMSR/WRMSR intercepts (may) inject a #GP on error,
      update the SVM intercepts to handle this for SEV-ES guests.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      [Redo MSR part using the .complete_emulated_msr callback. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      f1c6366e
    • Paolo Bonzini's avatar
      KVM: x86: introduce complete_emulated_msr callback · f9a4d621
      Paolo Bonzini authored
      This will be used by SEV-ES to inject MSR failure via the GHCB.
      Reviewed-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      f9a4d621
    • Paolo Bonzini's avatar
      KVM: x86: use kvm_complete_insn_gp in emulating RDMSR/WRMSR · 8b474427
      Paolo Bonzini authored
      Simplify the four functions that handle {kernel,user} {rd,wr}msr, there
      is still some repetition between the two instances of rdmsr but the
      whole business of calling kvm_inject_gp and kvm_skip_emulated_instruction
      can be unified nicely.
      
      Because complete_emulated_wrmsr now becomes essentially a call to
      kvm_complete_insn_gp, remove complete_emulated_msr.
      Reviewed-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      8b474427
    • Paolo Bonzini's avatar
      KVM: x86: remove bogus #GP injection · 9caec4bf
      Paolo Bonzini authored
      There is no need to inject a #GP from kvm_mtrr_set_msr, kvm_emulate_wrmsr will
      handle it.
      Reviewed-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      9caec4bf
  2. 14 Dec, 2020 7 commits
  3. 12 Dec, 2020 5 commits