Intel 64 and IA-32 Architectures. Software Developer’s Manual (Collection, 2023) - page 115

 

  Index      Manuals     Intel 64 and IA-32 Architectures. Software Developer’s Manual (Collection, 2023)

 

Search            copyright infringement  

 

   

 

   

 

Content      ..     113      114      115      116     ..

 

 

 

Intel 64 and IA-32 Architectures. Software Developer’s Manual (Collection, 2023) - page 115

 

 

VM EXITS
Table 28-5. Exit Qualification for I/O Instructions (Contd.)
Bit Position(s)
Contents
5
REP prefixed (0 = not REP; 1 = REP)
6
Operand encoding (0 = DX, 1 = immediate)
15:7
Not currently defined
31:16
Port number (as specified in DX or in an immediate operand)
63:32
Not currently defined. These bits exist only on processors that support Intel 64 architecture.
Table 28-6. Exit Qualification for APIC-Access VM Exits from Linear Accesses and Guest-Physical Accesses
Bit Position(s)
Contents
11:0
• If the APIC-access VM exit is due to a linear access, the offset of access within the APIC page.
• Undefined if the APIC-access VM exit is due a guest-physical access
15:12
Access type:
0 = linear access for a data read during instruction execution
1 = linear access for a data write during instruction execution
2 = linear access for an instruction fetch
3 = linear access (read or write) during event delivery
4 = linear access for monitoring
10 = guest-physical access during event delivery
11 = guest-physical access for monitoring or trace
15 = guest-physical access for an instruction fetch or during instruction execution
Other values not used
16
This bit is set for certain accesses that are asynchronous to instruction execution and not part of event delivery.
These includes guest-physical accesses related to trace output by Intel PT (see Section 26.5.4), accesses related
to PEBS on processors with the “EPT-friendly” enhancement (see Section 20.9.5), and accesses that occur during
user-interrupt delivery (see Section 7.4.2).
63:17
Not currently defined. Bits 63:32 exist only on processors that support Intel 64 architecture.
Bit 12 reports “NMI unblocking due to IRET”; see Section 28.2.3.
Bit 16 is set for certain accesses that are asynchronous to instruction execution and not part of event
delivery. These include trace-address pre-translation (TAPT) for Intel PT (see Section 26.5.4), accesses
related to PEBS on processors with the “EPT-friendly” enhancement (see Section 20.9.5), and accesses as
part of user-interrupt delivery (see Section 7.4.2).
— For VM exits caused as part of EOI virtualization (Section 30.1.4), bits 7:0 of the exit qualification are set
to vector of the virtual interrupt that was dismissed by the EOI virtualization. Bits above bit 7 are cleared.
— For APIC-write VM exits (Section 30.4.3.3), bits 11:0 of the exit qualification are set to the page offset of
the write access that caused the VM exit.1 Bits above bit 11 are cleared.
— For a VM exit due to a page-modification log-full event (Section 29.3.6), bit 12 of the exit qualification
reports “NMI unblocking due to IRET” (see Section 28.2.3). Bit 16 is set if the VM exit occurs during TAPT,
EPT-friendly PEBS, or user-interrupt delivery. All other bits of the exit qualification are undefined.
— For a VM exit due to an SPP-related event (Section 29.3.4), bit 11 of the exit qualification indicates the type
of event: 0 indicates an SPP misconfiguration and 1 indicates an SPP miss. Bit 12 of the exit qualification
1. Execution of WRMSR with ECX = 83FH (self-IPI MSR) can lead to an APIC-write VM exit; the exit qualification for such an APIC-write
VM exit is 3F0H.
Vol. 3C
28-9
VM EXITS
reports “NMI unblocking due to IRET” (see Section 28.2.3). Bit 16 is set if the VM exit occurs during TAPT
EPT-friendly PEBS, or user-interrupt delivery. All other bits of the exit qualification are undefined.
— If the “PASID translation” VM-execution control, PASID translation is performed for executions of the
ENQCMD and ENQCMDS instructions (see Section 26.5.8). PASID translation may fail, resulting in a
VM exit. Such a VM exit saves an exit qualification specified in the following items:
For ENQCMD, the exit qualification is IA32_PASID[19:0].
For ENQCMDS, the exit qualification contains the low 32 bits of the instruction’s source operand (which
had been read from memory prior to PASID translation).
— For a VM exit due to an instruction timeout (Section 26.2), bit 0 indicates (if set) that the context of the
virtual machine is invalid and that the VM should not be resumed. Bit 12 of the exit qualification reports
“NMI unblocking due to IRET” (see Section 28.2.3). All other bits of the exit qualification are undefined.
Guest linear address. For some VM exits, this field receives a linear address that pertains to the VM exit. The
field is set for different VM exits as follows:
— VM exits due to attempts to execute LMSW with a memory operand. In these cases, this field receives the
linear address of that operand. Bits 63:32 are cleared if the logical processor was not in 64-bit mode before
the VM exit.
— VM exits due to attempts to execute INS or OUTS for which the relevant segment is usable (if the relevant
segment is not usable, the value is undefined). (ES is always the relevant segment for INS; for OUTS, the
relevant segment is DS unless overridden by an instruction prefix.) The linear address is the base address
of relevant segment plus (E)DI (for INS) or (E)SI (for OUTS). Bits 63:32 are cleared if the logical processor
was not in 64-bit mode before the VM exit.
Table 28-7. Exit Qualification for EPT Violations
Bit Position(s)
Contents
0
Set if the access causing the EPT violation was a data read.1
1
Set if the access causing the EPT violation was a data write.1
2
Set if the access causing the EPT violation was an instruction fetch.
3
The logical-AND of bit 0 in the EPT paging-structure entries used to translate the guest-physical address of the
access causing the EPT violation (indicates whether the guest-physical address was readable).2
4
The logical-AND of bit 1 in the EPT paging-structure entries used to translate the guest-physical address of the
access causing the EPT violation (indicates whether the guest-physical address was writeable).2
5
The logical-AND of bit 2 in the EPT paging-structure entries used to translate the guest-physical address of the
access causing the EPT violation.2
If the “mode-based execute control for EPT” VM-execution control is 0, this indicates whether the guest-physical
address was executable. If that control is 1, this indicates whether the guest-physical address was executable
for supervisor-mode linear addresses.
6
If the “mode-based execute control” VM-execution control is 0, the value of this bit is undefined. If that control is
1, this bit is the logical-AND of bit 10 in the EPT paging-structure entries used to translate the guest-physical
address of the access causing the EPT violation. In this case, it indicates whether the guest-physical address was
executable for user-mode linear addresses.3
7
Set if the guest linear-address field is valid.
The guest linear-address field is valid for all EPT violations except those resulting from an attempt to load the
guest PDPTEs as part of the execution of the MOV CR instruction and those due to trace-address pre-translation
(TAPT; Section 26.5.4).
28-10
Vol. 3C
VM EXITS
Table 28-7. Exit Qualification for EPT Violations (Contd.)
Bit Position(s)
Contents
8
If bit 7 is 1:
• Set if the access causing the EPT violation is to a guest-physical address that is the translation of a linear
address.
• Clear if the access causing the EPT violation is to a paging-structure entry as part of a page walk or the
update of an accessed or dirty bit.
Reserved if bit 7 is 0 (cleared to 0).
9
If bit 7 is 1, bit 8 is 1, and the processor supports advanced VM-exit information for EPT violations,4 this bit is 0
if the linear address is a supervisor-mode linear address and 1 if it is a user-mode linear address. (If CR0.PG = 0,
the translation of every linear address is a user-mode linear address and thus this bit will be 1.) Otherwise, this
bit is undefined.
10
If bit 7 is 1, bit 8 is 1, and the processor supports advanced VM-exit information for EPT violations,4 this bit is 0
if paging translates the linear address to a read-only page and 1 if it translates to a read/write page. (If CR0.PG =
0, every linear address is read/write and thus this bit will be 1.) Otherwise, this bit is undefined.
11
If bit 7 is 1, bit 8 is 1, and the processor supports advanced VM-exit information for EPT violations,4 this bit is 0
if paging translates the linear address to an executable page and 1 if it translates to an execute-disable page. (If
CR0.PG = 0, CR4.PAE = 0, or IA32_EFER.NXE = 0, every linear address is executable and thus this bit will be 0.)
Otherwise, this bit is undefined.
12
NMI unblocking due to IRET (see Section 28.2.3).
13
Set if the access causing the EPT violation was a shadow-stack access.
14
If supervisor shadow-stack control is enabled (by setting bit 7 of EPTP), this bit is the same as bit 60 in the EPT
paging-structure entry that maps the page of the guest-physical address of the access causing the EPT violation.
Otherwise (or if translation of the guest-physical address terminates before reaching an EPT paging-structure
entry that maps a page), this bit is undefined.
15
This bit is set if the EPT violation was caused as a result of guest-paging verification. See Section 29.3.3.2.
16
This bit is set if the access was asynchronous to instruction execution not the result of event delivery. The bit is
set if the access is related to trace output by Intel PT (see Section 26.5.4), accesses related to PEBS on
processors with the “EPT-friendly” enhancement (see Section 20.9.5), or to user-interrupt delivery (see Section
7.4.2). Otherwise, this bit is cleared.
63:17
Not currently defined. Bits 63:32 exist only on processors that support Intel 64 architecture.
NOTES:
1. If accessed and dirty flags for EPT are enabled, processor accesses to guest paging-structure entries are treated as writes with
regard to EPT violations (see Section 29.3.3.2). If such an access causes an EPT violation, the processor sets both bit 0 and bit 1 of
the exit qualification.
2. Bits 5:3 are cleared to 0 if either (1) any of EPT paging-structure entries used to translate the guest-physical address of the access
causing the EPT violation is not present; or (2) 4-level EPT is in use and the guest-physical address sets any bits in the range 51:48
(see Section 29.3.2).
3. Bit 6 is cleared to 0 if (1) the “mode-based execute control” VM-execution control is 1; and (2) either (a) any of EPT paging-structure
entries used to translate the guest-physical address of the access causing the EPT violation is not present; or (b) 4-level EPT is in use
and the guest-physical address sets any bits in the range 51:48 (see Section 29.3.2).
4. Software can determine whether advanced VM-exit information for EPT violations is supported by consulting the VMX capability
MSR IA32_VMX_EPT_VPID_CAP (see Appendix A.10).
— VM exits due to EPT violations that set bit 7 of the exit qualification (see Table 28-7; these are all EPT
violations except those resulting from an attempt to load the PDPTEs as of execution of the MOV CR
instruction and those due to TAPT). The linear address may translate to the guest-physical address whose
access caused the EPT violation. Alternatively, translation of the linear address may reference a paging-
Vol. 3C
28-11
VM EXITS
structure entry whose access caused the EPT violation. Bits 63:32 are cleared if the logical processor was
not in 64-bit mode before the VM exit.
If the EPT violation occurred during execution of an instruction in enclave mode (and not during delivery of
an event incident to enclave mode), bits 11:0 of this field are cleared.
— VM exits due to SPP-related events.
— If the “prematurely busy shadow stack” VM-exit control is 1, certain VM exits (besides those noted above)
save the linear address that pertains to the VM exit if the VM exit caused a shadow stack to become
prematurely busy (see Section 26.4.3). This is true for VM exits due for these reasons: EPT misconfigu-
ration, page-modification log-full event, and instruction timeout. (A VM exit due to instruction timeout that
sets bit 0 of the exit qualification, indicating that VM context is invalid, does not save a valid linear address.)
— For all other VM exits, the field is undefined.
Guest-physical address. For a VM exit due to an EPT violation, an EPT misconfiguration, or an SPP-related
event, this field receives the guest-physical address that caused the EPT violation or EPT misconfiguration. For
all other VM exits, the field is undefined.
If the EPT violation or EPT misconfiguration occurred during execution of an instruction in enclave mode (and
not during delivery of an event incident to enclave mode), bits 11:0 of this field are cleared.
28.2.2 Information for VM Exits Due to Vectored Events
Section 25.9.2 defines fields containing information for VM exits due to the following events: exceptions (including
those generated by the instructions INT1, INT3, INTO, BOUND, UD0, UD1, and UD2); external interrupts that occur
while the “acknowledge interrupt on exit” VM-exit control is 1; and non-maskable interrupts (NMIs).1 Such
VM exits include those that occur on an attempt at a task switch that causes an exception before generating the
VM exit due to the task switch that causes the VM exit.
The following items detail the use of these fields:
VM-exit interruption information (format given in Table 25-19). The following items detail how this field is
established for VM exits due to these events:
— For an exception, bits 7:0 receive the exception vector (at most 31). For an NMI, bits 7:0 are set to 2. For
an external interrupt, bits 7:0 receive the vector.
— Bits 10:8 are set to 0 (external interrupt), 2 (non-maskable interrupt), 3 (hardware exception), 5
(privileged software exception), or 6 (software exception). Hardware exceptions comprise all exceptions
except the following:
Debug exceptions (#DB) generated by the INT1 instruction; these are privileged software exceptions.
(Other debug exceptions are considered hardware exceptions, as are those caused by executions of
INT1 in enclave mode.)
Breakpoint exceptions (#BP; generated by INT3) and overflow exceptions (#OF; generated by INTO);
these are software exceptions. (A #BP that occurs in enclave mode is considered a hardware
exception.)
BOUND-range exceeded exceptions (#BR; generated by BOUND) and invalid opcode exceptions (#UD)
generated by UD0, UD1, and UD2 are hardware exceptions.
— Bit 11 is set to 1 if the VM exit is caused by a hardware exception that would have delivered an error code
on the stack. This bit is always 0 if the VM exit occurred while the logical processor was in real-address
mode (CR0.PE=0).2 If bit 11 is set to 1, the error code is placed in the VM-exit interruption error code (see
below).
— Bit 12 reports “NMI unblocking due to IRET”; see Section 28.2.3. The value of this bit is undefined if the
VM exit is due to a double fault (the interruption type is hardware exception and the vector is 8).
1.
INT1 and INT3 refer to the instructions with opcodes F1 and CC, respectively, and not to INT n with value 1 or 3 for n.
2.
If the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PE must be 1 in VMX operation, a logical processor cannot be in real-
address mode unless the “unrestricted guest” VM-execution control and bit 31 of the primary processor-based VM-execution con-
trols are both 1.
28-12
Vol. 3C
VM EXITS
— Bits 30:13 are always set to 0.
— Bit 31 is always set to 1.
For other VM exits (including those due to external interrupts when the “acknowledge interrupt on exit” VM-exit
control is 0), the field is marked invalid (by clearing bit 31) and the remainder of the field is undefined.
VM-exit interruption error code.
— For VM exits that set both bit 31 (valid) and bit 11 (error code valid) in the VM-exit interruption-information
field, this field receives the error code that would have been pushed on the stack had the event causing the
VM exit been delivered normally through the IDT. The EXT bit is set in this field exactly when it would be set
normally. For exceptions that occur during the delivery of double fault (if the IDT-vectoring information field
indicates a double fault), the EXT bit is set to 1, assuming that (1) that the exception would produce an
error code normally (if not incident to double-fault delivery) and (2) that the error code uses the EXT bit
(not for page faults, which use a different format).
— For other VM exits, the value of this field is undefined.
28.2.3 Information About NMI Unblocking Due to IRET
A VM exit may occur during execution of the IRET instruction for reasons including the following: faults, EPT viola-
tions, page-modification log-full events, SPP-related events, or instruction timeouts.
An execution of IRET that commences while non-maskable interrupts (NMIs) are blocked will unblock NMIs even if
a fault or VM exit occurs; the state saved by such a VM exit will indicate that NMIs were not blocked.
VM exits for the reasons enumerated above provide more information to software by saving a bit called “NMI
unblocking due to IRET.” This bit is defined if (1) either the “NMI exiting” VM-execution control is 0 or the “virtual
NMIs” VM-execution control is 1; (2) the VM exit does not set the valid bit in the IDT-vectoring information field
(see Section 28.2.4); and (3) the VM exit is not due to a double fault. In these cases, the bit is defined as follows:
The bit is 1 if the VM exit resulted from a memory access as part of execution of the IRET instruction and one
of the following holds:
— The “virtual NMIs” VM-execution control is 0 and blocking by NMI (see Table 25-3) was in effect before
execution of IRET.
— The “virtual NMIs” VM-execution control is 1 and virtual-NMI blocking was in effect before execution of
IRET.
The bit is 0 for all other relevant VM exits.
For VM exits due to faults, NMI unblocking due to IRET is saved in bit 12 of the VM-exit interruption-information
field (Section 28.2.2). For VM exits due to EPT violations, page-modification log-full events, SPP-related events,
and instruction timeouts, NMI unblocking due to IRET is saved in bit 12 of the exit qualification (Section 28.2.1).
(Executions of IRET may also incur VM exits due to APIC accesses and EPT misconfigurations. These VM exits do
not report information about NMI unblocking due to IRET.)
28.2.4 Information for VM Exits During Event Delivery
Section 25.9.3 defined fields containing information for VM exits that occur while delivering an event through the
IDT and as a result of any of the following cases:1
A fault occurs during event delivery and causes a VM exit (because the bit associated with the fault is set to 1
in the exception bitmap).
A task switch is invoked through a task gate in the IDT. The VM exit occurs due to the task switch only after the
initial checks of the task switch pass (see Section 26.4.2).
Event delivery causes an APIC-access VM exit (see Section 30.4).
1. This includes the case in which a VM exit occurs while delivering a software interrupt (INT n) through the 16-bit IVT (interrupt vec-
tor table) that is used in virtual-8086 mode with virtual-machine extensions (if RFLAGS.VM = CR4.VME = 1).
Vol. 3C
28-13
VM EXITS
An EPT violation, EPT misconfiguration, page-modification log-full event, or SPP-related event that occurs
during event delivery.
Any of the above VM exits that occur during user-interrupt notification processing (see Section 7.5.2). Such
VM exits will be treated as if they occurred during delivery of an external interrupt with the vector UINV.
These fields are used for VM exits that occur during delivery of events injected as part of VM entry (see Section
27.6.1.2).
A VM exit is not considered to occur during event delivery in any of the following circumstances:
The original event causes the VM exit directly (for example, because the original event is a non-maskable
interrupt (NMI) and the “NMI exiting” VM-execution control is 1).
The original event results in a double-fault exception that causes the VM exit directly.
The VM exit occurred as a result of fetching the first instruction of the handler invoked by the event delivery.
The VM exit is caused by a triple fault.
The original event was a software interrupt (INT n) executed in virtual-8086 mode with EFLAGS.IOPL < 3 and
the VM exit was due to a general-protection exception (#GP) that occurred because either CR4.VME = 0 or bit
n of the software interrupt redirection bit map in the TSS is set.
The following items detail the use of these fields:
IDT-vectoring information (format given in Table 25-20). The following items detail how this field is established
for VM exits that occur during event delivery:
— If the VM exit occurred during delivery of an exception, bits 7:0 receive the exception vector (at most 31).
If the VM exit occurred during delivery of an NMI, bits 7:0 are set to 2. If the VM exit occurred during
delivery of an external interrupt, bits 7:0 receive the vector.
— Bits 10:8 are set to indicate the type of event that was being delivered when the VM exit occurred: 0
(external interrupt), 2 (non-maskable interrupt), 3 (hardware exception), 4 (software interrupt), 5
(privileged software interrupt), or 6 (software exception).
Hardware exceptions comprise all exceptions except the following:1
Debug exceptions (#DB) generated by the INT1 instruction; these are privileged software exceptions.
(Other debug exceptions are considered hardware exceptions, as are those caused by executions of
INT1 in enclave mode.)
Breakpoint exceptions (#BP; generated by INT3) and overflow exceptions (#OF; generated by INTO);
these are software exceptions. (A #BP that occurs in enclave mode is considered a hardware
exception.)
BOUND-range exceeded exceptions (#BR; generated by BOUND) and invalid opcode exceptions (#UD)
generated by UD0, UD1, and UD2 are hardware exceptions.
— Bit 11 is set to 1 if the VM exit occurred during delivery of a hardware exception that would have delivered
an error code on the stack. This bit is always 0 if the VM exit occurred while the logical processor was in
real-address mode (CR0.PE=0).2 If bit 11 is set to 1, the error code is placed in the IDT-vectoring error
code (see below).
— Bit 12 is undefined.
— Bits 30:13 are always set to 0.
— Bit 31 is always set to 1.
For other VM exits, the field is marked invalid (by clearing bit 31) and the remainder of the field is undefined.
IDT-vectoring error code.
1. In the following items, INT1 and INT3 refer to the instructions with opcodes F1 and CC, respectively, and not to INT n with value 1 or
3 for n.
2. If the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PE must be 1 in VMX operation, a logical processor cannot be in real-
address mode unless the “unrestricted guest” VM-execution control and bit 31 of the primary processor-based VM-execution con-
trols are both 1.
28-14
Vol. 3C
VM EXITS
— For VM exits that set both bit 31 (valid) and bit 11 (error code valid) in the IDT-vectoring information field,
this field receives the error code that would have been pushed on the stack by the event that was being
delivered through the IDT at the time of the VM exit. The EXT bit is set in this field when it would be set
normally.
— For other VM exits, the value of this field is undefined.
28.2.5 Information for VM Exits Due to Instruction Execution
Section 25.9.4 defined fields containing information for VM exits that occur due to instruction execution. (The VM-
exit instruction length is also used for VM exits that occur during the delivery of a software interrupt or software
exception.) The following items detail their use.
VM-exit instruction length. This field is used in the following cases:
— For fault-like VM exits due to attempts to execute one of the following instructions that cause VM exits
unconditionally (see Section 26.1.2) or based on the settings of VM-execution controls (see Section
26.1.3): CLTS, CPUID, ENCLS, GETSEC, HLT, IN, INS, INVD, INVEPT, INVLPG, INVPCID, INVVPID, LGDT,
LIDT, LLDT, LMSW, LOADIWKEY, LTR, MONITOR, MOV CR, MOV DR, MWAIT, OUT, OUTS, PAUSE, PCONFIG,
RDMSR, RDPMC, RDRAND, RDSEED, RDTSC, RDTSCP, RSM, SGDT, SIDT, SLDT, STR, TPAUSE, UMWAIT,
VMCALL, VMCLEAR, VMLAUNCH, VMPTRLD, VMPTRST, VMREAD, VMRESUME, VMWRITE, VMXOFF, VMXON,
WBINVD, WBNOINVD, WRMSR, XRSTORS, XSETBV, and XSAVES.1
— For VM exits due to software exceptions (those generated by executions of INT3 or INTO) or privileged
software exceptions (those generated by executions of INT1).
— For VM exits due to faults encountered during delivery of a software interrupt, privileged software
exception, or software exception.
— For VM exits due to attempts to effect a task switch via instruction execution. These are VM exits that
produce an exit reason indicating task switch and either of the following:
An exit qualification indicating execution of CALL, IRET, or JMP instruction.
An exit qualification indicating a task gate in the IDT and an IDT-vectoring information field indicating
that the task gate was encountered during delivery of a software interrupt, privileged software
exception, or software exception.
— For APIC-access VM exits and for VM exits caused by EPT violations, page-modification log-full events, and
SPP-related events encountered during delivery of a software interrupt, privileged software exception, or
software exception.2
— For VM exits due executions of VMFUNC that fail because one of the following is true:
EAX indicates a VM function that is not enabled (the bit at position EAX is 0 in the VM-function controls;
see Section 26.5.6.2).
EAX = 0 and either ECX 512 or the value of ECX selects an invalid tentative EPTP value (see Section
26.5.6.3).
In all the above cases, this field receives the length in bytes (1-15) of the instruction (including any instruction
prefixes) whose execution led to the VM exit (see the next paragraph for one exception).
The cases of VM exits encountered during delivery of a software interrupt, privileged software exception, or
software exception include those encountered during delivery of events injected as part of VM entry (see
Section 27.6.1.2). If the original event was injected as part of VM entry, this field receives the value of the VM-
entry instruction length.
All VM exits other than those listed in the above items leave this field undefined.
1.
This item applies only to fault-like VM exits. It does not apply to trap-like VM exits following executions of the MOV to CR8 instruc-
tion when the “use TPR shadow” VM-execution control is 1 or to those following executions of the WRMSR instruction when the
“virtualize x2APIC mode” VM-execution control is 1.
2.
The VM-exit instruction-length field is not defined following APIC-access VM exits resulting from physical accesses (see Section
30.4.6) even if encountered during delivery of a software interrupt, privileged software exception, or software exception.
Vol. 3C
28-15
VM EXITS
If the VM exit occurred in enclave mode, this field is cleared (none of the previous items apply).
Table 28-8. Format of the VM-Exit Instruction-Information Field as Used for INS and OUTS
Bit Position(s)
Content
6:0
Undefined.
9:7
Address size:
0: 16-bit
1: 32-bit
2: 64-bit (used only on processors that support Intel 64 architecture)
Other values not used.
14:10
Undefined.
17:15
Segment register:
0: ES
1: CS
2: SS
3: DS
4: FS
5: GS
Other values not used. Undefined for VM exits due to execution of INS.
31:18
Undefined.
VM-exit instruction information. For VM exits due to attempts to execute INS, INVEPT, INVPCID, INVVPID,
LIDT, LGDT, LLDT, LOADIWKEY, LTR, OUTS, RDRAND, RDSEED, SIDT, SGDT, SLDT, STR, TPAUSE, UMWAIT,
VMCLEAR, VMPTRLD, VMPTRST, VMREAD, VMWRITE, VMXON, XRSTORS, or XSAVES, this field receives
information about the instruction that caused the VM exit. The format of the field depends on the identity of the
instruction causing the VM exit:
— For VM exits due to attempts to execute INS or OUTS, the field has the format is given in Table 28-8.1
— For VM exits due to attempts to execute INVEPT, INVPCID, or INVVPID, the field has the format is given in
Table 28-9.
— For VM exits due to attempts to execute LIDT, LGDT, SIDT, or SGDT, the field has the format is given in
Table 28-10.
— For VM exits due to attempts to execute LLDT, LTR, SLDT, or STR, the field has the format is given in
Table 28-11.
— For VM exits due to attempts to execute RDRAND or RDSEED, the field has the format is given in
Table 28-12.
— For VM exits due to attempts to execute TPAUSE or UMWAIT, the field has the format is given in
Table 28-13.
— For VM exits due to attempts to execute VMCLEAR, VMPTRLD, VMPTRST, VMXON, XRSTORS, or XSAVES,
the field has the format is given in Table 28-14.
— For VM exits due to attempts to execute VMREAD or VMWRITE, the field has the format is given in
Table 28-15.
— For VM exits due to attempts to execute LOADIWKEY, the field has the format is given in Table 28-16.
For all other VM exits, the field is undefined, unless the VM exit occurred in enclave mode, in which case the
field is cleared.
1. The format of the field was undefined for these VM exits on the first processors to support the virtual-machine extensions. Soft-
ware can determine whether the format specified in Table 28-8 is used by consulting the VMX capability MSR IA32_VMX_BASIC
(see Appendix A.1).
28-16
Vol. 3C
VM EXITS
I/O RCX, I/O RSI, I/O RDI, I/O RIP. These fields are undefined except for SMM VM exits due to system-
management interrupts (SMIs) that arrive immediately after retirement of I/O instructions. See Section
32.15.2.3. Note that, if the VM exit occurred in enclave mode, these fields are all cleared.
Table 28-9. Format of the VM-Exit Instruction-Information Field as Used for INVEPT, INVPCID, and INVVPID
Bit Position(s)
Content
1:0
Scaling:
0: no scaling
1: scale by 2
2: scale by 4
3: scale by 8 (used only on processors that support Intel 64 architecture)
Undefined for instructions with no index register (bit 22 is set).
6:2
Undefined.
9:7
Address size:
0: 16-bit
1: 32-bit
2: 64-bit (used only on processors that support Intel 64 architecture)
Other values not used.
10
Cleared to 0.
14:11
Undefined.
17:15
Segment register:
0: ES
1: CS
2: SS
3: DS
4: FS
5: GS
Other values not used.
21:18
IndexReg:
0 = RAX
1 = RCX
2 = RDX
3 = RBX
4 = RSP
5 = RBP
6 = RSI
7 = RDI
8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)
Undefined for instructions with no index register (bit 22 is set).
22
IndexReg invalid (0 = valid; 1 = invalid)
26:23
BaseReg (encoded as IndexReg above)
Undefined for memory instructions with no base register (bit 27 is set).
27
BaseReg invalid (0 = valid; 1 = invalid)
31:28
Reg2 (same encoding as IndexReg above)
Vol. 3C
28-17
VM EXITS
Table 28-10. Format of the VM-Exit Instruction-Information Field as Used for LIDT, LGDT, SIDT, or SGDT
Bit Position(s)
Content
1:0
Scaling:
0: no scaling
1: scale by 2
2: scale by 4
3: scale by 8 (used only on processors that support Intel 64 architecture)
Undefined for instructions with no index register (bit 22 is set).
6:2
Undefined.
9:7
Address size:
0: 16-bit
1: 32-bit
2: 64-bit (used only on processors that support Intel 64 architecture)
Other values not used.
10
Cleared to 0.
11
Operand size:
0: 16-bit
1: 32-bit
Undefined for VM exits from 64-bit mode.
14:12
Undefined.
17:15
Segment register:
0: ES
1: CS
2: SS
3: DS
4: FS
5: GS
Other values not used.
21:18
IndexReg:
0 = RAX
1 = RCX
2 = RDX
3 = RBX
4 = RSP
5 = RBP
6 = RSI
7 = RDI
8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)
Undefined for instructions with no index register (bit 22 is set).
22
IndexReg invalid (0 = valid; 1 = invalid)
26:23
BaseReg (encoded as IndexReg above)
Undefined for instructions with no base register (bit 27 is set).
27
BaseReg invalid (0 = valid; 1 = invalid)
29:28
Instruction identity:
0: SGDT
1: SIDT
2: LGDT
3: LIDT
28-18
Vol. 3C
VM EXITS
Table 28-10. Format of the VM-Exit Instruction-Information Field as Used for LIDT, LGDT, SIDT, or SGDT (Contd.)
Bit Position(s)
Content
31:30
Undefined.
Table 28-11. Format of the VM-Exit Instruction-Information Field as Used for LLDT, LTR, SLDT, and STR
Bit Position(s)
Content
1:0
Scaling:
0: no scaling
1: scale by 2
2: scale by 4
3: scale by 8 (used only on processors that support Intel 64 architecture)
Undefined for register instructions (bit 10 is set) and for memory instructions with no index register (bit 10 is clear
and bit 22 is set).
2
Undefined.
6:3
Reg1:
0 = RAX
1 = RCX
2 = RDX
3 = RBX
4 = RSP
5 = RBP
6 = RSI
7 = RDI
8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)
Undefined for memory instructions (bit 10 is clear).
9:7
Address size:
0: 16-bit
1: 32-bit
2: 64-bit (used only on processors that support Intel 64 architecture)
Other values not used. Undefined for register instructions (bit 10 is set).
10
Mem/Reg (0 = memory; 1 = register).
14:11
Undefined.
17:15
Segment register:
0: ES
1: CS
2: SS
3: DS
4: FS
5: GS
Other values not used. Undefined for register instructions (bit 10 is set).
21:18
IndexReg (encoded as Reg1 above)
Undefined for register instructions (bit 10 is set) and for memory instructions with no index register (bit 10 is clear
and bit 22 is set).
22
IndexReg invalid (0 = valid; 1 = invalid)
Undefined for register instructions (bit 10 is set).
26:23
BaseReg (encoded as Reg1 above)
Undefined for register instructions (bit 10 is set) and for memory instructions with no base register (bit 10 is clear
and bit 27 is set).
Vol. 3C
28-19
VM EXITS
Table 28-11. Format of the VM-Exit Instruction-Information Field as Used for LLDT, LTR, SLDT, and STR (Contd.)
Bit Position(s)
Content
27
BaseReg invalid (0 = valid; 1 = invalid)
Undefined for register instructions (bit 10 is set).
29:28
Instruction identity:
0: SLDT
1: STR
2: LLDT
3: LTR
31:30
Undefined.
Table 28-12. Format of the VM-Exit Instruction-Information Field as Used for RDRAND and RDSEED
Bit Position(s)
Content
2:0
Undefined.
6:3
Operand register (destination register):
0 = RAX
1 = RCX
2 = RDX
3 = RBX
4 = RSP
5 = RBP
6 = RSI
7 = RDI
8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)
10:7
Undefined.
12:11
Operand size:
0: 16-bit
1: 32-bit
2: 64-bit
The value 3 is not used.
31:13
Undefined.
Table 28-13. Format of the VM-Exit Instruction-Information Field as Used for TPAUSE and UMWAIT
Bit Position(s)
Content
2:0
Undefined.
6:3
Operand register (source register):
0 = RAX
1 = RCX
2 = RDX
3 = RBX
4 = RSP
5 = RBP
6 = RSI
7 = RDI
8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)
31:7
Undefined.
28-20
Vol. 3C
VM EXITS
Table 28-14. Format of the VM-Exit Instruction-Information Field as Used for VMCLEAR, VMPTRLD, VMPTRST,
VMXON, XRSTORS, and XSAVES
Bit Position(s)
Content
1:0
Scaling:
0: no scaling
1: scale by 2
2: scale by 4
3: scale by 8 (used only on processors that support Intel 64 architecture)
Undefined for instructions with no index register (bit 22 is set).
6:2
Undefined.
9:7
Address size:
0: 16-bit
1: 32-bit
2: 64-bit (used only on processors that support Intel 64 architecture)
Other values not used.
10
Cleared to 0.
14:11
Undefined.
17:15
Segment register:
0: ES
1: CS
2: SS
3: DS
4: FS
5: GS
Other values not used.
21:18
IndexReg:
0 = RAX
1 = RCX
2 = RDX
3 = RBX
4 = RSP
5 = RBP
6 = RSI
7 = RDI
8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)
Undefined for instructions with no index register (bit 22 is set).
22
IndexReg invalid (0 = valid; 1 = invalid)
26:23
BaseReg (encoded as IndexReg above)
Undefined for instructions with no base register (bit 27 is set).
27
BaseReg invalid (0 = valid; 1 = invalid)
31:28
Undefined.
28.3
SAVING GUEST STATE
VM exits save certain components of processor state into corresponding fields in the guest-state area of the VMCS
(see Section 25.4). On processors that support Intel 64 architecture, the full value of each natural-width field (see
Section 25.11.2) is saved regardless of the mode of the logical processor before and after the VM exit.
Vol. 3C
28-21
VM EXITS
Table 28-15. Format of the VM-Exit Instruction-Information Field as Used for VMREAD and VMWRITE
Bit Position(s)
Content
1:0
Scaling:
0: no scaling
1: scale by 2
2: scale by 4
3: scale by 8 (used only on processors that support Intel 64 architecture)
Undefined for register instructions (bit 10 is set) and for memory instructions with no index register (bit
10 is clear
and bit 22 is set).
2
Undefined.
6:3
Reg1:
0 = RAX
1 = RCX
2 = RDX
3 = RBX
4 = RSP
5 = RBP
6 = RSI
7 = RDI
8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)
Undefined for memory instructions (bit 10 is clear).
9:7
Address size:
0: 16-bit
1: 32-bit
2: 64-bit (used only on processors that support Intel 64 architecture)
Other values not used. Undefined for register instructions (bit 10 is set).
10
Mem/Reg (0 = memory; 1 = register).
14:11
Undefined.
17:15
Segment register:
0: ES
1: CS
2: SS
3: DS
4: FS
5: GS
Other values not used. Undefined for register instructions (bit 10 is set).
21:18
IndexReg (encoded as Reg1 above)
Undefined for register instructions (bit 10 is set) and for memory instructions with no index register (bit
10 is clear
and bit 22 is set).
22
IndexReg invalid (0 = valid; 1 = invalid)
Undefined for register instructions (bit 10 is set).
26:23
BaseReg (encoded as Reg1 above)
Undefined for register instructions (bit 10 is set) and for memory instructions with no base register (bit 10 is clear
and bit 27 is set).
27
BaseReg invalid (0 = valid; 1 = invalid)
Undefined for register instructions (bit 10 is set).
31:28
Reg2 (same encoding as Reg1 above)
In general, the state saved is that which was in the logical processor at the time the VM exit commences. See
Section 28.1 for a discussion of which architectural updates occur at that time.
28-22
Vol. 3C
VM EXITS
Table 28-16. Format of the VM-Exit Instruction-Information Field as Used for LOADIWKEY
Bit Position(s)
Content
2:0
Undefined.
6:3
Reg1: identifies the first XMM register operand (XMM0-XMM15; values 8-15 are used only on processors that
support Intel 64 architecture).
30:7
Undefined.
31:28
Reg2: identifies the second XMM register operand (see above).
Section 28.3.1 through Section 28.3.4 provide details for how various components of processor state are saved.
These sections reference VMCS fields that correspond to processor state. Unless otherwise stated, these refer-
ences are to fields in the guest-state area.
28.3.1 Saving Control Registers, Debug Registers, and MSRs
Contents of certain control registers, debug registers, and MSRs are saved as follows:
The contents of CR0, CR3, CR4, and the IA32_SYSENTER_CS, IA32_SYSENTER_ESP, and IA32_SYSENTER_EIP
MSRs are saved into the corresponding fields. Bits 63:32 of the IA32_SYSENTER_CS MSR are not saved. On
processors that do not support Intel 64 architecture, bits 63:32 of the IA32_SYSENTER_ESP and
IA32_SYSENTER_EIP MSRs are not saved.
If the “save debug controls” VM-exit control is 1, the contents of DR7 and the IA32_DEBUGCTL MSR are saved
into the corresponding fields. The first processors to support the virtual-machine extensions supported only the
1-setting of this control and thus always saved data into these fields.
If the “save IA32_PAT” VM-exit control is 1, the contents of the IA32_PAT MSR are saved into the corresponding
field.
If the “save IA32_EFER” VM-exit control is 1, the contents of the IA32_EFER MSR are saved into the corre-
sponding field.
If the processor supports either the 1-setting of the “load IA32_BNDCFGS” VM-entry control or that of the
“clear IA32_BNDCFGS” VM-exit control, the contents of the IA32_BNDCFGS MSR are saved into the corre-
sponding field.
If the processor supports either the 1-setting of the “load IA32_RTIT_CTL” VM-entry control or that of the
“clear IA32_RTIT_CTL” VM-exit control, the contents of the IA32_RTIT_CTL MSR are saved into the corre-
sponding field.
If the processor supports the 1-setting of the “load CET” VM-entry control, the contents of the IA32_S_CET and
IA32_INTERRUPT_SSP_TABLE_ADDR MSRs are saved into the corresponding fields. On processors that do not
support Intel 64 architecture, bits 63:32 of these MSRs are not saved.
If the processor supports either the 1-setting of the “load guest IA32_LBR_CTL” VM-entry control or that of the
“clear IA32_LBR_CTL” VM-exit control, the contents of the IA32_LBR_CTL MSR are saved into the corre-
sponding field.
If the processor supports the 1-setting of the “load PKRS” VM-entry control, the contents of the IA32_PKRS
MSR are saved into the corresponding field.
If a processor supports user interrupts, every VM exit saves UINV into the guest UINV field in the VMCS
(bits 15:8 of the field are cleared).
If the “save IA32_PERF_GLOBAL_CTL” VM-exit control is 1, the contents of the IA32_PERF_GLOBAL_CTL MSR
are saved into the corresponding field.
The value of the SMBASE field is undefined after all VM exits except SMM VM exits. See Section 32.15.2.
28.3.2 Saving Segment Registers and Descriptor-Table Registers
For each segment register (CS, SS, DS, ES, FS, GS, LDTR, or TR), the values saved for the base-address, segment-
limit, and access rights are based on whether the register was unusable (see Section 25.4.1) before the VM exit:
Vol. 3C
28-23
VM EXITS
If the register was unusable, the values saved into the following fields are undefined: (1) base address;
(2) segment limit; and (3) bits 7:0 and bits 15:12 in the access-rights field. The following exceptions apply:
— CS.
The base-address and segment-limit fields are saved.
The L, D, and G bits are saved in the access-rights field.
— SS.
DPL is saved in the access-rights field.
On processors that support Intel 64 architecture, bits 63:32 of the value saved for the base address are
always zero.
— DS and ES. On processors that support Intel 64 architecture, bits 63:32 of the values saved for the base
addresses are always zero.
— FS and GS. The base-address field is saved.
— LDTR. The value saved for the base address is always canonical.
If the register was not unusable, the values saved into the following fields are those which were in the register
before the VM exit: (1) base address; (2) segment limit; and (3) bits 7:0 and bits 15:12 in access rights.
Bits 31:17 and 11:8 in the access-rights field are always cleared. Bit 16 is set to 1 if and only if the segment is
unusable.
The contents of the GDTR and IDTR registers are saved into the corresponding base-address and limit fields.
28.3.3 Saving RIP, RSP, RFLAGS, and SSP
The contents of the RIP, RSP, RFLAGS, and SSP (shadow-stack pointer) registers are saved as follows:
The value saved in the RIP field is determined by the nature and cause of the VM exit:
— If the VM exit occurred in enclave mode, the value saved is the AEP of interrupted enclave thread (the
remaining items do not apply).
— If the VM exit occurs due to by an attempt to execute an instruction that causes VM exits unconditionally or
that has been configured to cause a VM exit via the VM-execution controls, the value saved references that
instruction.
— If the VM exit is caused by an occurrence of an INIT signal, a start-up IPI (SIPI), or system-management
interrupt (SMI), the value saved is that which was in RIP before the event occurred.
— If the VM exit occurs due to the 1-setting of either the “interrupt-window exiting” VM-execution control or
the “NMI-window exiting” VM-execution control, the value saved is that which would be in the register had
the VM exit not occurred.
— If the VM exit is due to an external interrupt, non-maskable interrupt (NMI), or hardware exception (as
defined in Section 28.2.2), the value saved is the return pointer that would have been saved (either on the
stack had the event been delivered through a trap or interrupt gate,1 or into the old task-state segment had
the event been delivered through a task gate).
— If the VM exit is due to a triple fault, the value saved is the return pointer that would have been saved
(either on the stack had the event been delivered through a trap or interrupt gate, or into the old task-state
segment had the event been delivered through a task gate) had delivery of the double fault not
encountered the nested exception that caused the triple fault.
— If the VM exit is due to a software exception (due to an execution of INT3 or INTO) or a privileged software
exception (due to an execution of INT1), the value saved references the INT3, INTO, or INT1 instruction
that caused that exception.
1. The reference here is to the full value of RIP before any truncation that would occur had the stack width been only 32 bits or 16
bits.
28-24
Vol. 3C
VM EXITS
— Suppose that the VM exit is due to a task switch that was caused by execution of CALL, IRET, or JMP or by
execution of a software interrupt (INT n), software exception (due to execution of INT3 or INTO), or
privileged software exception (due to execution of INT1) that encountered a task gate in the IDT. The value
saved references the instruction that caused the task switch (CALL, IRET, JMP, INT n, INT3, INTO, INT1).
— Suppose that the VM exit is due to a task switch that was caused by a task gate in the IDT that was
encountered for any reason except the direct access by a software interrupt or software exception. The
value saved is that which would have been saved in the old task-state segment had the task switch
completed normally.
— If the VM exit is due to an execution of MOV to CR8 or WRMSR that reduced the value of bits 7:4 of VTPR
(see Section 30.1.1) below that of TPR threshold VM-execution control field (see Section 30.1.2), the value
saved references the instruction following the MOV to CR8 or WRMSR.
— If the VM exit was caused by APIC-write emulation (see Section 30.4.3.2) that results from an APIC access
as part of instruction execution, the value saved references the instruction following the one whose
execution caused the APIC-write emulation.
The contents of the RSP register are saved into the RSP field.
With the exception of the resume flag (RF; bit 16), the contents of the RFLAGS register is saved into the
RFLAGS field. RFLAGS.RF is saved as follows:
— If the VM exit occurred in enclave mode, the value saved is 0 (the remaining items do not apply).
— If the VM exit is caused directly by an event that would normally be delivered through the IDT, the value
saved is that which would appear in the saved RFLAGS image (either that which would be saved on the
stack had the event been delivered through a trap or interrupt gate1 or into the old task-state segment had
the event been delivered through a task gate) had the event been delivered through the IDT. See below for
VM exits due to task switches caused by task gates in the IDT.
— If the VM exit is caused by a triple fault, the value saved is that which the logical processor would have in
RF in the RFLAGS register had the triple fault taken the logical processor to the shutdown state.
— If the VM exit is caused by a task switch (including one caused by a task gate in the IDT), the value saved
is that which would have been saved in the RFLAGS image in the old task-state segment (TSS) had the task
switch completed normally without exception.
— If the VM exit is caused by an attempt to execute an instruction that unconditionally causes VM exits or one
that was configured to do with a VM-execution control, the value saved is 0.2
— For APIC-access VM exits and for VM exits caused by EPT violations, EPT misconfigurations, page-modifi-
cation log-full events, or SPP-related events, the value saved depends on whether the VM exit occurred
during delivery of an event through the IDT:
If the VM exit stored 0 for bit 31 for IDT-vectoring information field (because the VM exit did not occur
during delivery of an event through the IDT; see Section 28.2.4), the value saved is 1.
If the VM exit stored 1 for bit 31 for IDT-vectoring information field (because the VM exit did occur
during delivery of an event through the IDT), the value saved is the value that would have appeared in
the saved RFLAGS image had the event been delivered through the IDT (see above).
— For all other VM exits, the value saved is the value RFLAGS.RF had before the VM exit occurred.
If the processor supports the 1-setting of the “load CET” VM-entry control, the contents of the SSP register are
saved into the SSP field.
1. The reference here is to the full value of RFLAGS before any truncation that would occur had the stack width been only 32 bits or
16 bits.
2. This is true even if RFLAGS.RF was 1 before the instruction was executed. If, in response to such a VM exit, a VM monitor re-enters
the guest to re-execute the instruction that caused the VM exit (for example, after clearing the VM-execution control that caused
the VM exit), the instruction may encounter a code breakpoint that has already been processed. A VM monitor can avoid this by set-
ting the guest value of RFLAGS.RF to 1 before resuming guest software.
Vol. 3C
28-25
VM EXITS
28.3.4 Saving Non-Register State
Information corresponding to guest non-register state is saved as follows:
The activity-state field is saved with the logical processor’s activity state before the VM exit.1 See Section 28.1
for details of how events leading to a VM exit may affect the activity state. If the VM exit occurred during user-
interrupt notification processing (see Section 7.5.2) and the logical processor would have entered the HLT state
following user-interrupt notification processing, the saved activity state is “HLT”.
The interruptibility-state field is saved to reflect the logical processor’s interruptibility before the VM exit.
— See Section 28.1 for details of how events leading to a VM exit may affect this state.
— VM exits that end outside system-management mode (SMM) save bit 2 (blocking by SMI) as 0 regardless
of the state of such blocking before the VM exit.
— Bit 3 (blocking by NMI) is treated specially if the “virtual NMIs” VM-execution control is 1. In this case, the
value saved for this field does not indicate the blocking of NMIs but rather the state of virtual-NMI blocking.
— Bit 4 (enclave interruption) is set to 1 if the VM exit occurred while the logical processor was in enclave
mode.
Such VM exits includes those caused by interrupts, non-maskable interrupts, system-management
interrupts, INIT signals, and exceptions occurring in enclave mode as well as exceptions encountered
during the delivery of such events incident to enclave mode.
A VM exit that is incident to delivery of an event injected by VM entry leaves this bit unmodified.
The pending debug exceptions field is saved as clear for all VM exits except the following:
— A VM exit caused by an INIT signal, a machine-check exception, or a system-management interrupt (SMI).
— A VM exit with basic exit reason “TPR below threshold”,2 “virtualized EOI”, “APIC write”, “monitor trap flag,”
or “bus-lock detected.”
— A VM exit due to trace-address pre-translation (TAPT; see Section 26.5.4) or due to accesses related to
PEBS on processors with the “EPT-friendly” enhancement (see Section 20.9.5). Such VM exits can have
basic exit reason “APIC access,” “EPT violation,” “EPT misconfiguration,” “page-modification log full,” or
“SPP-related event.” When due to TAPT or PEBS, these VM exits (with the exception of those due to EPT
misconfigurations) set bit 16 of the exit qualification, indicating that they are asynchronous to instruction
execution and not part of event delivery.
— VM exits that are not caused by debug exceptions and that occur while there is MOV-SS blocking of debug
exceptions.
For VM exits that do not clear the field, the value saved is determined as follows:
— Each of bits 3:0 may be set if it corresponds to a matched breakpoint. This may be true even if the corre-
sponding breakpoint is not enabled in DR7.
— Suppose that a VM exit is due to an INIT signal, a machine-check exception, or an SMI; or that a VM exit
has basic exit reason “TPR below threshold” or “monitor trap flag.” In this case, the value saved sets bits
corresponding to the causes of any debug exceptions that were pending at the time of the VM exit.
If the VM exit occurs immediately after VM entry, the value saved may match that which was loaded on
VM entry (see Section 27.7.3). Otherwise, the following items apply:
Bit 12 (enabled breakpoint) is set to 1 in any of the following cases:
— If there was at least one matched data or I/O breakpoint that was enabled in DR7.
— If it had been set on VM entry, causing there to be valid pending debug exceptions (see Section
27.7.3) and the VM exit occurred before those exceptions were either delivered or lost.
— If the XBEGIN instruction was executed immediately before the VM exit and advanced debugging of
RTM transactional regions had been enabled (see Section 16.3.7, “RTM-Enabled Debugger
1.
If this activity state was an inactive state resulting from execution of a specific instruction (HLT or MWAIT), the value saved for RIP
by that VM exit will reference the following instruction.
2.
This item includes VM exits that occur as a result of certain VM entries (Section 27.7.7).
28-26
Vol. 3C
VM EXITS
Support,” of Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1). (This does
not apply to VM exits with basic exit reason “monitor trap flag.”)
— If a bus lock was asserted while CPL > 0 and OS bus-lock detection was enabled.
In other cases, bit 12 is cleared to 0.
Bit 14 (BS) is set if RFLAGS.TF = 1 in either of the following cases:
— IA32_DEBUGCTL.BTF = 0 and the cause of a pending debug exception was the execution of a single
instruction.
— IA32_DEBUGCTL.BTF = 1 and the cause of a pending debug exception was a taken branch.
Bit 16 (RTM) is set if a debug exception (#DB) or a breakpoint exception (#BP) occurred inside an RTM
region while advanced debugging of RTM transactional regions had been enabled. (This does not apply
to VM exits with basic exit reason “monitor trap flag.”)
— Suppose that a VM exit is due to another reason (but not a debug exception) and occurs while there is MOV-
SS blocking of debug exceptions. In this case, the value saved sets bits corresponding to the causes of any
debug exceptions that were pending at the time of the VM exit. If the VM exit occurs immediately after
VM entry (no instructions were executed in VMX non-root operation), the value saved may match that
which was loaded on VM entry (see Section 27.7.3). Otherwise, the following items apply:
Bit 12 (enabled breakpoint) is set to 1 if there was at least one matched data or I/O breakpoint that was
enabled in DR7. Bit 12 is also set if it had been set on VM entry, causing there to be valid pending debug
exceptions (see Section 27.7.3) and the VM exit occurred before those exceptions were either delivered
or lost. In other cases, bit 12 is cleared to 0.
The setting of bit 14 (BS) is implementation-specific. However, it is not set if RFLAGS.TF = 0 or
IA32_DEBUGCTL.BTF = 1.
— The reserved bits in the field are cleared.
If the “save VMX-preemption timer value” VM-exit control is 1, the value of timer is saved into the VMX-
preemption timer-value field. This is the value loaded from this field on VM entry as subsequently decremented
(see Section 26.5.1). VM exits due to timer expiration save the value 0. Other VM exits may also save the value
0 if the timer expired during VM exit. (If the “save VMX-preemption timer value” VM-exit control is 0, VM exit
does not modify the value of the VMX-preemption timer-value field.)
If the logical processor supports the 1-setting of the “enable EPT” VM-execution control, values are saved into
the four (4) PDPTE fields as follows:
— If the “enable EPT” VM-execution control is 1 and the logical processor was using PAE paging at the time of
the VM exit, the PDPTE values currently in use are saved:1
The values saved into bits 11:9 of each of the fields is undefined.
If the value saved into one of the fields has bit 0 (present) clear, the value saved into bits 63:1 of that
field is undefined. That value need not correspond to the value that was loaded by VM entry or to any
value that might have been loaded in VMX non-root operation.
If the value saved into one of the fields has bit 0 (present) set, the value saved into bits 63:12 of the
field is a guest-physical address.
— If the “enable EPT” VM-execution control is 0 or the logical processor was not using PAE paging at the time
of the VM exit, the values saved are undefined.
1. A logical processor uses PAE paging if CR0.PG = 1, CR4.PAE = 1 and IA32_EFER.LMA = 0. See Section 4.4 in the Intel® 64 and IA-32
Architectures Software Developer’s Manual, Volume 3A. “Enable EPT” is a secondary processor-based VM-execution control. If bit 31
of the primary processor-based VM-execution controls is 0, VM exit functions as if the “enable EPT” VM-execution control were 0.
See Section 25.6.2.
Vol. 3C
28-27
VM EXITS
28.4
SAVING MSRS
After processor state is saved to the guest-state area, values of MSRs may be stored into the VM-exit MSR-store
area (see Section 25.7.2). Specifically each entry in that area (up to the number specified in the VM-exit MSR-store
count) is processed in order by storing the value of the MSR indexed by bits 31:0 (as they would be read by
RDMSR) into bits 127:64. Processing of an entry fails in either of the following cases:
The value of bits 31:8 is 000008H, meaning that the indexed MSR is one that allows access to an APIC register
when the local APIC is in x2APIC mode.
The value of bits 31:0 indicates an MSR that can be read only in system-management mode (SMM) and the
VM exit will not end in SMM. (IA32_SMBASE is an MSR that can be read only in SMM.)
The value of bits 31:0 indicates an MSR that cannot be saved on VM exits for model-specific reasons. A
processor may prevent certain MSRs (based on the value of bits 31:0) from being stored on VM exits, even if
they can normally be read by RDMSR. Such model-specific behavior is documented in Chapter 2, “Model-
Specific Registers (MSRs)‚” in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 4.
Bits 63:32 of the entry are not all 0.
An attempt to read the MSR indexed by bits 31:0 would cause a general-protection exception if executed via
RDMSR with CPL = 0.
A VMX abort occurs if processing fails for any entry. See Section 28.7.
28.5
LOADING HOST STATE
Processor state is updated on VM exits in the following ways:
Some state is loaded from or otherwise determined by the contents of the host-state area.
Some state is determined by VM-exit controls.
Some state is established in the same way on every VM exit.
The page-directory pointers are loaded based on the values of certain control registers.
This loading may be performed in any order.
On processors that support Intel 64 architecture, the full values of each 64-bit field loaded (for example, the base
address for GDTR) is loaded regardless of the mode of the logical processor before and after the VM exit.
The loading of host state is detailed in Section 28.5.1 to Section 28.5.5. These sections reference VMCS fields that
correspond to processor state. Unless otherwise stated, these references are to fields in the host-state area.
A logical processor is in IA-32e mode after a VM exit only if the “host address-space size” VM-exit control is 1. If the
logical processor was in IA-32e mode before the VM exit and this control is 0, a VMX abort occurs. See Section
28.7.
In addition to loading host state, VM exits clear address-range monitoring (Section 28.5.6).
After the state loading described in this section, VM exits may load MSRs from the VM-exit MSR-load area (see
Section 28.6). This loading occurs only after the state loading described in this section.
28.5.1 Loading Host Control Registers, Debug Registers, MSRs
VM exits load new values for controls registers, debug registers, and some MSRs:
CR0, CR3, and CR4 are loaded from the CR0 field, the CR3 field, and the CR4 field, respectively, with the
following exceptions:
— The following bits are not modified:
For CR0, ET, CD, NW; bits 63:32 (on processors that support Intel 64 architecture), 28:19, 17, and
15:6; and any bits that are fixed in VMX operation (see Section 24.8).1
For CR3, bits 63:52 and bits in the range 51:32 beyond the processor’s physical-address width (they
are cleared to 0).2 (This item applies only to processors that support Intel 64 architecture.)
28-28
Vol. 3C
VM EXITS
For CR4, any bits that are fixed in VMX operation (see Section 24.8).
— CR4.PAE is set to 1 if the “host address-space size” VM-exit control is 1.
— CR4.PCIDE is set to 0 if the “host address-space size” VM-exit control is 0.
DR7 is set to 400H.
If the “clear UINV” VM-exit control is 1, VM exit clears UINV.
The following MSRs are established as follows:
— The IA32_DEBUGCTL MSR is cleared to 00000000_00000000H.
— The IA32_SYSENTER_CS MSR is loaded from the IA32_SYSENTER_CS field. Since that field has only 32
bits, bits 63:32 of the MSR are cleared to 0.
— The IA32_SYSENTER_ESP and IA32_SYSENTER_EIP MSRs are loaded from the IA32_SYSENTER_ESP and
IA32_SYSENTER_EIP fields, respectively.
If the processor does not support the Intel 64 architecture, these fields have only 32 bits; bits 63:32 of the
MSRs are cleared to 0.
If the processor supports the Intel 64 architecture with N < 64 linear-address bits, each of bits 63:N is set
to the value of bit N-1.1
— The following steps are performed on processors that support Intel 64 architecture:
The MSRs FS.base and GS.base are loaded from the base-address fields for FS and GS, respectively
(see Section 28.5.2).
The LMA and LME bits in the IA32_EFER MSR are each loaded with the setting of the “host address-
space size” VM-exit control.
— If the “load IA32_PERF_GLOBAL_CTRL” VM-exit control is 1, the IA32_PERF_GLOBAL_CTRL MSR is loaded
from the IA32_PERF_GLOBAL_CTRL field. Bits that are reserved in that MSR are maintained with their
reserved values.
— If the “load IA32_PAT” VM-exit control is 1, the IA32_PAT MSR is loaded from the IA32_PAT field. Bits that
are reserved in that MSR are maintained with their reserved values.
— If the “load IA32_EFER” VM-exit control is 1, the IA32_EFER MSR is loaded from the IA32_EFER field. Bits
that are reserved in that MSR are maintained with their reserved values.
— If the “clear IA32_BNDCFGS” VM-exit control is 1, the IA32_BNDCFGS MSR is cleared to
00000000_00000000H; otherwise, it is not modified.
— If the “clear IA32_RTIT_CTL” VM-exit control is 1, the IA32_RTIT_CTL MSR is cleared to
00000000_00000000H; otherwise, it is not modified.
— If the “load CET” VM-exit control is 1, the IA32_S_CET and IA32_INTERRUPT_SSP_TABLE_ADDR MSRs are
loaded from the IA32_S_CET and IA32_INTERRUPT_SSP_TABLE_ADDR fields, respectively.
If the processor does not support the Intel 64 architecture, these fields have only 32 bits; bits 63:32 of the
MSRs are cleared to 0.
If the processor supports the Intel 64 architecture with N < 64 linear-address bits, each of bits 63:N is set
to the value of bit N-1.
— If the “load PKRS” VM-exit control is 1, the IA32_PKRS MSR is loaded from the IA32_PKRS field. Bits 63:32
of that MSR are maintained with zeroes.
With the exception of FS.base and GS.base, any of these MSRs is subsequently overwritten if it appears in the
VM-exit MSR-load area. See Section 28.6.
1.
Bits 28:19, 17, and 15:6 of CR0 and CR0.ET are unchanged by executions of MOV to CR0. CR0.ET is always 1 and the other bits are
always 0.
2.
Software can determine a processor’s physical-address width by executing CPUID with 80000008H in EAX. The physical-address
width is returned in bits 7:0 of EAX.
1.
Software can determine the number N by executing CPUID with 80000008H in EAX. The number of linear-address bits supported is
returned in bits 15:8 of EAX.
Vol. 3C
28-29
VM EXITS
28.5.2 Loading Host Segment and Descriptor-Table Registers
Each of the registers CS, SS, DS, ES, FS, GS, and TR is loaded as follows (see below for the treatment of LDTR):
The selector is loaded from the selector field. The segment is unusable if its selector is loaded with zero. The
checks specified in Section 27.2.3 limit the selector values that may be loaded. In particular, CS and TR are
never loaded with zero and are thus never unusable. SS can be loaded with zero only on processors that
support Intel 64 architecture and only if the VM exit is to 64-bit mode (64-bit mode allows use of segments
marked unusable).
The base address is set as follows:
— CS. Cleared to zero.
— SS, DS, and ES. Undefined if the segment is unusable; otherwise, cleared to zero.
— FS and GS. Undefined (but, on processors that support Intel 64 architecture, canonical) if the segment is
unusable and the VM exit is not to 64-bit mode; otherwise, loaded from the base-address field.
If the processor supports the Intel 64 architecture and the processor supports N < 64 linear-address bits,
each of bits 63:N is set to the value of bit N-1.1 The values loaded for base addresses for FS and GS are
also manifest in the FS.base and GS.base MSRs.
— TR. Loaded from the host-state area. If the processor supports the Intel 64 architecture and the processor
supports N < 64 linear-address bits, each of bits 63:N is set to the value of bit N-1.
The segment limit is set as follows:
— CS. Set to FFFFFFFFH (corresponding to a descriptor limit of FFFFFH and a G-bit setting of 1).
— SS, DS, ES, FS, and GS. Undefined if the segment is unusable; otherwise, set to FFFFFFFFH.
— TR. Set to 00000067H.
The type field and S bit are set as follows:
— CS. Type set to 11 and S set to 1 (execute/read, accessed, non-conforming code segment).
— SS, DS, ES, FS, and GS. Undefined if the segment is unusable; otherwise, type set to 3 and S set to 1
(read/write, accessed, expand-up data segment).
— TR. Type set to 11 and S set to 0 (busy 32-bit task-state segment).
The DPL is set as follows:
— CS, SS, and TR. Set to 0. The current privilege level (CPL) will be 0 after the VM exit completes.
— DS, ES, FS, and GS. Undefined if the segment is unusable; otherwise, set to 0.
The P bit is set as follows:
— CS, TR. Set to 1.
— SS, DS, ES, FS, and GS. Undefined if the segment is unusable; otherwise, set to 1.
On processors that support Intel 64 architecture, CS.L is loaded with the setting of the “host address-space
size” VM-exit control. Because the value of this control is also loaded into IA32_EFER.LMA (see Section 28.5.1),
no VM exit is ever to compatibility mode (which requires IA32_EFER.LMA = 1 and CS.L = 0).
D/B.
— CS. Loaded with the inverse of the setting of the “host address-space size” VM-exit control. For example, if
that control is 0, indicating a 32-bit guest, CS.D/B is set to 1.
— SS. Set to 1.
— DS, ES, FS, and GS. Undefined if the segment is unusable; otherwise, set to 1.
— TR. Set to 0.
G.
1.
Software can determine the number N by executing CPUID with 80000008H in EAX. The number of linear-address bits supported is
returned in bits 15:8 of EAX.
28-30
Vol. 3C
VM EXITS
— CS. Set to 1.
— SS, DS, ES, FS, and GS. Undefined if the segment is unusable; otherwise, set to 1.
— TR. Set to 0.
The host-state area does not contain a selector field for LDTR. LDTR is established as follows on all VM exits: the
selector is cleared to 0000H, the segment is marked unusable and is otherwise undefined (although the base
address is always canonical).
The base addresses for GDTR and IDTR are loaded from the GDTR base-address field and the IDTR base-address
field, respectively. If the processor supports the Intel 64 architecture and the processor supports N < 64 linear-
address bits, each of bits 63:N of each base address is set to the value of bit N-1 of that base address. The GDTR
and IDTR limits are each set to FFFFH.
28.5.3 Loading Host RIP, RSP, RFLAGS, and SSP
RIP and RSP are loaded from the RIP field and the RSP field, respectively. RFLAGS is cleared, except bit 1, which is
always set.
If the “load CET” VM-exit control is 1, SSP (shadow-stack pointer) is loaded from the SSP field.
28.5.4 Checking and Loading Host Page-Directory-Pointer-Table Entries
If CR0.PG = 1, CR4.PAE = 1, and IA32_EFER.LMA = 0, the logical processor uses PAE paging. See Section 4.4 of
the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A.1 When in PAE paging is in use, the
physical address in CR3 references a table of page-directory-pointer-table entries (PDPTEs). A MOV to CR3
when PAE paging is in use checks the validity of the PDPTEs and, if they are valid, loads them into the processor
(into internal, non-architectural registers).
A VM exit is to a VMM that uses PAE paging if (1) bit 5 (corresponding to CR4.PAE) is set in the CR4 field in the
host-state area of the VMCS; and (2) the “host address-space size” VM-exit control is 0. Such a VM exit may check
the validity of the PDPTEs referenced by the CR3 field in the host-state area of the VMCS. Such a VM exit must
check their validity if either (1) PAE paging was not in use before the VM exit; or (2) the value of CR3 is changing
as a result of the VM exit. A VM exit to a VMM that does not use PAE paging must not check the validity of the
PDPTEs.
A VM exit that checks the validity of the PDPTEs uses the same checks that are used when CR3 is loaded with
MOV to CR3 when PAE paging is in use. If MOV to CR3 would cause a general-protection exception due to the
PDPTEs that would be loaded (e.g., because a reserved bit is set), a VMX abort occurs (see Section 28.7). If a
VM exit to a VMM that uses PAE does not cause a VMX abort, the PDPTEs are loaded into the processor as would
MOV to CR3, using the value of CR3 being load by the VM exit.
28.5.5 Updating Non-Register State
VM exits affect the non-register state of a logical processor as follows:
A logical processor is always in the active state after a VM exit.
Event blocking is affected as follows:
— There is no blocking by STI or by MOV SS after a VM exit.
— VM exits caused directly by non-maskable interrupts (NMIs) cause blocking by NMI (see Table 25-3). Other
VM exits do not affect blocking by NMI. (See Section 28.1 for the case in which an NMI causes a VM exit
indirectly.)
There are no pending debug exceptions after a VM exit.
1. On processors that support Intel 64 architecture, the physical-address extension may support more than 36 physical-address bits.
Software can determine a processor’s physical-address width by executing CPUID with 80000008H in EAX. The physical-address
width is returned in bits 7:0 of EAX.
Vol. 3C
28-31
VM EXITS
Section 29.4 describes how the VMX architecture controls how a logical processor manages information in the TLBs
and paging-structure caches. The following items detail how VM exits invalidate cached mappings:
If the “enable VPID” VM-execution control is 0, the logical processor invalidates linear mappings and combined
mappings associated with VPID 0000H (for all PCIDs); combined mappings for VPID 0000H are invalidated for
all EPTRTA values (EPTRTA is the value of bits 51:12 of EPTP).
VM exits are not required to invalidate any guest-physical mappings, nor are they required to invalidate any
linear mappings or combined mappings if the “enable VPID” VM-execution control is 1.
28.5.6 Clearing Address-Range Monitoring
The Intel 64 and IA-32 architectures allow software to monitor a specified address range using the MONITOR and
MWAIT instructions. See Section 9.10.4 in the Intel® 64 and IA-32 Architectures Software Developer’s Manual,
Volume 3A. VM exits clear any address-range monitoring that may be in effect.
28.6
LOADING MSRS
VM exits may load MSRs from the VM-exit MSR-load area (see Section 25.7.2). Specifically each entry in that area
(up to the number specified in the VM-exit MSR-load count) is processed in order by loading the MSR indexed by
bits 31:0 with the contents of bits 127:64 as they would be written by WRMSR.
Processing of an entry fails in any of the following cases:
The value of bits 31:0 is either C0000100H (the IA32_FS_BASE MSR) or C0000101H (the IA32_GS_BASE
MSR).
The value of bits 31:8 is 000008H, meaning that the indexed MSR is one that allows access to an APIC register
when the local APIC is in x2APIC mode.
The value of bits 31:0 indicates an MSR that can be written only in system-management mode (SMM) and the
VM exit will not end in SMM. (IA32_SMM_MONITOR_CTL is an MSR that can be written only in SMM.)
The value of bits 31:0 indicates an MSR that cannot be loaded on VM exits for model-specific reasons. A
processor may prevent loading of certain MSRs even if they can normally be written by WRMSR. Such model-
specific behavior is documented in Chapter 2, “Model-Specific Registers (MSRs)‚” in the Intel® 64 and IA-32
Architectures Software Developer’s Manual, Volume 4.
Bits 63:32 are not all 0.
An attempt to write bits 127:64 to the MSR indexed by bits 31:0 of the entry would cause a general-protection
exception if executed via WRMSR with CPL = 0.1
If processing fails for any entry, a VMX abort occurs. See Section 28.7.
If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so
that, after VM exit, the logical processor does not use any translations that were cached before the transition.
28.7
VMX ABORTS
A problem encountered during a VM exit leads to a VMX abort. A VMX abort takes a logical processor into a shut-
down state as described below.
A VMX abort does not modify the VMCS data in the VMCS region of any active VMCS. The contents of these data are
thus suspect after the VMX abort.
On a VMX abort, a logical processor saves a nonzero 32-bit VMX-abort indicator field at byte offset 4 in the VMCS
region of the VMCS whose misconfiguration caused the failure (see Section 25.2). The following values are used:
1. Note the following about processors that support Intel 64 architecture. If CR0.PG = 1, WRMSR to the IA32_EFER MSR causes a gen-
eral-protection exception if it would modify the LME bit. Since CR0.PG is always 1 in VMX operation, the IA32_EFER MSR should not
be included in the VM-exit MSR-load area for the purpose of modifying the LME bit.
28-32
Vol. 3C
VM EXITS
1. There was a failure in saving guest MSRs (see Section 28.4).
2. Host checking of the page-directory-pointer-table entries (PDPTEs) failed (see Section 28.5.4).
3. The current VMCS has been corrupted (through writes to the corresponding VMCS region) in such a way that
the logical processor cannot complete the VM exit properly.
4. There was a failure on loading host MSRs (see Section 28.6).
5. There was a machine-check event during VM exit (see Section 28.8).
6. The logical processor was in IA-32e mode before the VM exit and the “host address-space size” VM-exit control
was 0 (see Section 28.5).
Some of these causes correspond to failures during the loading of state from the host-state area. Because the
loading of such state may be done in any order (see Section 28.5) a VM exit that might lead to a VMX abort for
multiple reasons (for example, the current VMCS may be corrupt and the host PDPTEs might not be properly
configured). In such cases, the VMX-abort indicator could correspond to any one of those reasons.
A logical processor never reads the VMX-abort indicator in a VMCS region and writes it only with one of the non-
zero values mentioned above. The VMX-abort indicator allows software on one logical processor to diagnose the
VMX-abort on another. For this reason, it is recommended that software running in VMX root operation zero the
VMX-abort indicator in the VMCS region of any VMCS that it uses.
After saving the VMX-abort indicator, operation of a logical processor experiencing a VMX abort depends on
whether the logical processor is in SMX operation:1
If the logical processor is in SMX operation, an Intel® TXT shutdown condition occurs. The error code used is
000DH, indicating “VMX abort.” See the Intel® Trusted Execution Technology Measured Launched Environment
Programming Guide.
If the logical processor is outside SMX operation, it issues a special bus cycle (to notify the chipset) and enters
the VMX-abort shutdown state. RESET is the only event that wakes a logical processor from the VMX-abort
shutdown state. The following events do not affect a logical processor in this state: machine-check events;
INIT signals; external interrupts; non-maskable interrupts (NMIs); start-up IPIs (SIPIs); and system-
management interrupts (SMIs).
28.8
MACHINE-CHECK EVENTS DURING VM EXIT
If a machine-check event occurs during VM exit, one of the following occurs:
The machine-check event is handled as if it occurred before the VM exit:
— If CR4.MCE = 0, operation of the logical processor depends on whether the logical processor is in SMX
operation:1
If the logical processor is in SMX operation, an Intel® TXT shutdown condition occurs. The error code
used is 000CH, indicating “unrecoverable machine-check condition.”
If the logical processor is outside SMX operation, it goes to the shutdown state.
— If CR4.MCE = 1, a machine-check exception (#MC) is generated:
If bit 18 (#MC) of the exception bitmap is 0, the exception is delivered through the guest IDT.
If bit 18 of the exception bitmap is 1, the exception causes a VM exit.
The machine-check event is handled after VM exit completes:
— If the VM exit ends with CR4.MCE = 0, operation of the logical processor depends on whether the logical
processor is in SMX operation:
1. A logical processor is in SMX operation if GETSEC[SEXIT] has not been executed since the last execution of GETSEC[SENTER]. A logi-
cal processor is outside SMX operation if GETSEC[SENTER] has not been executed or if GETSEC[SEXIT] was executed after the last
execution of GETSEC[SENTER]. See Chapter 7, “Safer Mode Extensions Reference‚” in Intel® 64 and IA-32 Architectures Software
Developer’s Manual, Volume 2D.
Vol. 3C
28-33
VM EXITS
If the logical processor is in SMX operation, an Intel® TXT shutdown condition occurs with error code
000CH (unrecoverable machine-check condition).
If the logical processor is outside SMX operation, it goes to the shutdown state.
— If the VM exit ends with CR4.MCE = 1, a machine-check exception (#MC) is delivered through the host IDT.
A VMX abort is generated (see Section 28.7). The logical processor blocks events as done normally in
VMX abort. The VMX abort indicator is 5, for “machine-check event during VM exit.”
The first option is not used if the machine-check event occurs after any host state has been loaded. The second
option is used only if VM entry is able to load all host state.
28.9
USER-INTERRUPT RECOGNITION AFTER VM EXIT
A VM exit results in recognition of a pending user interrupt if it completes with CR4.UINTR = IA32_EFER.LMA = 1
and with UIRR 0; otherwise, no pending user interrupt is recognized.
28-34
Vol. 3C
CHAPTER 29
VMX SUPPORT FOR ADDRESS TRANSLATION
The architecture for VMX operation includes two features that support address translation: virtual-processor iden-
tifiers (VPIDs) and the extended page-table mechanism (EPT). VPIDs are a mechanism for managing translations
of linear addresses. EPT defines a layer of address translation that augments the translation of linear addresses.
Section 29.1 details the architecture of VPIDs. Section 29.3 provides the details of EPT. Section 29.4 explains how
a logical processor may cache information from the paging structures, how it may use that cached information, and
how software can managed the cached information.
29.1
VIRTUAL PROCESSOR IDENTIFIERS (VPIDS)
The original architecture for VMX operation required VMX transitions to flush the TLBs and paging-structure caches.
This ensured that translations cached for the old linear-address space would not be used after the transition.
Virtual-processor identifiers (VPIDs) introduce to VMX operation a facility by which a logical processor may cache
information for multiple linear-address spaces. When VPIDs are used, VMX transitions may retain cached informa-
tion and the logical processor switches to a different linear-address space.
Section 29.4 details the mechanisms by which a logical processor manages information cached for multiple address
spaces. A logical processor may tag some cached information with a 16-bit VPID. This section specifies how the
current VPID is determined at any point in time:
The current VPID is 0000H in the following situations:
— Outside VMX operation. (This includes operation in system-management mode under the default treatment
of SMIs and SMM with VMX operation; see Section 32.14.)
— In VMX root operation.
— In VMX non-root operation when the “enable VPID” VM-execution control is 0.
If the logical processor is in VMX non-root operation and the “enable VPID” VM-execution control is 1, the
current VPID is the value of the VPID VM-execution control field in the VMCS. (VM entry ensures that this value
is never 0000H; see Section 27.2.1.1.)
VPIDs and PCIDs (see Section 4.10.1) can be used concurrently. When this is done, the processor associates
cached information with both a VPID and a PCID. Such information is used only if the current VPID and PCID both
match those associated with the cached information.
29.2
HYPERVISOR-MANAGED LINEAR-ADDRESS TRANSLATION (HLAT)
Hypervisor-managed linear-address translation (HLAT) is a feature that changes the way in which linear
addresses are translated in VMX non-root operation. Instead of ordinary paging, translation uses a modified
process called HLAT paging.
HLAT paging is used only if the “enable HLAT” VM-execution control is 1. HLAT paging is used only for the paging
modes 4-level paging and 5-level paging. Because HLAT paging is a modification of ordinary paging, details of the
feature are given in Section 4.5, which describes the operation of 4-level paging and 5-level paging.
29.3
THE EXTENDED PAGE TABLE MECHANISM (EPT)
The extended page-table mechanism (EPT) is a feature that can be used to support the virtualization of physical
memory. When EPT is in use, certain addresses that would normally be treated as physical addresses (and used to
access memory) are instead treated as guest-physical addresses. Guest-physical addresses are translated by
traversing a set of EPT paging structures to produce physical addresses that are used to access memory.
Vol. 3C
29-1
VMX SUPPORT FOR ADDRESS TRANSLATION
Section 29.3.1 gives an overview of EPT.
Section 29.3.2 describes operation of EPT-based address translation.
Section 29.3.3 discusses VM exits that may be caused by EPT.
Section 29.3.7 describes interactions between EPT and memory typing.
29.3.1 EPT Overview
EPT is used when the “enable EPT” VM-execution control is 1.1 It translates the guest-physical addresses used in
VMX non-root operation and those used by VM entry for event injection.
The translation from guest-physical addresses to physical addresses is determined by a set of EPT paging struc-
tures. The EPT paging structures are similar to those used to translate linear addresses while the processor is in
IA-32e mode. Section 29.3.2 gives the details of the EPT paging structures.
If CR0.PG = 1, linear addresses are translated through paging structures referenced through control register CR3.2
While the “enable EPT” VM-execution control is 1, these are called guest paging structures. There are no guest
paging structures if CR0.PG = 0.3
When the “enable EPT” VM-execution control is 1, the identity of guest-physical addresses depends on the value
of CR0.PG:
If CR0.PG = 0, each linear address is treated as a guest-physical address.
If CR0.PG = 1, guest-physical addresses are those derived from the contents of control register CR3 and the
guest paging structures. (This includes the values of the PDPTEs, which logical processors store in internal,
non-architectural registers.) The latter includes (in page-table entries and in other paging-structure entries for
which bit 7—PS—is 1) the addresses to which linear addresses are translated by the guest paging structures.
If CR0.PG = 1, the translation of a linear address to a physical address requires multiple translations of guest-phys-
ical addresses using EPT. Assume, for example, that CR4.PAE = CR4.PSE = 0. The translation of a 32-bit linear
address then operates as follows:
Bits 31:22 of the linear address select an entry in the guest page directory located at the guest-physical
address in CR3. The guest-physical address of the guest page-directory entry (PDE) is translated through EPT
to determine the guest PDE’s physical address.
Bits 21:12 of the linear address select an entry in the guest page table located at the guest-physical address in
the guest PDE. The guest-physical address of the guest page-table entry (PTE) is translated through EPT to
determine the guest PTE’s physical address.
Bits 11:0 of the linear address is the offset in the page frame located at the guest-physical address in the guest
PTE. The guest-physical address determined by this offset is translated through EPT to determine the physical
address to which the original linear address translates.
In addition to translating a guest-physical address to a physical address, EPT specifies the privileges that software
is allowed when accessing the address. Attempts at disallowed accesses are called EPT violations and cause
VM exits. See Section 29.3.3.
A processor uses EPT to translate guest-physical addresses only when those addresses are used to access memory.
This principle implies the following:
The MOV to CR3 instruction loads CR3 with a guest-physical address. Whether that address is translated
through EPT depends on whether PAE paging is being used.4
1.
“Enable EPT” is a secondary processor-based VM-execution control. If bit 31 of the primary processor-based VM-execution controls
is 0, the logical processor operates as if the “enable EPT” VM-execution control were 0. See Section 25.6.2.
2. If HLAT paging is enabled, the processor uses the HLATP VMCS field instead of CR3. See Section 4.5.1. For simplicity, the remainder
of this section refers only to CR3.
3. If the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PG must be 1 in VMX operation, CR0.PG can be 0 in VMX non-root
operation only if the “unrestricted guest” VM-execution control and bit 31 of the primary processor-based VM-execution controls are
both 1.
4. A logical processor uses PAE paging if CR0.PG = 1, CR4.PAE = 1 and IA32_EFER.LMA = 0. See Section 4.4 in the Intel® 64 and IA-32
Architectures Software Developer’s Manual, Volume 3A.
29-2
Vol. 3C
VMX SUPPORT FOR ADDRESS TRANSLATION
— If PAE paging is not being used, the instruction does not use that address to access memory and does not
cause it to be translated through EPT. (If CR0.PG = 1, the address will be translated through EPT on the
next memory accessing using a linear address.)
— If PAE paging is being used, the instruction loads the four (4) page-directory-pointer-table entries (PDPTEs)
from that address and it does cause the address to be translated through EPT.
Section 4.4.1 identifies executions of MOV to CR0 and MOV to CR4 that load the PDPTEs from the guest-
physical address in CR3. Such executions cause that address to be translated through EPT.
The PDPTEs contain guest-physical addresses. The instructions that load the PDPTEs (see above) do not use
those addresses to access memory and do not cause them to be translated through EPT. The address in a
PDPTE will be translated through EPT on the next memory accessing using a linear address that uses that
PDPTE.
29.3.2 EPT Translation Mechanism
The EPT translation mechanism can be configured in either of two modes: 4-level EPT or 5-level EPT. 4-level EPT
accesses at most 4 EPT paging-structure entries (an EPT page-walk length of 4) to translate a guest-physical
address and uses only bits 47:0 of each guest-physical address. In contrast, 5-level EPT may access up to 5 EPT
paging-structure entries (an EPT page-walk length of 5) and uses guest-physical address bits 56:0.1
The EPT page-walk length is configured using the extended-page-table pointer (EPTP), a VM-execution control field
(see Table 25-9 in Section 25.6.11). Specifically, bits 5:3 contain a value one less than EPT page-walk length.
Thus, a value of 3 configures 4-level EPT, while a value of 4 configures 5-level EPT.2
The remainder of this section describes the translation process used by 4-level EPT and 5-level EPT. Because the
processes used by the two EPT modes are similar, they are described together in the following items (with any
differences identified):
With 5-level EPT, 4-KByte naturally aligned EPT PML5 table is located at the physical address specified in
bits 51:12 of the EPTP. An EPT PML5 table comprises 512 64-bit entries (EPT PML5Es). An EPT PML5E is
selected using the physical address defined as follows:
— Bits 63:52 are all 0.
— Bits 51:12 are from the EPTP.
— Bits 11:3 are bits 56:48 of the guest-physical address.3
— Bits 2:0 are all 0.
Because an EPT PML5E is identified using bits 56:48 of the guest-physical address, it controls access to a 256-
TByte region of the guest-physical-address space. The format of an EPT PML5E is given in Table 29-1.
With 4-level EPT, bits 51:48 of the guest-physical address must all be zero; otherwise, an EPT violation occurs
(see Section 29.3.3).
A 4-KByte naturally aligned EPT PML4 table is located at the physical address specified in the EPTP (for 4-level
EPT) or in the EPT PML5E (for 5-level EPT). An EPT PML4 table comprises 512 64-bit entries (EPT PML4Es). An
EPT PML4E is selected using the physical address defined as follows:
— Bits 63:52 are all 0.
— Bits 51:12 are from the EPTP (for 4-level EPT) or from bits 51:12 of the EPT PML4E (for 5-level EPT).
— Bits 11:3 are bits 47:39 of the guest-physical address.
— Bits 2:0 are all 0.
1.
Physical addresses and guest-physical addresses are architecturally limited to 52 bits (e.g., by paging), so in practice bits 56:52 are
zero.
2.
Software should read the VMX capability MSR IA32_VMX_EPT_VPID_CAP (see Appendix A.10) to determine what EPT page-walk
lengths are supported.
3.
Bits 56:52 of each guest-physical address are necessarily zero because guest-physical addresses are architecturally limited to 52
bits.
Vol. 3C
29-3
VMX SUPPORT FOR ADDRESS TRANSLATION
Table 29-1. Format of an EPT PML5 Entry (PML5E) that References an EPT PML4 Table
Bit
Contents
Position(s)
0
Read access; indicates whether reads are allowed from the 256-TByte region controlled by this entry.
1
Write access; indicates whether writes are allowed to the 256-TByte region controlled by this entry.
2
If the “mode-based execute control for EPT” VM-execution control is 0, execute access; indicates whether instruction
fetches are allowed from the 256-TByte region controlled by this entry.
If that control is 1, execute access for supervisor-mode linear addresses; indicates whether instruction fetches are
allowed from supervisor-mode linear addresses in the 256-TByte region controlled by this entry.
7:3
Reserved (must be 0).
8
If bit 6 of EPTP is 1, accessed flag for EPT; indicates whether software has accessed the 256-TByte region
controlled by this entry (see Section 29.3.5). Ignored if bit 6 of EPTP is 0.
9
Ignored.
10
Execute access for user-mode linear addresses. If the “mode-based execute control for EPT” VM-execution control is
1, indicates whether instruction fetches are allowed from user-mode linear addresses in the 256-TByte region
controlled by this entry. If that control is 0, this bit is ignored.
11
Ignored.
(N-1):12
Physical address of 4-KByte aligned EPT PML4 table referenced by this entry.1
51:N
Reserved (must be 0).
63:52
Ignored.
NOTES:
1. N is the physical-address width supported by the processor. Software can determine a processor’s physical-address width by execut-
ing CPUID with 80000008H in EAX. The physical-address width is returned in bits 7:0 of EAX.
Because an EPT PML4E is identified using bits 47:39 of the guest-physical address, it controls access to a 512-
GByte region of the guest-physical-address space. The format of an EPT PML4E is given in Table 29-2.
A 4-KByte naturally aligned EPT page-directory-pointer table is located at the physical address specified in
bits 51:12 of the EPT PML4E. An EPT page-directory-pointer table comprises 512 64-bit entries (EPT PDPTEs).
An EPT PDPTE is selected using the physical address defined as follows:
— Bits 63:52 are all 0.
— Bits 51:12 are from the EPT PML4E.
— Bits 11:3 are bits 38:30 of the guest-physical address.
— Bits 2:0 are all 0.
Because an EPT PDPTE is identified using bits 47:30 of the guest-physical address, it controls access to a 1-GByte
region of the guest-physical-address space. Use of the EPT PDPTE depends on the value of bit 7 in that entry:1
If bit 7 of the EPT PDPTE is 1, the EPT PDPTE maps a 1-GByte page. The final physical address is computed as
follows:
— Bits 63:52 are all 0.
— Bits 51:30 are from the EPT PDPTE.
— Bits 29:0 are from the original guest-physical address.
1. Not all processors allow bit 7 of an EPT PDPTE to be set to 1. Software should read the VMX capability MSR IA32_VMX_EPT_VPID_-
CAP (see Appendix A.10) to determine whether this is allowed.
29-4
Vol. 3C
VMX SUPPORT FOR ADDRESS TRANSLATION
Table 29-2. Format of an EPT PML4 Entry (PML4E) that References an EPT Page-Directory-Pointer Table
Bit
Contents
Position(s)
0
Read access; indicates whether reads are allowed from the 512-GByte region controlled by this entry.
1
Write access; indicates whether writes are allowed to the 512-GByte region controlled by this entry.
2
If the “mode-based execute control for EPT” VM-execution control is 0, execute access; indicates whether instruction
fetches are allowed from the 512-GByte region controlled by this entry.
If that control is 1, execute access for supervisor-mode linear addresses; indicates whether instruction fetches are
allowed from supervisor-mode linear addresses in the 512-GByte region controlled by this entry.
7:3
Reserved (must be 0).
8
If bit 6 of EPTP is 1, accessed flag for EPT; indicates whether software has accessed the 512-GByte region
controlled by this entry (see Section 29.3.5). Ignored if bit 6 of EPTP is 0.
9
Ignored.
10
Execute access for user-mode linear addresses. If the “mode-based execute control for EPT” VM-execution control is
1, indicates whether instruction fetches are allowed from user-mode linear addresses in the 512-GByte region
controlled by this entry. If that control is 0, this bit is ignored.
11
Ignored.
(N-1):12
Physical address of 4-KByte aligned EPT page-directory-pointer table referenced by this entry.1
51:N
Reserved (must be 0).
63:52
Ignored.
NOTES:
1. N is the physical-address width supported by the processor.
The format of an EPT PDPTE that maps a 1-GByte page is given in Table 29-3.
If bit 7 of the EPT PDPTE is 0, a 4-KByte naturally aligned EPT page directory is located at the physical address
specified in bits 51:12 of the EPT PDPTE. The format of an EPT PDPTE that references an EPT page directory is
given in Table 29-4.
Vol. 3C
29-5
VMX SUPPORT FOR ADDRESS TRANSLATION
Table 29-3. Format of an EPT Page-Directory-Pointer-Table Entry (PDPTE) that Maps a 1-GByte Page
Bit
Contents
Position(s)
0
Read access; indicates whether reads are allowed from the 1-GByte page referenced by this entry.
1
Write access; indicates whether writes are allowed to the 1-GByte page referenced by this entry.
2
If the “mode-based execute control for EPT” VM-execution control is 0, execute access; indicates whether
instruction fetches are allowed from the 1-GByte page controlled by this entry.
If that control is 1, execute access for supervisor-mode linear addresses; indicates whether instruction fetches are
allowed from supervisor-mode linear addresses in the 1-GByte page controlled by this entry.
5:3
EPT memory type for this 1-GByte page (see Section 29.3.7).
6
Ignore PAT memory type for this 1-GByte page (see Section 29.3.7).
7
Must be 1 (otherwise, this entry references an EPT page directory).
8
If bit 6 of EPTP is 1, accessed flag for EPT; indicates whether software has accessed the 1-GByte page referenced
by this entry (see Section 29.3.5). Ignored if bit 6 of EPTP is 0.
9
If bit 6 of EPTP is 1, dirty flag for EPT; indicates whether software has written to the 1-GByte page referenced by
this entry (see Section 29.3.5). Ignored if bit 6 of EPTP is 0.
10
Execute access for user-mode linear addresses. If the “mode-based execute control for EPT” VM-execution control is
1, indicates whether instruction fetches are allowed from user-mode linear addresses in the 1-GByte page controlled
by this entry. If that control is 0, this bit is ignored.
11
Ignored.
29:12
Reserved (must be 0).
(N-1):30
Physical address of the 1-GByte page referenced by this entry.1
51:N
Reserved (must be 0).
56:52
Ignored.
57
Verify guest paging. If the “guest-paging verification” VM-execution control is 1, indicates limits on the guest paging
structures used to access the 1-GByte page controlled by this entry (see Section 29.3.3.2). If that control is 0, this
bit is ignored.
58
Paging-write access. If the “EPT paging-write control” VM-execution control is 1, indicates that guest paging may
update the 1-GByte page controlled by this entry (see Section 29.3.3.2). If that control is 0, this bit is ignored.
59
Ignored.
60
Supervisor shadow stack. If bit 7 of EPTP is 1, indicates whether supervisor shadow stack accesses are allowed to
guest-physical addresses in the 1-GByte page mapped by this entry (see Section 29.3.3.2).
Ignored if bit 7 of EPTP is 0.
62:61
Ignored.
63
Suppress #VE. If the “EPT-violation #VE” VM-execution control is 1, EPT violations caused by accesses to this page
are convertible to virtualization exceptions only if this bit is 0 (see Section 26.5.7.1). If “EPT-violation #VE” VM-
execution control is 0, this bit is ignored.
NOTES:
1. N is the physical-address width supported by the processor.
29-6
Vol. 3C
VMX SUPPORT FOR ADDRESS TRANSLATION
Table 29-4. Format of an EPT Page-Directory-Pointer-Table Entry (PDPTE) that References an EPT Page Directory
Bit
Contents
Position(s)
0
Read access; indicates whether reads are allowed from the 1-GByte region controlled by this entry.
1
Write access; indicates whether writes are allowed to the 1-GByte region controlled by this entry.
2
If the “mode-based execute control for EPT” VM-execution control is 0, execute access; indicates whether instruction
fetches are allowed from the 1-GByte region controlled by this entry.
If that control is 1, execute access for supervisor-mode linear addresses; indicates whether instruction fetches are
allowed from supervisor-mode linear addresses in the 1-GByte region controlled by this entry.
7:3
Reserved (must be 0).
8
If bit 6 of EPTP is 1, accessed flag for EPT; indicates whether software has accessed the 1-GByte region controlled
by this entry (see Section 29.3.5). Ignored if bit 6 of EPTP is 0.
9
Ignored.
10
Execute access for user-mode linear addresses. If the “mode-based execute control for EPT” VM-execution control is
1, indicates whether instruction fetches are allowed from user-mode linear addresses in the 1-GByte region
controlled by this entry. If that control is 0, this bit is ignored.
11
Ignored.
(N-1):12
Physical address of 4-KByte aligned EPT page directory referenced by this entry.1
51:N
Reserved (must be 0).
63:52
Ignored.
NOTES:
1. N is the physical-address width supported by the processor.
An EPT page-directory comprises 512 64-bit entries (PDEs). An EPT PDE is selected using the physical address
defined as follows:
— Bits 63:52 are all 0.
— Bits 51:12 are from the EPT PDPTE.
— Bits 11:3 are bits 29:21 of the guest-physical address.
— Bits 2:0 are all 0.
Because an EPT PDE is identified using bits 47:21 of the guest-physical address, it controls access to a 2-MByte
region of the guest-physical-address space. Use of the EPT PDE depends on the value of bit 7 in that entry:
If bit 7 of the EPT PDE is 1, the EPT PDE maps a 2-MByte page. The final physical address is computed as
follows:
— Bits 63:52 are all 0.
— Bits 51:21 are from the EPT PDE.
— Bits 20:0 are from the original guest-physical address.
The format of an EPT PDE that maps a 2-MByte page is given in Table 29-5.
If bit 7 of the EPT PDE is 0, a 4-KByte naturally aligned EPT page table is located at the physical address
specified in bits 51:12 of the EPT PDE. The format of an EPT PDE that references an EPT page table is given in
Table 29-6.
An EPT page table comprises 512 64-bit entries (PTEs). An EPT PTE is selected using a physical address defined
as follows:
— Bits 63:52 are all 0.
Vol. 3C
29-7
VMX SUPPORT FOR ADDRESS TRANSLATION
Table 29-5. Format of an EPT Page-Directory Entry (PDE) that Maps a 2-MByte Page
Bit
Contents
Position(s)
0
Read access; indicates whether reads are allowed from the 2-MByte page referenced by this entry.
1
Write access; indicates whether writes are allowed to the 2-MByte page referenced by this entry.
2
If the “mode-based execute control for EPT” VM-execution control is 0, execute access; indicates whether instruction
fetches are allowed from the 2-MByte page controlled by this entry.
If that control is 1, execute access for supervisor-mode linear addresses; indicates whether instruction fetches are
allowed from supervisor-mode linear addresses in the 2-MByte page controlled by this entry.
5:3
EPT memory type for this 2-MByte page (see Section 29.3.7).
6
Ignore PAT memory type for this 2-MByte page (see Section 29.3.7).
7
Must be 1 (otherwise, this entry references an EPT page table).
8
If bit 6 of EPTP is 1, accessed flag for EPT; indicates whether software has accessed the 2-MByte page referenced
by this entry (see Section 29.3.5). Ignored if bit 6 of EPTP is 0.
9
If bit 6 of EPTP is 1, dirty flag for EPT; indicates whether software has written to the 2-MByte page referenced by
this entry (see Section 29.3.5). Ignored if bit 6 of EPTP is 0.
10
Execute access for user-mode linear addresses. If the “mode-based execute control for EPT” VM-execution control is
1, indicates whether instruction fetches are allowed from user-mode linear addresses in the 2-MByte page controlled
by this entry. If that control is 0, this bit is ignored.
11
Ignored.
20:12
Reserved (must be 0).
(N-1):21
Physical address of the 2-MByte page referenced by this entry.1
51:N
Reserved (must be 0).
56:52
Ignored.
57
Verify guest paging. If the “guest-paging verification” VM-execution control is 1, indicates limits on the guest paging
structures used to access the 2-MByte page controlled by this entry (see Section 29.3.3.2). If that control is 0, this
bit is ignored.
58
Paging-write access. If the “EPT paging-write control” VM-execution control is 1, indicates that guest paging may
update the 2-MByte page controlled by this entry (see Section 29.3.3.2). If that control is 0, this bit is ignored.
59
Ignored.
60
Supervisor shadow stack. If bit 7 of EPTP is 1, indicates whether supervisor shadow stack accesses are allowed to
guest-physical addresses in the 2-MByte page mapped by this entry (see Section 29.3.3.2).
Ignored if bit 7 of EPTP is 0.
62:61
Ignored.
63
Suppress #VE. If the “EPT-violation #VE” VM-execution control is 1, EPT violations caused by accesses to this page
are convertible to virtualization exceptions only if this bit is 0 (see Section 26.5.7.1). If “EPT-violation #VE” VM-
execution control is 0, this bit is ignored.
NOTES:
1. N is the physical-address width supported by the processor.
— Bits 51:12 are from the EPT PDE.
29-8
Vol. 3C
VMX SUPPORT FOR ADDRESS TRANSLATION
— Bits 11:3 are bits 20:12 of the guest-physical address.
— Bits 2:0 are all 0.
Because an EPT PTE is identified using bits 47:12 of the guest-physical address, every EPT PTE maps a 4-KByte
page. The final physical address is computed as follows:
— Bits 63:52 are all 0.
— Bits 51:12 are from the EPT PTE.
— Bits 11:0 are from the original guest-physical address.
The format of an EPT PTE is given in Table 29-7.
An EPT paging-structure entry is present if any of bits 2:0 is 1; otherwise, the entry is not present. The processor
ignores bits 62:3 and uses the entry neither to reference another EPT paging-structure entry nor to produce a
physical address. A reference using a guest-physical address whose translation encounters an EPT paging-struc-
ture that is not present causes an EPT violation (see Section 29.3.3.2). (If the “EPT-violation #VE” VM-execution
control is 1, the EPT violation is convertible to a virtualization exception only if bit 63 is 0; see Section 26.5.7.1. If
the “EPT-violation #VE” VM-execution control is 0, this bit is ignored.)
Table 29-6. Format of an EPT Page-Directory Entry (PDE) that References an EPT Page Table
Bit
Contents
Position(s)
0
Read access; indicates whether reads are allowed from the 2-MByte region controlled by this entry.
1
Write access; indicates whether writes are allowed to the 2-MByte region controlled by this entry.
2
If the “mode-based execute control for EPT” VM-execution control is 0, execute access; indicates whether instruction
fetches are allowed from the 2-MByte region controlled by this entry.
If that control is 1, execute access for supervisor-mode linear addresses; indicates whether instruction fetches are
allowed from supervisor-mode linear addresses in the 2-MByte region controlled by this entry.
6:3
Reserved (must be 0).
7
Must be 0 (otherwise, this entry maps a 2-MByte page).
8
If bit 6 of EPTP is 1, accessed flag for EPT; indicates whether software has accessed the 2-MByte region controlled
by this entry (see Section 29.3.5). Ignored if bit 6 of EPTP is 0.
9
Ignored.
10
Execute access for user-mode linear addresses. If the “mode-based execute control for EPT” VM-execution control is
1, indicates whether instruction fetches are allowed from user-mode linear addresses in the 2-MByte region
controlled by this entry. If that control is 0, this bit is ignored.
11
Ignored.
(N-1):12
Physical address of 4-KByte aligned EPT page table referenced by this entry.1
51:N
Reserved (must be 0).
63:52
Ignored.
NOTES:
1. N is the physical-address width supported by the processor.
NOTE
If the “mode-based execute control for EPT” VM-execution control is 1, an EPT paging-structure
entry is present if any of bits 2:0 or bit 10 is 1. If bits 2:0 are all 0 but bit 10 is 1, the entry is used
normally to reference another EPT paging-structure entry or to produce a physical address.
Vol. 3C
29-9
VMX SUPPORT FOR ADDRESS TRANSLATION
The discussion above describes how the EPT paging structures reference each other and how the logical processor
traverses those structures when translating a guest-physical address. It does not cover all details of the translation
process. Additional details are provided as follows:
Situations in which the translation process may lead to VM exits (sometimes before the process completes) are
described in Section 29.3.3.
Interactions between the EPT translation mechanism and memory typing are described in Section 29.3.7.
Figure 29-1 gives a summary of the formats of the EPTP and the EPT paging-structure entries. For the EPT paging
structure entries, it identifies separately the format of entries that map pages, those that reference other EPT
paging structures, and those that do neither because they are not present; bits 2:0 and bit 7 are highlighted
because they determine how a paging-structure entry is used. (Figure 29-1 does not comprehend the fact that, if
the “mode-based execute control for EPT” VM-execution control is 1, an entry is present if any of bits 2:0 or bit 10
is 1.)
29.3.3 EPT-Induced VM Exits
Accesses using guest-physical addresses may cause VM exits due to EPT misconfigurations, EPT violations, and
page-modification log-full events. An EPT misconfiguration occurs when, in the course of translating a guest-
physical address, the logical processor encounters an EPT paging-structure entry that contains an unsupported
value (see Section 29.3.3.1). An EPT violation occurs when there is no EPT misconfiguration but the EPT paging-
structure entries disallow an access using the guest-physical address (see Section 29.3.3.2). A page-modifica-
tion log-full event occurs when the logical processor determines a need to create a page-modification log entry
and the current log is full (see Section 29.3.6).
These events occur only due to an attempt to access memory with a guest-physical address. Loading CR3 with a
guest-physical address with the MOV to CR3 instruction can cause neither an EPT configuration nor an EPT violation
until that address is used to access a paging structure.1
If the “EPT-violation #VE” VM-execution control is 1, certain EPT violations may cause virtualization exceptions
instead of VM exits. See Section 26.5.7.1.
29.3.3.1 EPT Misconfigurations
An EPT misconfiguration occurs if translation of a guest-physical address encounters an EPT paging-structure entry
that meets any of the following conditions:
Bit 0 of the entry is clear (indicating that data reads are not allowed) and any of the following hold:
— Bit 1 is set (indicating that data writes are allowed).
— The processor does not support execute-only translations and either of the following hold:
Bit 2 is set (indicating that instruction fetches are allowed).2
The “mode-based execute control for EPT” VM-execution control is 1 and bit 10 is set (indicating that
instruction fetches are allowed from user-mode linear addresses).
Software should read the VMX capability MSR IA32_VMX_EPT_VPID_CAP to determine whether execute-
only translations are supported (see Appendix A.10).
— The “EPT paging-write control” VM-execution control is 1, the entry maps a page, and bit 58 is set
(indicating that paging writes are allowed).
The entry is present (see Section 29.3.2) and of the following holds:
1. If the logical processor is using PAE paging—because CR0.PG = CR4.PAE = 1 and IA32_EFER.LMA = 0—the MOV to CR3 instruction
loads the PDPTEs from memory using the guest-physical address being loaded into CR3. In this case, therefore, the MOV to CR3
instruction may cause an EPT misconfiguration, an EPT violation, or a page-modification log-full event.
2. If the “mode-based execute control for EPT” VM-execution control is 1, setting bit 2 indicates that instruction fetches are allowed
from supervisor-mode linear addresses.
29-10
Vol. 3C
VMX SUPPORT FOR ADDRESS TRANSLATION
Table 29-7. Format of an EPT Page-Table Entry that Maps a 4-KByte Page
Bit
Contents
Position(s)
0
Read access; indicates whether reads are allowed from the 4-KByte page referenced by this entry.
1
Write access; indicates whether writes are allowed to the 4-KByte page referenced by this entry.
2
If the “mode-based execute control for EPT” VM-execution control is 0, execute access; indicates whether
instruction fetches are allowed from the 4-KByte page controlled by this entry.
If that control is 1, execute access for supervisor-mode linear addresses; indicates whether instruction fetches are
allowed from supervisor-mode linear addresses in the 4-KByte page controlled by this entry.
5:3
EPT memory type for this 4-KByte page (see Section 29.3.7).
6
Ignore PAT memory type for this 4-KByte page (see Section 29.3.7).
7
Ignored.
8
If bit 6 of EPTP is 1, accessed flag for EPT; indicates whether software has accessed the 4-KByte page referenced
by this entry (see Section 29.3.5). Ignored if bit 6 of EPTP is 0.
9
If bit 6 of EPTP is 1, dirty flag for EPT; indicates whether software has written to the 4-KByte page referenced by
this entry (see Section 29.3.5). Ignored if bit 6 of EPTP is 0.
10
Execute access for user-mode linear addresses. If the “mode-based execute control for EPT” VM-execution control is
1, indicates whether instruction fetches are allowed from user-mode linear addresses in the 4-KByte page controlled
by this entry. If that control is 0, this bit is ignored.
11
Ignored.
(N-1):12
Physical address of the 4-KByte page referenced by this entry.1
51:N
Reserved (must be 0).
56:52
Ignored.
57
Verify guest paging. If the “guest-paging verification” VM-execution control is 1, indicates limits on the guest paging
structures used to access the 4-KByte page controlled by this entry (see Section 29.3.3.2). If that control is 0, this
bit is ignored.
58
Paging-write access. If the “EPT paging-write control” VM-execution control is 1, indicates that guest paging may
update the 4-KByte page controlled by this entry (see Section 29.3.3.2). If that control is 0, this bit is ignored.
59
Ignored.
60
Supervisor shadow stack. If bit 7 of EPTP is 1, indicates whether supervisor shadow stack accesses are allowed to
guest-physical addresses in the 4-KByte page mapped by this entry (see Section 29.3.3.2).
Ignored if bit 7 of EPTP is 0.
61
Sub-page write permissions. If the “sub-page write permissions for EPT” VM-execution control is 1, writes to
individual 128-byte regions of the 4-KByte page referenced by this entry may be allowed even if the page would
normally not be writable (see Section 29.3.4). If “sub-page write permissions for EPT” VM-execution control is 0, this
bit is ignored.
62
Ignored.
63
Suppress #VE. If the “EPT-violation #VE” VM-execution control is 1, EPT violations caused by accesses to this page
are convertible to virtualization exceptions only if this bit is 0 (see Section 26.5.7.1). If “EPT-violation #VE” VM-
execution control is 0, this bit is ignored.
Vol. 3C
29-11
VMX SUPPORT FOR ADDRESS TRANSLATION
NOTES:
1. N is the physical-address width supported by the processor.
— A reserved bit is set. This includes the setting of a bit in the range 51:12 that is beyond the logical
processor’s physical-address width.1 See Section 29.3.2 for details of which bits are reserved in which EPT
paging-structure entries.
— The entry is the last one used to translate a guest physical address (either an EPT PDE with bit 7 set to 1 or
an EPT PTE) and the value of bits 5:3 (EPT memory type) is 2, 3, or 7 (these values are reserved).
EPT misconfigurations result when an EPT paging-structure entry is configured with settings reserved for future
functionality. Software developers should be aware that such settings may be used in the future and that an EPT
paging-structure entry that causes an EPT misconfiguration on one processor might not do so in the future.
29.3.3.2 EPT Violations
An EPT violation may occur during an access using a guest-physical address whose translation does not cause an
EPT misconfiguration. An EPT violation occurs in any of the following situations:
Translation of the guest-physical address encounters an EPT paging-structure entry that is not present (see
Section 29.3.2).
The access is a data read and, for any byte to be read, bit 0 (read access) was clear in any of the EPT paging-
structure entries used to translate the guest-physical address of the byte. Reads by the logical processor of
guest paging structures to translate a linear address are considered to be data reads.
1. Software can determine a processor’s physical-address width by executing CPUID with 80000008H in EAX. The physical-address
width is returned in bits 7:0 of EAX.
29-12
Vol. 3C
VMX SUPPORT FOR ADDRESS TRANSLATION
6
6
6
6
5
5
5
5
5
5
5
5
5
3
3
3
2
2
2
2
2
2
2
2
2
2
1
1
1
1
1
1
1
1
1
1
M1
M-1
3
2
1
0
9
8
7
6
5
4
3
2
1
2
1
0
9
8
7
6
5
4
3
2
1
0
9
8
7
6
5
4
3
2
1
0
9
8
7
6
5
4
3
2
1
0
S
A
EPT
EPT
S
Reserved
Address of EPT PML5 table or PML4 table
Rsvd.
/
PWL-
PS
EPTP3
S
2
D
1
MT
X
Ig
Ig
X
PML5E:
Ignored
Rsvd.
Address of EPT PML4 table
U
A
Reserved
5
W
R
n.
4
n.
present6
S
PML5E:
V
Ignored
0
0
0
not
E
7
present
Ig
X
Ig
PML4E:
Ignored
Rsvd.
Address of EPT page-directory-pointer table
A
Reserved
X
W
R
n.
U
n.
present
S
PML4E:
V
Ignored
0
0
0
not
E
present
S
V
I
S
P
Physical
PDPTE:
S
Ig
G
Ig
X
P
EPT
V
Ign.
W
Ignored
Rsvd.
address of
Reserved
D
A
1
X
W
R
1GB
S
n.
P
n.
U
A
MT
8
9
1GB page
page
E
10
T
PDPTE:
Ig
X
Ig
Ignored
Rsvd.
Address of EPT page directory
A
0
Rsvd.
X
W
R
page
n.
U
n.
directory
S
PDTPE:
V
Ignored
0
0
0
not
E
present
I
S
S
V
PDE:
Ig
P
Physical address
Ig
X
P
EPT
V
Ign.
S
G
Ignored
Rsvd.
Reserved
D
A
1
X
W
R
2MB
n.
W
of 2MB page
n.
U
A
MT
E
S
P
page
T
PDE:
Ig
X
Ig
Ignored
Rsvd.
Address of EPT page table
A
0
Rsvd.
X
W
R
page
n.
U
n.
table
S
PDE:
V
Ignored
0
0
0
not
E
present
S
I
S
S
V
I
PTE:
Ig
P
Ig
P
Ig
X
P
EPT
V
S
G
Ignored
Rsvd.
Physical address of 4KB page
D
A
g
X
W
R
4KB
n.
P
n.
W
n.
U
A
MT
E
11
S
P
n
page
T
S
PTE:
V
Ignored
0
0
0
not
E
present
Figure 29-1. Formats of EPTP and EPT Paging-Structure Entries
NOTES:
1. M is an abbreviation for MAXPHYADDR.
2. Supervisor shadow-stack control.
3. See Section 25.6.11 for details of the EPTP.
4. Execute access for user-mode linear addresses. If the “mode-based execute control for EPT” VM-execution control is 0, this bit is
ignored.
5. Execute access. If the “mode-based execute control for EPT” VM-execution control is 1, this bit controls execute access for supervi-
sor-mode linear addresses.
Vol. 3C
29-13
VMX SUPPORT FOR ADDRESS TRANSLATION
6. If the “mode-based execute control for EPT” VM-execution control is 1, an EPT paging-structure entry is present if any of bits 2:0 or
bit 10 is 1. This table does not comprehend that fact.
7. Suppress #VE. If the “EPT-violation #VE” VM-execution control is 0, this bit is ignored.
8. Supervisor shadow-stack page. If bit 7 of the EPTP is 0, this bit is ignored.
9. Paging-write access. If the “EPT paging-write control” VM-execution control is 0, this bit is ignored.
10. Verify guest paging. If the “guest-paging verification” VM-execution control is 0, this bit is ignored.
11. Sub-page write permissions. If the “sub-page write permissions for EPT” VM-execution control is 0, this bit is ignored.
The access is a data write and, for any byte to be written, bit 1 (write access) was clear in any of the EPT
paging-structure entries used to translate the guest-physical address of the byte. Writes by the logical
processor to guest paging structures to update accessed and dirty flags are considered to be data writes.
If bit 6 of the EPT pointer (EPTP) is 1 (enabling accessed and dirty flags for EPT), processor accesses to guest
paging-structure entries are treated as writes with regard to EPT violations. Thus, if bit 1 is clear in any of the
EPT paging-structure entries used to translate the guest-physical address of a guest paging-structure entry, an
attempt to use that entry to translate a linear address causes an EPT violation.
(This does not apply to loads of the PDPTE registers by the MOV to CR instruction for PAE paging; see Section
4.4.1. Those loads of guest PDPTEs are treated as reads and do not cause EPT violations due to a guest-physical
address not being writable.)
Processor writes to guest paging structures to update accessed and dirty flags are called paging writes.
(When accessed and dirty flags for EPT are enabled all processor accesses to guest paging structures are
considered paging writes.) If the “EPT paging-write control” VM-execution control is 1, clearing the write-
access bit in the EPT paging-structure entry that maps a page does not prevent a paging write if bit 58 (paging-
write access) in that entry is 1. (EPT paging-structure entries that reference other EPT paging structures do not
use bit 58, and it remains the case that they must set the write-access bit for paging writes to be allowed.)
If the “sub-page write permissions for EPT” VM-execution control is 1, data writes to a guest-physical address
that would cause an EPT violation (as indicated above) do not do so in certain situations. If the guest-physical
address is mapped using a 4-KByte page and bit 61 (sub-page write permissions) of the EPT PTE used to map
the page is 1, writes to certain 128-byte sub-pages may be allowed. See Section 29.3.4 for details.
The access is an instruction fetch and the EPT paging structures prevent execute access to any of the bytes
being fetched. Whether this occurs depends upon the setting of the “mode-based execute control for EPT” VM-
execution control:
— If the control is 0, an instruction fetch from a byte is prevented if bit 2 (execute access) was clear in any of
the EPT paging-structure entries used to translate the guest-physical address of the byte.
— If the control is 1, an instruction fetch from a byte is prevented in either of the following cases:
Paging maps the linear address of the byte as a supervisor-mode address and bit 2 (execute access for
supervisor-mode linear addresses) was clear in any of the EPT paging-structure entries used to
translate the guest-physical address of the byte.
Paging maps a linear address as a supervisor-mode address if the U/S flag (bit 2) is 0 in at least one of
the paging-structure entries controlling the translation of the linear address.
Paging maps the linear address of the byte as a user-mode address and bit 10 (execute access for user-
mode linear addresses) was clear in any of the EPT paging-structure entries used to translate the guest-
physical address of the byte.
Paging maps a linear address as a user-mode address if the U/S flag is 1 in all of the paging-structure
entries controlling the translation of the linear address. If paging is disabled (CR0.PG = 0), every linear
address is a user-mode address.
If supervisor shadow-stack control is enabled (by setting bit 7 of EPTP), the access is a supervisor shadow-
stack access, and the EPT paging-structure entries used to translate the guest-physical address of the access
disallow supervisor shadow-stack accesses. Such an access is disallowed if any of the following hold:
— Bit 0 (read access) is clear in any EPT paging-structure entry used to translate the guest-physical address
of the access.
29-14
Vol. 3C
VMX SUPPORT FOR ADDRESS TRANSLATION
— Bit 1 (write access) is clear in any EPT paging-structure entry that references an EPT paging structure in the
translation of the guest-physical address. (Clearing bit 1 in the EPT paging-structure entry that maps the
page of the guest-physical address does not disallow shadow-stack reads and writes.)
— Bit 60 (supervisor-shadow stack access) is clear in the EPT paging-structure entry that maps the page of
the guest-physical address.
Supervisor shadow-stack control and the supervisor-shadow stack access bits in EPT paging-structure entries
do not affect other accesses (including user shadow-stack accesses).
If the “guest-paging verification” and “EPT paging-write control” VM-execution controls are both 1, guest-
paging verification is performed for certain accesses related to translation of a linear address.
Specifically, guest-paging verification may apply to an access using a guest-physical address to the guest
paging-structure entry that maps a page for the linear address (see Chapter 4, “Paging”). It applies if bit 57
(verify guest paging) is set in the EPT paging-structure entry that maps a page for that guest-physical address.
When guest-paging verification occurs, there is an EPT violation if bit 58 (paging-write access) is clear in the
EPT paging-structure entry that was used to map a page for the guest-physical address of any guest paging-
structure entry that was used during translation of the original linear address.1
See Section 29.3.3.3 for details regarding the prioritization of such EPT violations relative to any page faults
that may occur due to the original reference to the linear address being translated.
29.3.3.3 Prioritization of EPT Misconfigurations and EPT Violations
The translation of a linear address to a physical address requires one or more translations of guest-physical
addresses using EPT (see Section 29.3.1). This section specifies the relative priority of EPT-induced VM exits with
respect to each other and to other events that may be encountered when accessing memory using a linear address.
For an access to a guest-physical address, determination of whether an EPT misconfiguration or an EPT violation
occurs is based on an iterative process:2
1. An EPT paging-structure entry is read (initially, this is an EPT PML5 entry or an EPT PML4 entry):
a. If the entry is not present (see Section 29.3.2), an EPT violation occurs.
b. If the entry is present but its contents are not configured properly (see Section 29.3.3.1), an EPT miscon-
figuration occurs.
c. If the entry is present and its contents are configured properly, operation depends on whether the entry
references another EPT paging structure (or if instead it is an EPT PDPTE or EPT PDE with bit 7 set to 1, or
an EPT PTE):
i) If the entry does reference another EPT paging structure, an entry from that structure is accessed;
step 1 is executed for that other entry.
ii) Otherwise, the entry is used to produce the ultimate physical address (the translation of the original
guest-physical address); step 2 is executed.
2. Once the ultimate physical address is determined, the privileges determined by the EPT paging-structure
entries are evaluated:
a. If the access to the guest-physical address is not allowed by these privileges (see Section 29.3.3.2), an EPT
violation occurs.
b. If the access to the guest-physical address is allowed by these privileges, memory is accessed using the
ultimate physical address.
If CR0.PG = 1, the translation of a linear address is also an iterative process, with the processor first accessing an
entry in the guest paging structure referenced by the guest-physical address in CR3,3 then accessing an entry in
1. When there is a restart of HLAT paging (see Section 4.5), the guest paging-structure entries used by HLAT paging (prior to the
restart) are not relevant to guest-paging verification.
2. This is a simplification of the more detailed description given in Section 29.3.2.
3. If PAE paging is in use, the processor instead uses the guest-physical address in the appropriate PDPTE register. If HLAT paging is
enabled, the processor instead uses the HLATP VMCS field. For simplicity, the remainder of this section refers only to CR3.
Vol. 3C
29-15
VMX SUPPORT FOR ADDRESS TRANSLATION
another guest paging structure referenced by the guest-physical address in the first guest paging-structure entry,
etc. Each guest-physical address is itself translated using EPT and may cause an EPT-induced VM exit. The
following items detail how page faults and EPT-induced VM exits are recognized during this iterative process:
1.
An attempt is made to access a guest paging-structure entry with a guest-physical address (initially, the
address in CR3.
a. If the access fails because of an EPT misconfiguration or an EPT violation (see above), an EPT-induced
VM exit occurs.
b. If the access does not cause an EPT-induced VM exit, the translation continues. If guest-paging verification
is enabled (see Section 29.3.3.2), the processor notes whether the EPT paging-structure entry used to map
a page for the guest-physical address set bit 58 (paging write). Then, bit 0 (the present flag) of the guest
paging-structure entry is consulted:
i) If the present flag is 0 or any reserved bit is set, a page fault occurs.
ii) If the present flag is 1, no reserved bit is set, operation depends on whether the entry references
another guest paging structure (whether it is a guest PDE with PS = 1 or a guest PTE):
If the entry does reference another guest paging structure, an entry from that structure is
accessed; step 1 is executed for that other entry.
Otherwise, the entry is used to produce the ultimate guest-physical address (the translation of the
original linear address); step 2 is executed.
2.
Once the ultimate guest-physical address is determined, the privileges determined by the guest paging-
structure entries are evaluated:
a. If the access to the linear address is not allowed by these privileges (e.g., it was a write to a read-only
page), a page fault occurs.
b. If the access to the linear address is allowed by these privileges, an attempt is made to access memory at
the ultimate guest-physical address:
i) If the access fails because of an EPT misconfiguration or an EPT violation (see above), an EPT-induced
VM exit occurs. It is at this point that guest-paging verification occurs (if enabled), using the paging-
write bits that were noted at occurrences of step 1b above (see Section 29.3.3.2 for details of guest-
paging verification).
ii) If the access does not cause an EPT-induced VM exit, memory is accessed using the ultimate physical
address (the translation, using EPT, of the ultimate guest-physical address).
If CR0.PG = 0, a linear address is treated as a guest-physical address and is translated using EPT (see above). This
process, if it completes without an EPT violation or EPT misconfiguration, produces a physical address and deter-
mines the privileges allowed by the EPT paging-structure entries. If these privileges do not allow the access to the
physical address (see Section 29.3.3.2), an EPT violation occurs. Otherwise, memory is accessed using the physical
address.
29.3.4 Sub-Page Write Permissions
Section 29.3.3.2 explained how EPT enforces the access rights for guest-physical addresses using EPT violations.
Since these access rights are determined using the EPT paging-structure entries that are used to translate a guest-
physical address, their granularity is limited to that which is used to map pages (1-GByte, 2-MByte, or 4-KByte).
The sub-page write-permission feature allows the control of write accesses to guest-physical addresses to be
controlled at finer granularity. Sub-page write permissions allow write accesses to be controlled at the granularity
of naturally aligned 128-byte sub-pages. Specifically, the feature allows writes to selected sub-pages of 4-KByte
page that would otherwise not be writable.
Sub-page write permissions are enabled setting the “sub-page write permissions for EPT” VM-execution control to
1. The remainder of this section describes changes to processor operation with this control setting.
Section 29.3.4.1 identifies the data accesses that are eligible for sub-page write permissions. Section 29.3.4.2
explains how the processor determines whether to allow such an access.
29-16
Vol. 3C
VMX SUPPORT FOR ADDRESS TRANSLATION
29.3.4.1 Write Accesses That Are Eligible for Sub-Page Write Permissions
A guest-physical address is eligible for sub-page write permissions if writes to it would be disallowed following
Section 29.3.3.2: bit 1 (write access) is clear in any of the EPT paging-structure entries used to translate the guest-
physical address. Guest-physical addresses to which writes would be disallowed for other reasons (e.g., the trans-
lation encounters an EPT paging-structure entry that is not present) are not eligible for sub-page write permis-
sions.
In addition, a guest-physical address is eligible for sub-page write permissions only if it is mapped using a 4-KByte
page and bit 61 (sub-page write permissions) of the EPT PTE used to map the page is 1. (Guest-physical addresses
mapped with larger pages are not eligible for sub-page write permissions.)
For some memory accesses, the processor ignores bit 61 in an EPT PTE used to map a 4-KByte page and does not
apply sub-page write permissions to the access. (In such a case, the access causes an EPT violation when indicated
by the conditions given in Section 29.3.3.2.) Sub-page write permissions never apply to the following accesses:
A write access performed within a transactional region.
A write access by an enclave to an address within the enclave's ELRANGE. (Sub-page write permissions may
apply to write accesses by an enclaves to addresses outside its ELRANGE.)
A write access to the enclave page cache (EPC) by an Intel SGX instruction.
A write access to a guest paging structure to update an accessed or dirty flag.
Processor accesses to guest paging-structure entries when accessed and dirty flags for EPT are enabled (such
accesses are treated as writes with regard to EPT violations).
There are additional accesses to which sub-page write permissions might not be applied (behavior is model-
specific). The following items enumerate examples:
A write access that crosses two 4-KByte pages. In this case, sub-page permissions may be applied to neither
or to only one of the pages. (There is no write to either page unless the write is allowed to both pages.)
A write access by an instruction that performs multiple write accesses (sub-page write permissions are
intended principally for basic instructions such as AND, MOV, OR, TEST, XCHG, and XOR).
If a guest-physical address is eligible for sub-page write permissions, the processor determines whether to allow
write to the address using the process described in Section 29.3.4.2.
If a guest-physical address is eligible for sub-page write permissions and that address translates to an address on
the APIC-access page (see Section 30.4), the processor may treat a write access to the address as if the “virtualize
APIC accesses” VM-execution control were 0. For that reason, it is recommended that software not configure any
guest-physical address that translates to an address on the APIC-access page to be eligible for sub-page write
permissions.
29.3.4.2 Determining an Access’s Sub-Page Write Permission
Sub-page write permissions control write accesses individually to each of the 32 128-byte sub-pages of a 4-KByte
page. Bits 11:7 of guest-physical address identify the sub-page.
For each guest-physical address eligible for sub-page write permissions, there is a 64-bit sub-page permission
vector (SPP vector). All addresses on a 4-KByte page use the same SPP vector. If an address’s sub-page number
(bits 11:7 of the address) is S, writes to address are allowed if and only if bit 2S of the sub-page permission is set
to 1. (The bits at odd positions in a SPP vector are not used and must be zero.)
Each page’s SPP vector is located in memory. For a write to a guest-physical address eligible for sub-page write
permissions, the processor uses the following process to locate the address’s SPP vector:
1. The SPPTP (sub-page-permission-table pointer) VM-execution control field contains the physical address of the
4-KByte root SPP table (SSPL4 table). Bits 47:39 of the guest-physical address identify a 64-bit entry in that
table, called an SPPL4E.
2. A 4-KByte SPPL3 table is located at the physical address in the selected SPPL4E. Bits 38:30 of the guest-
physical address identify a 64-bit entry in that table, called an SPPL3E.
3. A 4-KByte SPPL2 table is located at the physical address in the selected SPPL3E. Bits 29:21 of the guest-
physical address identify a 64-bit entry in that table, called an SPPL2E.
Vol. 3C
29-17
VMX SUPPORT FOR ADDRESS TRANSLATION
4. A 4-KByte SPP-vector table (SSPL1 table) is located at the physical address in the selected SPPL2E. Bits 20:12
of the guest-physical address identify the 64-bit SPP vector for the address. As noted earlier, bit 2S of the sub-
page permission vector determines whether the address may be written, where S is the value of address
bits 11:7.
(The memory type used to access these tables is reported in bits 53:50 of the IA32_VMX_BASIC MSR. See
Appendix A.1.)
A write access to multiple 128-byte sub-pages on a single 4-KByte page is allowed only if the indicated bit in the
page’s SPP vector for each of those sub-pages is set to 1. The following items apply to cases in which an access
writes to two 4-KByte pages:
If a write to either page would be disallowed according to Section 29.3.3.2, the access might be disallowed
even if the guest-physical address of that page is eligible for sub-page write permissions. (This behavior is
model-specific.)
The access is allowed only if, for each page, either (1) a write to the page would be allowed following Section
29.3.3.2; or (2) both (a) the guest-physical address of that page is eligible for sub-page write permissions; and
(b) the page’s sub-page vector allows the write (as described above).
Bit 0 of each entry (SPPL4E, SPPL3E, or SPPL2E) is the entry’s valid bit. If the process above accesses an entry in
which this bit is 0, the process stops and the logical processor incurs an SPP miss.
In each entry (SPPL4E, SPPL4E, or SPPL2E), bits 11:1 are reserved, as are bits 63:N, where N is the processor’s
physical-address width. If the process above accesses an entry in which the valid bit is 1 and in which some
reserved bit is set, the process stops and the logical processor incurs an SPP misconfiguration. Bits in an SPP
vector in odd positions are also reserved; an SPP misconfiguration occurs also any of those bits are set in the final
SPP vector.
SPP misses and SPP misconfigurations are called SPP-related events and cause VM exits.
29.3.5 Accessed and Dirty Flags for EPT
The Intel 64 architecture supports accessed and dirty flags in ordinary paging-structure entries (see Section
4.8). Some processors also support corresponding flags in EPT paging-structure entries. Software should read the
VMX capability MSR IA32_VMX_EPT_VPID_CAP (see Appendix A.10) to determine whether the processor supports
this feature.
Software can enable accessed and dirty flags for EPT using bit 6 of the extended-page-table pointer (EPTP), a VM-
execution control field (see Table 25-9 in Section 25.6.11). If this bit is 1, the processor will set the accessed and
dirty flags for EPT as described below. In addition, setting this flag causes processor accesses to guest paging-
structure entries to be treated as writes (see below and Section 29.3.3.2).
For any EPT paging-structure entry that is used during guest-physical-address translation, bit 8 is the accessed
flag. For a EPT paging-structure entry that maps a page (as opposed to referencing another EPT paging structure),
bit 9 is the dirty flag.
Whenever the processor uses an EPT paging-structure entry as part of guest-physical-address translation, it sets
the accessed flag in that entry (if it is not already set).
Whenever there is a write to a guest-physical address, the processor sets the dirty flag (if it is not already set) in
the EPT paging-structure entry that identifies the final physical address for the guest-physical address (either an
EPT PTE or an EPT paging-structure entry in which bit 7 is 1).
When accessed and dirty flags for EPT are enabled, processor accesses to guest paging-structure entries are
treated as writes (see Section 29.3.3.2). Thus, such an access will cause the processor to set the dirty flag in the
EPT paging-structure entry that identifies the final physical address of the guest paging-structure entry.
(This does not apply to loads of the PDPTE registers for PAE paging by the MOV to CR instruction; see Section 4.4.1.
Those loads of guest PDPTEs are treated as reads and do not cause the processor to set the dirty flag in any EPT
paging-structure entry.)
These flags are “sticky,” meaning that, once set, the processor does not clear them; only software can clear them.
29-18
Vol. 3C
VMX SUPPORT FOR ADDRESS TRANSLATION
A processor may cache information from the EPT paging-structure entries in TLBs and paging-structure caches
(see Section 29.4). This fact implies that, if software changes an accessed flag or a dirty flag from 1 to 0, the
processor might not set the corresponding bit in memory on a subsequent access using an affected guest-physical
address.
29.3.6 Page-Modification Logging
When accessed and dirty flags for EPT are enabled, software can track writes to guest-physical addresses using a
feature called page-modification logging.
Software can enable page-modification logging by setting the “enable PML” VM-execution control (see Table 25-7
in Section 25.6.2). When this control is 1, the processor adds entries to the page-modification log as described
below. The page-modification log is a 4-KByte region of memory located at the physical address in the PML address
VM-execution control field. The page-modification log consists of 512 64-bit entries; the PML index VM-execution
control field indicates the next entry to use.
Before allowing a guest-physical access, the processor may determine that it first needs to set an accessed or dirty
flag for EPT (see Section 29.3.5). When this happens, the processor examines the PML index. If the PML index is
not in the range 0-511, there is a page-modification log-full event and a VM exit occurs. In this case, the
accessed or dirty flag is not set, and the guest-physical access that triggered the event does not occur.
If instead the PML index is in the range 0-511, the processor proceeds to update accessed or dirty flags for EPT as
described in Section 29.3.5. If the processor updated a dirty flag for EPT (changing it from 0 to 1), it then operates
as follows:
1. The guest-physical address of the access is written to the page-modification log. Specifically, the guest-
physical address is written to physical address determined by adding 8 times the PML index to the PML address.
Bits 11:0 of the value written are always 0 (the guest-physical address written is thus 4-KByte aligned).
2. The PML index is decremented by 1 (this may cause the value to transition from 0 to FFFFH).
Because the processor decrements the PML index with each log entry, the value may transition from 0 to FFFFH. At
that point, no further logging will occur, as the processor will determine that the PML index is not in the range 0-
511 and will generate a page-modification log-full event (see above).
29.3.7 EPT and Memory Typing
This section specifies how a logical processor determines the memory type use for a memory access while EPT is in
use. (See Chapter 12, “Memory Cache Control‚” of the Intel® 64 and IA-32 Architectures Software Developer’s
Manual, Volume 3A, for details of memory typing in the Intel 64 architecture.) Section 29.3.7.1 explains how the
memory type is determined for accesses to the EPT paging structures. Section 29.3.7.2 explains how the memory
type is determined for an access using a guest-physical address that is translated using EPT.
29.3.7.1 Memory Type Used for Accessing EPT Paging Structures
This section explains how the memory type is determined for accesses to the EPT paging structures. The determi-
nation is based first on the value of bit 30 (cache disable—CD) in control register CR0:
If CR0.CD = 0, the memory type used for any such reference is the EPT paging-structure memory type, which
is specified in bits 2:0 of the extended-page-table pointer (EPTP), a VM-execution control field (see Section
25.6.11). A value of 0 indicates the uncacheable type (UC), while a value of 6 indicates the write-back type
(WB). Other values are reserved.
If CR0.CD = 1, the memory type used for any such reference is uncacheable (UC).
The MTRRs have no effect on the memory type used for an access to an EPT paging structure.
29.3.7.2 Memory Type Used for Translated Guest-Physical Addresses
The effective memory type of a memory access using a guest-physical address (an access that is translated
using EPT) is the memory type that is used to access memory. The effective memory type is based on the value of
Vol. 3C
29-19
VMX SUPPORT FOR ADDRESS TRANSLATION
bit 30 (cache disable—CD) in control register CR0; the last EPT paging-structure entry used to translate the guest-
physical address (either an EPT PDE with bit 7 set to 1 or an EPT PTE); and the PAT memory type (see below):
The PAT memory type depends on the value of CR0.PG:
— If CR0.PG = 0, the PAT memory type is WB (writeback).1
— If CR0.PG = 1, the PAT memory type is the memory type selected from the IA32_PAT MSR as specified in
Section 12.12.3, “Selecting a Memory Type from the PAT.”2
The EPT memory type is specified in bits 5:3 of the last EPT paging-structure entry: 0 = UC; 1 = WC; 4 = WT;
5 = WP; and 6 = WB. Other values are reserved and cause EPT misconfigurations (see Section 29.3.3).
If CR0.CD = 0, the effective memory type depends upon the value of bit 6 of the last EPT paging-structure
entry:
— If the value is 0, the effective memory type is the combination of the EPT memory type and the PAT memory
type specified in Table 12-7 in Section 12.5.2.2, using the EPT memory type in place of the MTRR memory
type.
— If the value is 1, the memory type used for the access is the EPT memory type. The PAT memory type is
ignored.
If CR0.CD = 1, the effective memory type is UC.
The MTRRs have no effect on the memory type used for an access to a guest-physical address.
29.4
CACHING TRANSLATION INFORMATION
Processors supporting Intel® 64 and IA-32 architectures may accelerate the address-translation process by
caching on the processor data from the structures in memory that control that process. Such caching is discussed
in Section 4.10, “Caching Translation Information,” in the Intel® 64 and IA-32 Architectures Software Developer’s
Manual, Volume 3A. The current section describes how this caching interacts with the VMX architecture.
The VPID and EPT features of the architecture for VMX operation augment this caching architecture. EPT defines
the guest-physical address space and defines translations to that address space (from the linear-address space)
and from that address space (to the physical-address space). Both features control the ways in which a logical
processor may create and use information cached from the paging structures.
Section 29.4.1 describes the different kinds of information that may be cached. Section 29.4.2 specifies when such
information may be cached and how it may be used. Section 29.4.3 details how software can invalidate cached
information.
29.4.1 Information That May Be Cached
Section 4.10, “Caching Translation Information,” in the Intel® 64 and IA-32 Architectures Software Developer’s
Manual, Volume 3A, identifies two kinds of translation-related information that may be cached by a logical
processor: translations, which are mappings from linear page numbers to physical page frames, and paging-
structure caches, which map the upper bits of a linear page number to information from the paging-structure
entries used to translate linear addresses matching those upper bits.
The same kinds of information may be cached when VPIDs and EPT are in use. A logical processor may cache and
use such information based on its function. Information with different functionality is identified as follows:
1. If the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PG must be 1 in VMX operation, CR0.PG can be 0 in VMX non-root
operation only if the “unrestricted guest” VM-execution control and bit 31 of the primary processor-based VM-execution controls are
both 1.
2. Table 12-11 in Section 12.12.3, “Selecting a Memory Type from the PAT,” illustrates how the PAT memory type is selected based on
the values of the PAT, PCD, and PWT bits in a page-table entry (or page-directory entry with PS = 1). For accesses to a guest paging-
structure entry X, the PAT memory type is selected from the table by using a value of 0 for the PAT bit with the values of PCD and
PWT from the paging-structure entry Y that references X (or from CR3 if X is in the root paging structure). With PAE paging, the PAT
memory type for accesses to the PDPTEs is WB.
29-20
Vol. 3C
VMX SUPPORT FOR ADDRESS TRANSLATION
Linear mappings.1 There are two kinds:
— Linear translations. Each of these is a mapping from a linear page number to the physical page frame to
which it translates, along with information about access privileges and memory typing.
— Linear paging-structure-cache entries. Each of these is a mapping from the upper portion of a linear
address to the physical address of the paging structure used to translate the corresponding region of the
linear-address space, along with information about access privileges. For example, bits 47:39 of a linear
address would map to the address of the relevant page-directory-pointer table.
Linear mappings do not contain information from any EPT paging structure.
Guest-physical mappings.2 There are two kinds:
— Guest-physical translations. Each of these is a mapping from a guest-physical page number to the physical
page frame to which it translates, along with information about access privileges and memory typing.
— Guest-physical paging-structure-cache entries. Each of these is a mapping from the upper portion of a
guest-physical address to the physical address of the EPT paging structure used to translate the corre-
sponding region of the guest-physical address space, along with information about access privileges.
The information in guest-physical mappings about access privileges and memory typing is derived from EPT
paging structures.
Combined mappings.3 There are two kinds:
— Combined translations. Each of these is a mapping from a linear page number to the physical page frame
to which it translates, along with information about access privileges and memory typing.
— Combined paging-structure-cache entries. Each of these is a mapping from the upper portion of a linear
address to the physical address of the paging structure used to translate the corresponding region of the
linear-address space, along with information about access privileges.
The information in combined mappings about access privileges and memory typing is derived from both guest
paging structures and EPT paging structures.
Guest-physical mappings and combined mappings may also include SPP vectors and information about the data
structures used to locate SPP vectors (see Section 29.3.4.2).
29.4.2 Creating and Using Cached Translation Information
The following items detail the creation of the mappings described in the previous section:4
The following items describe the creation of mappings while EPT is not in use (including execution outside VMX
non-root operation):
— Linear mappings may be created. They are derived from the paging structures referenced (directly or
indirectly) by the current value of CR3 and are associated with the current VPID and the current PCID.
— No linear mappings are created with information derived from paging-structure entries that are not present
(bit 0 is 0) or that set reserved bits. For example, if a PTE is not present, no linear mapping are created for
any linear page number whose translation would use that PTE.
— No guest-physical or combined mappings are created while EPT is not in use.
The following items describe the creation of mappings while EPT is in use:
— Guest-physical mappings may be created. They are derived from the EPT paging structures referenced
(directly or indirectly) by bits 51:12 of the current EPTP. These 40 bits contain the address of the EPT root
1. Earlier versions of this manual used the term “VPID-tagged” to identify linear mappings.
2. Earlier versions of this manual used the term “EPTP-tagged” to identify guest-physical mappings.
3. Earlier versions of this manual used the term “dual-tagged” to identify combined mappings.
4. This section associated cached information with the current VPID and PCID. If PCIDs are not supported or are not being used (e.g.,
because CR4.PCIDE = 0), all the information is implicitly associated with PCID 000H; see Section 4.10.1, “Process-Context Identifiers
(PCIDs),” in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A.
Vol. 3C
29-21
VMX SUPPORT FOR ADDRESS TRANSLATION
table (a EPT PML4 table with 4-level EPT or a EPT PML5 table with 5-level EPT); the notation EPTRTA refers
to those 40 bits. Newly created guest-physical mappings are associated with the current EPTRTA.
— Combined mappings may be created. They are derived from the EPT paging structures referenced (directly
or indirectly) by the current EPTRTA. If CR0.PG = 1, they are also derived from the paging structures
referenced (directly or indirectly) by the current value of CR3. They are associated with the current VPID,
the current PCID, and the current EPTRTA.1 No combined paging-structure-cache entries are created if
CR0.PG = 0.2
— No guest-physical mappings or combined mappings are created with information derived from EPT paging-
structure entries that are not present (see Section 29.3.2) or that are misconfigured (see Section
29.3.3.1).
— No combined mappings are created with information derived from guest paging-structure entries that are
not present or that set reserved bits.
— No linear mappings are created while EPT is in use.
The following items detail the use of the various mappings:
If EPT is not in use (e.g., when outside VMX non-root operation), a logical processor may use cached mappings
as follows:
— For accesses using linear addresses, it may use linear mappings associated with the current VPID and the
current PCID. It may also use global TLB entries (linear mappings) associated with the current VPID and
any PCID.
— No guest-physical or combined mappings are used while EPT is not in use.
If EPT is in use, a logical processor may use cached mappings as follows:
— For accesses using linear addresses, it may use combined mappings associated with the current VPID, the
current PCID, and the current EPTRTA. It may also use global TLB entries (combined mappings) associated
with the current VPID, the current EPTRTA, and any PCID.
— For accesses using guest-physical addresses, it may use guest-physical mappings associated with the
current EPTRTA.
— No linear mappings are used while EPT is in use.
29.4.3 Invalidating Cached Translation Information
Software modifications of paging structures (including EPT paging structures and the data structures used to locate
SPP vectors) may result in inconsistencies between those structures and the mappings cached by a logical
processor. Certain operations invalidate information cached by a logical processor and can be used to eliminate
such inconsistencies.
29.4.3.1 Operations that Invalidate Cached Mappings
The following operations invalidate cached mappings as indicated:
Operations that architecturally invalidate entries in the TLBs or paging-structure caches independent of VMX
operation (e.g., the INVLPG and INVPCID instructions) invalidate linear mappings and combined mappings.3
They are required to do so only for the current VPID (but, for combined mappings, all EPTRTAs). Linear
1. At any given time, a logical processor may be caching combined mappings for a VPID and a PCID that are associated with different
EPTRTAs. Similarly, it may be caching combined mappings for an EPTRTA that are associated with different VPIDs and PCIDs.
2. If the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PG must be 1 in VMX operation, CR0.PG can be 0 in VMX non-root
operation only if the “unrestricted guest” VM-execution control and bit 31 of the primary processor-based VM-execution controls are
both 1.
3. See Section 4.10.4, “Invalidation of TLBs and Paging-Structure Caches,” in the Intel® 64 and IA-32 Architectures Software Devel-
oper’s Manual, Volume 3A, for an enumeration of operations that architecturally invalidate entries in the TLBs and paging-structure
caches independent of VMX operation.
29-22
Vol. 3C
VMX SUPPORT FOR ADDRESS TRANSLATION
mappings for the current VPID are invalidated even if EPT is in use.1 Combined mappings for the current
VPID are invalidated even if EPT is not in use.2
An EPT violation invalidates any guest-physical mappings (associated with the current EPTRTA) that would be
used to translate the guest-physical address that caused the EPT violation. If that guest-physical address was
the translation of a linear address, the EPT violation also invalidates any combined mappings for that linear
address associated with the current PCID, the current VPID and the current EPTRTA.
If the “enable VPID” VM-execution control is 0, VM entries and VM exits invalidate linear mappings and
combined mappings associated with VPID 0000H (for all PCIDs). Combined mappings for VPID 0000H are
invalidated for all EPTRTAs.
Execution of the INVVPID instruction invalidates linear mappings and combined mappings. Invalidation is
based on instruction operands, called the INVVPID type and the INVVPID descriptor. Four INVVPID types are
currently defined:
Individual-address. If the INVVPID type is 0, the logical processor invalidates linear mappings and
combined mappings associated with the VPID specified in the INVVPID descriptor and that would be used
to translate the linear address specified in of the INVVPID descriptor. Linear mappings and combined
mappings for that VPID and linear address are invalidated for all PCIDs and, for combined mappings, all
EPTRTAs. (The instruction may also invalidate mappings associated with other VPIDs and for other linear
addresses.)
Single-context. If the INVVPID type is 1, the logical processor invalidates all linear mappings and
combined mappings associated with the VPID specified in the INVVPID descriptor. Linear mappings and
combined mappings for that VPID are invalidated for all PCIDs and, for combined mappings, all EPTRTAs.
(The instruction may also invalidate mappings associated with other VPIDs.)
All-context. If the INVVPID type is 2, the logical processor invalidates linear mappings and combined
mappings associated with all VPIDs except VPID 0000H and with all PCIDs. (The instruction may also
invalidate linear mappings with VPID 0000H.) Combined mappings are invalidated for all EPTRTAs.
Single-context-retaining-globals. If the INVVPID type is 3, the logical processor invalidates linear
mappings and combined mappings associated with the VPID specified in the INVVPID descriptor. Linear
mappings and combined mappings for that VPID are invalidated for all PCIDs and, for combined mappings,
all EPTRTAs. The logical processor is not required to invalidate information that was used for global trans-
lations (although it may do so). See Section 4.10, “Caching Translation Information,” for details regarding
global translations. (The instruction may also invalidate mappings associated with other VPIDs.)
See Chapter 31 for details of the INVVPID instruction. See Section 29.4.3.3 for guidelines regarding use of this
instruction.
Execution of the INVEPT instruction invalidates guest-physical mappings and combined mappings. Invalidation
is based on instruction operands, called the INVEPT type and the INVEPT descriptor. Two INVEPT types are
currently defined:
Single-context. If the INVEPT type is 1, the logical processor invalidates all guest-physical mappings and
combined mappings associated with the EPTRTA specified in the INVEPT descriptor. Combined mappings for
that EPTRTA are invalidated for all VPIDs and all PCIDs. (The instruction may invalidate mappings
associated with other EPTRTAs.)
All-context. If the INVEPT type is 2, the logical processor invalidates guest-physical mappings and
combined mappings associated with all EPTRTAs (and, for combined mappings, for all VPIDs and PCIDs).
See Chapter 31 for details of the INVEPT instruction. See Section 29.4.3.4 for guidelines regarding use of this
instruction.
A power-up or a reset invalidates all linear mappings, guest-physical mappings, and combined mappings.
1. While no linear mappings are created while EPT is in use, a logical processor may retain, while EPT is in use, linear mappings (for the
same VPID as the current one) there were created earlier, when EPT was not in use.
2. While no combined mappings are created while EPT is not in use, a logical processor may retain, while EPT is in not use, combined
mappings (for the same VPID as the current one) there were created earlier, when EPT was in use.
Vol. 3C
29-23
VMX SUPPORT FOR ADDRESS TRANSLATION
29.4.3.2 Operations that Need Not Invalidate Cached Mappings
The following items detail cases of operations that are not required to invalidate certain cached mappings:
Operations that architecturally invalidate entries in the TLBs or paging-structure caches independent of VMX
operation are not required to invalidate any guest-physical mappings.
The INVVPID instruction is not required to invalidate any guest-physical mappings.
The INVEPT instruction is not required to invalidate any linear mappings.
VMX transitions are not required to invalidate any guest-physical mappings. If the “enable VPID” VM-execution
control is 1, VMX transitions are not required to invalidate any linear mappings or combined mappings.
The VMXOFF and VMXON instructions are not required to invalidate any linear mappings, guest-physical
mappings, or combined mappings.
A logical processor may invalidate any cached mappings at any time. For this reason, the operations identified
above may invalidate the indicated mappings despite the fact that doing so is not required.
29.4.3.3 Guidelines for Use of the INVVPID Instruction
The need for VMM software to use the INVVPID instruction depends on how that software is virtualizing memory.
If EPT is not in use, it is likely that the VMM is virtualizing the guest paging structures. Such a VMM may configure
the VMCS so that all or some of the operations that invalidate entries the TLBs and the paging-structure caches
(e.g., the INVLPG instruction) cause VM exits. If VMM software is emulating these operations, it may be necessary
to use the INVVPID instruction to ensure that the logical processor’s TLBs and the paging-structure caches are
appropriately invalidated.
Requirements of when software should use the INVVPID instruction depend on the specific algorithm being used for
page-table virtualization. The following items provide guidelines for software developers:
Emulation of the INVLPG instruction may require execution of the INVVPID instruction as follows:
— The INVVPID type is individual-address (0).
— The VPID in the INVVPID descriptor is the one assigned to the virtual processor whose execution is being
emulated.
— The linear address in the INVVPID descriptor is that of the operand of the INVLPG instruction being
emulated.
Some instructions invalidate all entries in the TLBs and paging-structure caches—except for global translations.
An example is the MOV to CR3 instruction. (See Section 4.10, “Caching Translation Information,” in the Intel®
64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, for details regarding global translations.)
Emulation of such an instruction may require execution of the INVVPID instruction as follows:
— The INVVPID type is single-context-retaining-globals (3).
— The VPID in the INVVPID descriptor is the one assigned to the virtual processor whose execution is being
emulated.
Some instructions invalidate all entries in the TLBs and paging-structure caches—including for global transla-
tions. An example is the MOV to CR4 instruction if the value of value of bit 4 (page global enable—PGE) is
changing. Emulation of such an instruction may require execution of the INVVPID instruction as follows:
— The INVVPID type is single-context (1).
— The VPID in the INVVPID descriptor is the one assigned to the virtual processor whose execution is being
emulated.
If EPT is not in use, the logical processor associates all mappings it creates with the current VPID, and it will use
such mappings to translate linear addresses. For that reason, a VMM should not use the same VPID for different
non-EPT guests that use different page tables. Doing so may result in one guest using translations that pertain to
the other.
If EPT is in use, the instructions enumerated above might not be configured to cause VM exits and the VMM might
not be emulating them. In that case, executions of the instructions by guest software properly invalidate the
29-24
Vol. 3C

 

 

 

 

 

 

 

Content      ..     113      114      115      116     ..