1. 15 Dec, 2020 23 commits
    • 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 7 commits
    • Paolo Bonzini's avatar
      Merge tag 'kvm-s390-next-5.11-1' of... · e8614e5e
      Paolo Bonzini authored
      Merge tag 'kvm-s390-next-5.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD
      
      KVM: s390: Features and Test for 5.11
      
      - memcg accouting for s390 specific parts of kvm and gmap
      - selftest for diag318
      - new kvm_stat for when async_pf falls back to sync
      
      The selftest even triggers a non-critical bug that is unrelated
      to diag318, fix will follow later.
      e8614e5e
    • Paolo Bonzini's avatar
      KVM: x86: reinstate vendor-agnostic check on SPEC_CTRL cpuid bits · 39485ed9
      Paolo Bonzini authored
      Until commit e7c587da ("x86/speculation: Use synthetic bits for
      IBRS/IBPB/STIBP"), KVM was testing both Intel and AMD CPUID bits before
      allowing the guest to write MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD.
      Testing only Intel bits on VMX processors, or only AMD bits on SVM
      processors, fails if the guests are created with the "opposite" vendor
      as the host.
      
      While at it, also tweak the host CPU check to use the vendor-agnostic
      feature bit X86_FEATURE_IBPB, since we only care about the availability
      of the MSR on the host here and not about specific CPUID bits.
      
      Fixes: e7c587da ("x86/speculation: Use synthetic bits for IBRS/IBPB/STIBP")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarDenis V. Lunev <den@openvz.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      39485ed9
    • Cathy Zhang's avatar
      KVM: x86: Expose AVX512_FP16 for supported CPUID · 2224fc9e
      Cathy Zhang authored
      AVX512_FP16 is supported by Intel processors, like Sapphire Rapids.
      It could gain better performance for it's faster compared to FP32
      if the precision or magnitude requirements are met. It's availability
      is indicated by CPUID.(EAX=7,ECX=0):EDX[bit 23].
      
      Expose it in KVM supported CPUID, then guest could make use of it; no
      new registers are used, only new instructions.
      Signed-off-by: default avatarCathy Zhang <cathy.zhang@intel.com>
      Signed-off-by: default avatarKyung Min Park <kyung.min.park@intel.com>
      Acked-by: default avatarDave Hansen <dave.hansen@intel.com>
      Reviewed-by: default avatarTony Luck <tony.luck@intel.com>
      Message-Id: <20201208033441.28207-3-kyung.min.park@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      2224fc9e
    • Kyung Min Park's avatar
      x86: Enumerate AVX512 FP16 CPUID feature flag · e1b35da5
      Kyung Min Park authored
      Enumerate AVX512 Half-precision floating point (FP16) CPUID feature
      flag. Compared with using FP32, using FP16 cut the number of bits
      required for storage in half, reducing the exponent from 8 bits to 5,
      and the mantissa from 23 bits to 10. Using FP16 also enables developers
      to train and run inference on deep learning models fast when all
      precision or magnitude (FP32) is not needed.
      
      A processor supports AVX512 FP16 if CPUID.(EAX=7,ECX=0):EDX[bit 23]
      is present. The AVX512 FP16 requires AVX512BW feature be implemented
      since the instructions for manipulating 32bit masks are associated with
      AVX512BW.
      
      The only in-kernel usage of this is kvm passthrough. The CPU feature
      flag is shown as "avx512_fp16" in /proc/cpuinfo.
      Signed-off-by: default avatarKyung Min Park <kyung.min.park@intel.com>
      Acked-by: default avatarDave Hansen <dave.hansen@intel.com>
      Reviewed-by: default avatarTony Luck <tony.luck@intel.com>
      Message-Id: <20201208033441.28207-2-kyung.min.park@intel.com>
      Acked-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      e1b35da5
    • Aaron Lewis's avatar
      selftests: kvm: Merge user_msr_test into userspace_msr_exit_test · fb636053
      Aaron Lewis authored
      Both user_msr_test and userspace_msr_exit_test tests the functionality
      of kvm_msr_filter.  Instead of testing this feature in two tests, merge
      them together, so there is only one test for this feature.
      Signed-off-by: default avatarAaron Lewis <aaronlewis@google.com>
      Message-Id: <20201204172530.2958493-1-aaronlewis@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      fb636053
    • Aaron Lewis's avatar
      selftests: kvm: Test MSR exiting to userspace · 3cea1891
      Aaron Lewis authored
      Add a selftest to test that when the ioctl KVM_X86_SET_MSR_FILTER is
      called with an MSR list, those MSRs exit to userspace.
      
      This test uses 3 MSRs to test this:
        1. MSR_IA32_XSS, an MSR the kernel knows about.
        2. MSR_IA32_FLUSH_CMD, an MSR the kernel does not know about.
        3. MSR_NON_EXISTENT, an MSR invented in this test for the purposes of
           passing a fake MSR from the guest to userspace.  KVM just acts as a
           pass through.
      
      Userspace is also able to inject a #GP.  This is demonstrated when
      MSR_IA32_XSS and MSR_IA32_FLUSH_CMD are misused in the test.  When this
      happens a #GP is initiated in userspace to be thrown in the guest which is
      handled gracefully by the exception handling framework introduced earlier
      in this series.
      
      Tests for the generic instruction emulator were also added.  For this to
      work the module parameter kvm.force_emulation_prefix=1 has to be enabled.
      If it isn't enabled the tests will be skipped.
      
      A test was also added to ensure the MSR permission bitmap is being set
      correctly by executing reads and writes of MSR_FS_BASE and MSR_GS_BASE
      in the guest while alternating which MSR userspace should intercept.  If
      the permission bitmap is being set correctly only one of the MSRs should
      be coming through at a time, and the guest should be able to read and
      write the other one directly.
      Signed-off-by: default avatarAaron Lewis <aaronlewis@google.com>
      Reviewed-by: default avatarAlexander Graf <graf@amazon.com>
      Message-Id: <20201012194716.3950330-5-aaronlewis@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      3cea1891
    • Uros Bizjak's avatar
      KVM/VMX: Use TEST %REG,%REG instead of CMP $0,%REG in vmenter.S · 6c44221b
      Uros Bizjak authored
      Saves one byte in __vmx_vcpu_run for the same functionality.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Sean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarUros Bizjak <ubizjak@gmail.com>
      Message-Id: <20201029140457.126965-1-ubizjak@gmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      6c44221b
  4. 10 Dec, 2020 3 commits