• 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
kvm_host.h 50.4 KB