1. 23 10月, 2020 1 次提交
  2. 22 10月, 2020 6 次提交
  3. 28 9月, 2020 15 次提交
    • P
      KVM: x86: rename KVM_REQ_GET_VMCS12_PAGES · 729c15c2
      Paolo Bonzini 提交于
      We are going to use it for SVM too, so use a more generic name.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      729c15c2
    • A
      KVM: x86: Introduce MSR filtering · 1a155254
      Alexander Graf 提交于
      It's not desireable to have all MSRs always handled by KVM kernel space. Some
      MSRs would be useful to handle in user space to either emulate behavior (like
      uCode updates) or differentiate whether they are valid based on the CPU model.
      
      To allow user space to specify which MSRs it wants to see handled by KVM,
      this patch introduces a new ioctl to push filter rules with bitmaps into
      KVM. Based on these bitmaps, KVM can then decide whether to reject MSR access.
      With the addition of KVM_CAP_X86_USER_SPACE_MSR it can also deflect the
      denied MSR events to user space to operate on.
      
      If no filter is populated, MSR handling stays identical to before.
      Signed-off-by: NAlexander Graf <graf@amazon.com>
      
      Message-Id: <20200925143422.21718-8-graf@amazon.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      1a155254
    • A
      KVM: x86: Add infrastructure for MSR filtering · 51de8151
      Alexander Graf 提交于
      In the following commits we will add pieces of MSR filtering.
      To ensure that code compiles even with the feature half-merged, let's add
      a few stubs and struct definitions before the real patches start.
      Signed-off-by: NAlexander Graf <graf@amazon.com>
      
      Message-Id: <20200925143422.21718-4-graf@amazon.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      51de8151
    • A
      KVM: x86: Allow deflecting unknown MSR accesses to user space · 1ae09954
      Alexander Graf 提交于
      MSRs are weird. Some of them are normal control registers, such as EFER.
      Some however are registers that really are model specific, not very
      interesting to virtualization workloads, and not performance critical.
      Others again are really just windows into package configuration.
      
      Out of these MSRs, only the first category is necessary to implement in
      kernel space. Rarely accessed MSRs, MSRs that should be fine tunes against
      certain CPU models and MSRs that contain information on the package level
      are much better suited for user space to process. However, over time we have
      accumulated a lot of MSRs that are not the first category, but still handled
      by in-kernel KVM code.
      
      This patch adds a generic interface to handle WRMSR and RDMSR from user
      space. With this, any future MSR that is part of the latter categories can
      be handled in user space.
      
      Furthermore, it allows us to replace the existing "ignore_msrs" logic with
      something that applies per-VM rather than on the full system. That way you
      can run productive VMs in parallel to experimental ones where you don't care
      about proper MSR handling.
      Signed-off-by: NAlexander Graf <graf@amazon.com>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      
      Message-Id: <20200925143422.21718-3-graf@amazon.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      1ae09954
    • S
      KVM: x86: Rename "shared_msrs" to "user_return_msrs" · 7e34fbd0
      Sean Christopherson 提交于
      Rename the "shared_msrs" mechanism, which is used to defer restoring
      MSRs that are only consumed when running in userspace, to a more banal
      but less likely to be confusing "user_return_msrs".
      
      The "shared" nomenclature is confusing as it's not obvious who is
      sharing what, e.g. reasonable interpretations are that the guest value
      is shared by vCPUs in a VM, or that the MSR value is shared/common to
      guest and host, both of which are wrong.
      
      "shared" is also misleading as the MSR value (in hardware) is not
      guaranteed to be shared/reused between VMs (if that's indeed the correct
      interpretation of the name), as the ability to share values between VMs
      is simply a side effect (albiet a very nice side effect) of deferring
      restoration of the host value until returning from userspace.
      
      "user_return" avoids the above confusion by describing the mechanism
      itself instead of its effects.
      Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Message-Id: <20200923180409.32255-2-sean.j.christopherson@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      7e34fbd0
    • S
      KVM: x86: Add intr/vectoring info and error code to kvm_exit tracepoint · 235ba74f
      Sean Christopherson 提交于
      Extend the kvm_exit tracepoint to align it with kvm_nested_vmexit in
      terms of what information is captured.  On SVM, add interrupt info and
      error code, while on VMX it add IDT vectoring and error code.  This
      sets the stage for macrofying the kvm_exit tracepoint definition so that
      it can be reused for kvm_nested_vmexit without loss of information.
      
      Opportunistically stuff a zero for VM_EXIT_INTR_INFO if the VM-Enter
      failed, as the field is guaranteed to be invalid.  Note, it'd be
      possible to further filter the interrupt/exception fields based on the
      VM-Exit reason, but the helper is intended only for tracepoints, i.e.
      an extra VMREAD or two is a non-issue, the failed VM-Enter case is just
      low hanging fruit.
      Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Message-Id: <20200923201349.16097-5-sean.j.christopherson@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      235ba74f
    • S
      KVM: VMX: Rename RDTSCP secondary exec control name to insert "ENABLE" · 7f3603b6
      Sean Christopherson 提交于
      Rename SECONDARY_EXEC_RDTSCP to SECONDARY_EXEC_ENABLE_RDTSCP in
      preparation for consolidating the logic for adjusting secondary exec
      controls based on the guest CPUID model.
      
      No functional change intended.
      Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Message-Id: <20200923165048.20486-4-sean.j.christopherson@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      7f3603b6
    • S
      KVM: x86: Add kvm_x86_ops hook to short circuit emulation · 09e3e2a1
      Sean Christopherson 提交于
      Replace the existing kvm_x86_ops.need_emulation_on_page_fault() with a
      more generic is_emulatable(), and unconditionally call the new function
      in x86_emulate_instruction().
      
      KVM will use the generic hook to support multiple security related
      technologies that prevent emulation in one way or another.  Similar to
      the existing AMD #NPF case where emulation of the current instruction is
      not possible due to lack of information, AMD's SEV-ES and Intel's SGX
      and TDX will introduce scenarios where emulation is impossible due to
      the guest's register state being inaccessible.  And again similar to the
      existing #NPF case, emulation can be initiated by kvm_mmu_page_fault(),
      i.e. outside of the control of vendor-specific code.
      
      While the cause and architecturally visible behavior of the various
      cases are different, e.g. SGX will inject a #UD, AMD #NPF is a clean
      resume or complete shutdown, and SEV-ES and TDX "return" an error, the
      impact on the common emulation code is identical: KVM must stop
      emulation immediately and resume the guest.
      
      Query is_emulatable() in handle_ud() as well so that the
      force_emulation_prefix code doesn't incorrectly modify RIP before
      calling emulate_instruction() in the absurdly unlikely scenario that
      KVM encounters forced emulation in conjunction with "do not emulate".
      
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Message-Id: <20200915232702.15945-1-sean.j.christopherson@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      09e3e2a1
    • B
      KVM: SVM: Enable INVPCID feature on AMD · 4407a797
      Babu Moger 提交于
      The following intercept bit has been added to support VMEXIT
      for INVPCID instruction:
      Code    Name            Cause
      A2h     VMEXIT_INVPCID  INVPCID instruction
      
      The following bit has been added to the VMCB layout control area
      to control intercept of INVPCID:
      Byte Offset     Bit(s)    Function
      14h             2         intercept INVPCID
      
      Enable the interceptions when the the guest is running with shadow
      page table enabled and handle the tlbflush based on the invpcid
      instruction type.
      
      For the guests with nested page table (NPT) support, the INVPCID
      feature works as running it natively. KVM does not need to do any
      special handling in this case.
      
      AMD documentation for INVPCID feature is available at "AMD64
      Architecture Programmer’s Manual Volume 2: System Programming,
      Pub. 24593 Rev. 3.34(or later)"
      
      The documentation can be obtained at the links below:
      Link: https://www.amd.com/system/files/TechDocs/24593.pdf
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537Signed-off-by: NBabu Moger <babu.moger@amd.com>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      Message-Id: <159985255929.11252.17346684135277453258.stgit@bmoger-ubuntu>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4407a797
    • B
      KVM: SVM: Add new intercept word in vmcb_control_area · 4c44e8d6
      Babu Moger 提交于
      The new intercept bits have been added in vmcb control area to support
      few more interceptions. Here are the some of them.
       - INTERCEPT_INVLPGB,
       - INTERCEPT_INVLPGB_ILLEGAL,
       - INTERCEPT_INVPCID,
       - INTERCEPT_MCOMMIT,
       - INTERCEPT_TLBSYNC,
      
      Add a new intercept word in vmcb_control_area to support these instructions.
      Also update kvm_nested_vmrun trace function to support the new addition.
      
      AMD documentation for these instructions is available at "AMD64
      Architecture Programmer’s Manual Volume 2: System Programming, Pub. 24593
      Rev. 3.34(or later)"
      
      The documentation can be obtained at the links below:
      Link: https://www.amd.com/system/files/TechDocs/24593.pdf
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537Signed-off-by: NBabu Moger <babu.moger@amd.com>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      Message-Id: <159985251547.11252.16994139329949066945.stgit@bmoger-ubuntu>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4c44e8d6
    • B
      KVM: SVM: Modify 64 bit intercept field to two 32 bit vectors · c62e2e94
      Babu Moger 提交于
      Convert all the intercepts to one array of 32 bit vectors in
      vmcb_control_area. This makes it easy for future intercept vector
      additions. Also update trace functions.
      Signed-off-by: NBabu Moger <babu.moger@amd.com>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      Message-Id: <159985250813.11252.5736581193881040525.stgit@bmoger-ubuntu>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      c62e2e94
    • B
      KVM: SVM: Modify intercept_exceptions to generic intercepts · 9780d51d
      Babu Moger 提交于
      Modify intercept_exceptions to generic intercepts in vmcb_control_area. Use
      the generic vmcb_set_intercept, vmcb_clr_intercept and vmcb_is_intercept to
      set/clear/test the intercept_exceptions bits.
      Signed-off-by: NBabu Moger <babu.moger@amd.com>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      Message-Id: <159985250037.11252.1361972528657052410.stgit@bmoger-ubuntu>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      9780d51d
    • B
      KVM: SVM: Change intercept_dr to generic intercepts · 30abaa88
      Babu Moger 提交于
      Modify intercept_dr to generic intercepts in vmcb_control_area. Use
      the generic vmcb_set_intercept, vmcb_clr_intercept and vmcb_is_intercept
      to set/clear/test the intercept_dr bits.
      Signed-off-by: NBabu Moger <babu.moger@amd.com>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      Message-Id: <159985249255.11252.10000868032136333355.stgit@bmoger-ubuntu>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      30abaa88
    • B
      KVM: SVM: Change intercept_cr to generic intercepts · 03bfeeb9
      Babu Moger 提交于
      Change intercept_cr to generic intercepts in vmcb_control_area.
      Use the new vmcb_set_intercept, vmcb_clr_intercept and vmcb_is_intercept
      where applicable.
      Signed-off-by: NBabu Moger <babu.moger@amd.com>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      Message-Id: <159985248506.11252.9081085950784508671.stgit@bmoger-ubuntu>
      [Change constant names. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      03bfeeb9
    • B
      KVM: SVM: Introduce vmcb_(set_intercept/clr_intercept/_is_intercept) · c45ad722
      Babu Moger 提交于
      This is in preparation for the future intercept vector additions.
      
      Add new functions vmcb_set_intercept, vmcb_clr_intercept and vmcb_is_intercept
      using kernel APIs __set_bit, __clear_bit and test_bit espectively.
      Signed-off-by: NBabu Moger <babu.moger@amd.com>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      Message-Id: <159985247876.11252.16039238014239824460.stgit@bmoger-ubuntu>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      c45ad722
  4. 08 9月, 2020 3 次提交
  5. 04 9月, 2020 2 次提交
  6. 30 8月, 2020 1 次提交
  7. 26 8月, 2020 1 次提交
  8. 22 8月, 2020 1 次提交
    • W
      KVM: Pass MMU notifier range flags to kvm_unmap_hva_range() · fdfe7cbd
      Will Deacon 提交于
      The 'flags' field of 'struct mmu_notifier_range' is used to indicate
      whether invalidate_range_{start,end}() are permitted to block. In the
      case of kvm_mmu_notifier_invalidate_range_start(), this field is not
      forwarded on to the architecture-specific implementation of
      kvm_unmap_hva_range() and therefore the backend cannot sensibly decide
      whether or not to block.
      
      Add an extra 'flags' parameter to kvm_unmap_hva_range() so that
      architectures are aware as to whether or not they are permitted to block.
      
      Cc: <stable@vger.kernel.org>
      Cc: Marc Zyngier <maz@kernel.org>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Signed-off-by: NWill Deacon <will@kernel.org>
      Message-Id: <20200811102725.7121-2-will@kernel.org>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      fdfe7cbd
  9. 20 8月, 2020 1 次提交
  10. 19 8月, 2020 1 次提交
  11. 18 8月, 2020 1 次提交
  12. 17 8月, 2020 1 次提交
  13. 13 8月, 2020 1 次提交
  14. 11 8月, 2020 2 次提交
  15. 08 8月, 2020 3 次提交