On 20/02/20 21:43, Sean Christopherson wrote: > 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(). Change the effective VMX > implementation to never do INVEPT, i.e. to always flush via INVVPID. > The INVEPT performed by __vmx_flush_tlb() when @invalidate_gpa=false and > enable_vpid=0 is unnecessary, as it will only flush GPA->HPA mappings; > GVA->GPA and GVA->HPA translations are flushed by VM-Enter when VPID is > disabled, and changes in the guest pages tables only affect GVA->*PA > mappings. > > When EPT and VPID are enabled, doing INVVPID is not required (by Intel's > architecture) to invalidate GPA mappings, i.e. TLB entries that cache > GPA->HPA translations can live across INVVPID as GPA->HPA mappings are > associated with an EPTP, not a VPID. The intent of @invalidate_gpa is > to inform vmx_flush_tlb() that it needs to "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 > invalidating GLA->GPA mappings. Since you need a v2, can you replace the name of mappings with "linear", "guest-physical" and "combined" as in the SDM? It takes a little to get used to them but it avoids three-letter acronym soup. Paolo
