@@ -1126,11 +1126,14 @@ static void nested_vmx_transition_tlb_flush(struct kvm_vcpu *vcpu,
11261126 struct vcpu_vmx * vmx = to_vmx (vcpu );
11271127
11281128 /*
1129- * If vmcs12 doesn't use VPID, L1 expects linear and combined mappings
1130- * for *all* contexts to be flushed on VM-Enter/VM-Exit, i.e. it's a
1131- * full TLB flush from the guest's perspective. This is required even
1132- * if VPID is disabled in the host as KVM may need to synchronize the
1133- * MMU in response to the guest TLB flush.
1129+ * If VPID is disabled, then guest TLB accesses use VPID=0, i.e. the
1130+ * same VPID as the host, and so architecturally, linear and combined
1131+ * mappings for VPID=0 must be flushed at VM-Enter and VM-Exit. KVM
1132+ * emulates L2 sharing L1's VPID=0 by using vpid01 while running L2,
1133+ * and so KVM must also emulate TLB flush of VPID=0, i.e. vpid01. This
1134+ * is required if VPID is disabled in KVM, as a TLB flush (there are no
1135+ * VPIDs) still occurs from L1's perspective, and KVM may need to
1136+ * synchronize the MMU in response to the guest TLB flush.
11341137 *
11351138 * Note, using TLB_FLUSH_GUEST is correct even if nested EPT is in use.
11361139 * EPT is a special snowflake, as guest-physical mappings aren't
@@ -2196,6 +2199,17 @@ static void prepare_vmcs02_early_rare(struct vcpu_vmx *vmx,
21962199
21972200 vmcs_write64 (VMCS_LINK_POINTER , INVALID_GPA );
21982201
2202+ /*
2203+ * If VPID is disabled, then guest TLB accesses use VPID=0, i.e. the
2204+ * same VPID as the host. Emulate this behavior by using vpid01 for L2
2205+ * if VPID is disabled in vmcs12. Note, if VPID is disabled, VM-Enter
2206+ * and VM-Exit are architecturally required to flush VPID=0, but *only*
2207+ * VPID=0. I.e. using vpid02 would be ok (so long as KVM emulates the
2208+ * required flushes), but doing so would cause KVM to over-flush. E.g.
2209+ * if L1 runs L2 X with VPID12=1, then runs L2 Y with VPID12 disabled,
2210+ * and then runs L2 X again, then KVM can and should retain TLB entries
2211+ * for VPID12=1.
2212+ */
21992213 if (enable_vpid ) {
22002214 if (nested_cpu_has_vpid (vmcs12 ) && vmx -> nested .vpid02 )
22012215 vmcs_write16 (VIRTUAL_PROCESSOR_ID , vmx -> nested .vpid02 );
@@ -5758,6 +5772,12 @@ static int handle_invvpid(struct kvm_vcpu *vcpu)
57585772 return nested_vmx_fail (vcpu ,
57595773 VMXERR_INVALID_OPERAND_TO_INVEPT_INVVPID );
57605774
5775+ /*
5776+ * Always flush the effective vpid02, i.e. never flush the current VPID
5777+ * and never explicitly flush vpid01. INVVPID targets a VPID, not a
5778+ * VMCS, and so whether or not the current vmcs12 has VPID enabled is
5779+ * irrelevant (and there may not be a loaded vmcs12).
5780+ */
57615781 vpid02 = nested_get_vpid02 (vcpu );
57625782 switch (type ) {
57635783 case VMX_VPID_EXTENT_INDIVIDUAL_ADDR :
0 commit comments