28-18 Vol. 3C

VMX SUPPORT FOR ADDRESS TRANSLATION

•

Software should use the INVEPT instruction with the “single-context” INVEPT type after making any of the 
following changes to an EPT paging-structure entry (the INVEPT descriptor should contain an EPTP value that 
references — directly or indirectly — the modified EPT paging structure):
— Changing any of the privilege bits 2:0 from 1 to 0.
— Changing the physical address in bits 51:12.
— Clearing bit 8 (the accessed flag) if accessed and dirty flags for EPT will be enabled.
— For an EPT PDPTE or an EPT PDE, changing bit 7 (which determines whether the entry maps a page).
— For  the last EPT paging-structure entry used to translate a guest-physical address (an EPT PDPTE with bit 7 

set to 1, an EPT PDE with bit 7 set to 1, or an EPT PTE), changing either bits 5:3 or bit 6. (These bits 
determine the effective memory type of accesses using that EPT paging-structure entry; see Section 
28.2.6.)

— For  the last EPT paging-structure entry used to translate a guest-physical address (an EPT PDPTE with bit 7 

set to 1, an EPT PDE with bit 7 set to 1, or an EPT PTE), clearing bit 9 (the dirty flag) if accessed and dirty 
flags for EPT will be enabled.

•

Software should use the INVEPT instruction with the “single-context” INVEPT type before a VM entry with an 
EPTP value X such that X[6] = 1 (accessed and dirty flags for EPT are enabled) if the logical processor had 
earlier been in VMX non-root operation with an EPTP value Y such that Y[6] = 0 (accessed and dirty flags for 
EPT are not enabled) and Y[51:12] = X[51:12].

•

Software may use the INVEPT instruction after modifying a present EPT paging-structure entry to change any 
of the privilege bits 2:0 from 0 to 1. Failure to do so may cause an EPT violation that would not otherwise occur. 
Because an EPT violation invalidates any mappings that would be used by the access that caused the EPT 
violation (see Section 28.3.3.1), an EPT violation will not recur if the original access is performed again, even if 
the INVEPT instruction is not executed.

•

Because a logical processor does not cache any information derived from EPT paging-structure entries that are 
not present or misconfigured (see Section 28.2.3.1), it is not necessary to execute INVEPT following modifi-
cation of an EPT paging-structure entry that had been not present or misconfigured.

•

As detailed in Section 29.4.5, an access to the APIC-access page might not cause an APIC-access VM exit if 
software does not properly invalidate information that may be cached from the EPT paging structures. If EPT 
was in use on a logical processor at one time with EPTP X, it is recommended that software use the INVEPT 
instruction with the “single-context” INVEPT type and with EPTP X in the INVEPT descriptor before a VM entry 
on the same logical processor that enables EPT with EPTP X and either (a) the “virtualize APIC accesses” VM-
execution control was changed from 0 to 1; or (b) the value of the APIC-access address was changed.

•

Software can use the INVEPT instruction with the “all-context” INVEPT type immediately after execution of the 
VMXON instruction or immediately prior to execution of the VMXOFF instruction. Either prevents potentially 
undesired retention of information cached from EPT paging structures between separate uses of VMX 
operation.

In a system containing more than one logical processor, software must account for the fact that information from 
an EPT paging-structure entry may be cached on logical processors other than the one that modifies that entry. The 
process of propagating the changes to a paging-structure entry is commonly referred to as “TLB shootdown.” A 
discussion of TLB shootdown appears in Section 4.10.5, “Propagation of Paging-Structure Changes to Multiple 
Processors,” in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A.