Lines Matching full:vpid

1241  * If L1 uses VPID and we allocated a vpid02, TLB entries are tagged
1242  * with different VPID (L1 entries are tagged with vmx->vpid
1263 	 * If VPID is disabled, then guest TLB accesses use VPID=0, i.e. the
1264 	 * same VPID as the host, and so architecturally, linear and combined
1265 	 * mappings for VPID=0 must be flushed at VM-Enter and VM-Exit.  KVM
1266 	 * emulates L2 sharing L1's VPID=0 by using vpid01 while running L2,
1267 	 * and so KVM must also emulate TLB flush of VPID=0, i.e. vpid01.  This
1268 	 * is required if VPID is disabled in KVM, as a TLB flush (there are no
1274 	 * flushed on VPID invalidations, including VM-Enter or VM-Exit with
1275 	 * VPID disabled.  As a result, KVM _never_ needs to sync nEPT
1284 	/* L2 should never have a VPID if VPID is disabled. */
1288 	 * VPID is enabled and in use by vmcs12.  If vpid12 is changing, then
1290 	 * is the VPID incorporated into the MMU context.  I.e. KVM must assume
1301 	 * If VPID is enabled, used by vmc12, and vpid12 is not changing but
1303 	 * KVM was unable to allocate a VPID for L2, flush the current context
2377 	 * If VPID is disabled, then guest TLB accesses use VPID=0, i.e. the
2378 	 * same VPID as the host.  Emulate this behavior by using vpid01 for L2
2379 	 * if VPID is disabled in vmcs12.  Note, if VPID is disabled, VM-Enter
2380 	 * and VM-Exit are architecturally required to flush VPID=0, but *only*
2381 	 * VPID=0.  I.e. using vpid02 would be ok (so long as KVM emulates the
2391 			vmcs_write16(VIRTUAL_PROCESSOR_ID, vmx->vpid);
6063 		u64 vpid;
6100 	if (operand.vpid >> 16)
6105 	 * Always flush the effective vpid02, i.e. never flush the current VPID
6106 	 * and never explicitly flush vpid01.  INVVPID targets a VPID, not a
6107 	 * VMCS, and so whether or not the current vmcs12 has VPID enabled is
6117 		if (!operand.vpid ||
6125 		if (!operand.vpid)
6140 	 * linear mappings for L2 (tagged with L2's VPID).  Free all guest