1. 21 Apr, 2020 37 commits
  2. 20 Apr, 2020 3 commits
    • Sean Christopherson's avatar
      KVM: x86: Move "flush guest's TLB" logic to separate kvm_x86_ops hook · e64419d9
      Sean Christopherson authored
      Add a dedicated hook to handle flushing TLB entries on behalf of the
      guest, i.e. for a paravirtualized TLB flush, and use it directly instead
      of bouncing through kvm_vcpu_flush_tlb().
      
      For VMX, change the effective implementation implementation to never do
      INVEPT and flush only the current context, i.e. to always flush via
      INVVPID(SINGLE_CONTEXT).  The INVEPT performed by __vmx_flush_tlb() when
      @invalidate_gpa=false and enable_vpid=0 is unnecessary, as it will only
      flush guest-physical mappings; linear and combined mappings are flushed
      by VM-Enter when VPID is disabled, and changes in the guest pages tables
      do not affect guest-physical mappings.
      
      When EPT and VPID are enabled, doing INVVPID is not required (by Intel's
      architecture) to invalidate guest-physical mappings, i.e. TLB entries
      that cache guest-physical mappings can live across INVVPID as the
      mappings are associated with an EPTP, not a VPID.  The intent of
      @invalidate_gpa is to inform vmx_flush_tlb() that it must "invalidate
      gpa mappings", i.e. do INVEPT and not simply INVVPID.  Other than nested
      VPID handling, which now calls vpid_sync_context() directly, the only
      scenario where KVM can safely do INVVPID instead of INVEPT (when EPT is
      enabled) is if KVM is flushing TLB entries from the guest's perspective,
      i.e. is only required to invalidate linear mappings.
      
      For SVM, flushing TLB entries from the guest's perspective can be done
      by flushing the current ASID, as changes to the guest's page tables are
      associated only with the current ASID.
      
      Adding a dedicated ->tlb_flush_guest() paves the way toward removing
      @invalidate_gpa, which is a potentially dangerous control flag as its
      meaning is not exactly crystal clear, even for those who are familiar
      with the subtleties of what mappings Intel CPUs are/aren't allowed to
      keep across various invalidation scenarios.
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Message-Id: <20200320212833.3507-15-sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      e64419d9
    • Sean Christopherson's avatar
      KVM: nVMX: Use vpid_sync_vcpu_addr() to emulate INVVPID with address · bc41d0c4
      Sean Christopherson authored
      Use vpid_sync_vcpu_addr() to emulate the "individual address" variant of
      INVVPID now that said function handles the fallback case of the (host)
      CPU not supporting "individual address".
      
      Note, the "vpid == 0" checks in the vpid_sync_*() helpers aren't
      actually redundant with the "!operand.vpid" check in handle_invvpid(),
      as the vpid passed to vpid_sync_vcpu_addr() is a KVM (host) controlled
      value, i.e. vpid02 can be zero even if operand.vpid is non-zero.
      
      No functional change intended.
      Reviewed-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Message-Id: <20200320212833.3507-14-sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      bc41d0c4
    • Sean Christopherson's avatar
      KVM: VMX: Drop redundant capability checks in low level INVVPID helpers · ca431c0c
      Sean Christopherson authored
      Remove the INVVPID capabilities checks from vpid_sync_vcpu_single() and
      vpid_sync_vcpu_global() now that all callers ensure the INVVPID variant
      is supported.  Note, in some cases the guarantee is provided in concert
      with hardware_setup(), which enables VPID if and only if at least of
      invvpid_single() or invvpid_global() is supported.
      
      Drop the WARN_ON_ONCE() from vmx_flush_tlb() as vpid_sync_vcpu_single()
      will trigger a WARN() on INVVPID failure, i.e. if SINGLE_CONTEXT isn't
      supported.
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Message-Id: <20200320212833.3507-13-sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      ca431c0c