Content      ..     112      113      114      115     ..

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

VMX NON-ROOT OPERATION

— If both controls are 1, the virtual delay is multiplied by 2⁴⁸ (using a shift) to produce a 128-bit

integer. That product is then divided by the TSC multiplier to produce a 64-bit integer. The physical

delay is that quotient.

• If the “RDTSC exiting” VM-execution control is 1, UMWAIT causes a VM exit.

•

WRMSR. Section 26.1.3 identifies when executions of the WRMSR instruction cause VM exits. If such an

execution neither a fault due to CPL > 0 nor a VM exit, the instruction’s behavior may be modified for certain

values of ECX:

— If ECX contains 48H (indicating the IA32_SPEC_CTRL MSR), instruction behavior depends on the setting of

the “virtualize IA32_SPEC_CTRL” VM-execution control:

• If the control is 0, WRMSR operates normally, loading the IA32_SPEC_CTRL MSR with the value in

EAX:EDX.

• If the control is 1, instruction will attempt to write the IA32_SPEC_CTRL MSR using the instruction’s

source operand, but it will attempt to modify only those bits in positions corresponding to bits cleared in

the IA32_SPEC_CTRL mask field in the VMCS.

Specifically, the instruction attempts to write the MSR with the following value:

(MSR_VAL & ISC_MASK) OR (SRC & NOT ISC_MASK),

where MSR_VAL is the original value of the MSR, ISC_MASK is the IA32_SPEC_CTRL mask, and SRC is

the instruction’s source operand.

Any fault that would result from writing that value to the MSR (e.g., due to a reserved-bit violation)

occurs normally. Otherwise, the value is written to the MSR.

Such a write to the MSR will have any side effects that would occur normally had the MSR been written

with the value indicated above (including any side effects that may result from writing unchanged

values to the masked bits).

If the write completes without a fault, the unmodified value of the source operand is written to the

IA32_SPEC_CTRL shadow field in the VMCS.

— If ECX contains 79H (indicating IA32_BIOS_UPDT_TRIG MSR), no microcode update is loaded, and control

passes to the next instruction. This implies that microcode updates cannot be loaded in VMX non-root

operation.

— On processors that support Intel PT but which do not allow it to be used in VMX operation, if ECX contains

570H (indicating the IA32_RTIT_CTL MSR), the instruction causes a general-protection exception.¹

— If ECX contains 808H (indicating the TPR MSR), 80BH (the EOI MSR), 830H (the ICR MSR), or 83FH (the

self-IPI MSR), instruction behavior may be modified if the “virtualize x2APIC mode” VM-execution control is

1; see Section 30.5.

•

XRSTORS. Behavior of the XRSTORS instruction is determined first by the setting of the “enable

XSAVES/XRSTORS” VM-execution control:

— If the “enable XSAVES/XRSTORS” VM-execution control is 0, XRSTORS causes an invalid-opcode exception

(#UD).

— If the “enable XSAVES/XRSTORS” VM-execution control is 1, treatment is based on the value of the XSS-

exiting bitmap (see Section 25.6.21):

• XRSTORS causes a VM exit if any bit is set in the logical-AND of the following three values: EDX:EAX,

the IA32_XSS MSR, and the XSS-exiting bitmap.

• Otherwise, XRSTORS operates normally.

•

XSAVES. Behavior of the XSAVES instruction is determined first by the setting of the “enable

XSAVES/XRSTORS” VM-execution control:

— If the “enable XSAVES/XRSTORS” VM-execution control is 0, XSAVES causes an invalid-opcode exception

(#UD).

1.

Software should read the VMX capability MSR IA32_VMX_MISC to determine whether the processor allows Intel PT to be used in

VMX operation (see Appendix A.6).

26-12

Vol. 3C

VMX NON-ROOT OPERATION

transitions to the C0 C-state and causes a VM exit; the timer does not cause a VM exit if it counts down to zero in

the wait-for-SIPI state. The timer is not decremented in C-states deeper than C2.

Treatment of the timer in the case of system management interrupts (SMIs) and system-management mode

(SMM) depends on whether the treatment of SMIs and SMM:

• If the default treatment of SMIs and SMM (see Section 32.14) is active, the VMX-preemption timer counts

across an SMI to VMX non-root operation, subsequent execution in SMM, and the return from SMM via the RSM

instruction. However, the timer can cause a VM exit only from VMX non-root operation. If the timer expires

during SMI, in SMM, or during RSM, a timer-induced VM exit occurs immediately after RSM with its normal

priority unless it is blocked based on activity state (Section 26.2).

• If the dual-monitor treatment of SMIs and SMM (see Section 32.15) is active, transitions into and out of SMM

are VM exits and VM entries, respectively. The treatment of the VMX-preemption timer by those transitions is

mostly the same as for ordinary VM exits and VM entries; Section 32.15.2 and Section 32.15.4 detail some

differences.

26.5.2 Monitor Trap Flag

The monitor trap flag is a debugging feature that causes VM exits to occur on certain instruction boundaries in

VMX non-root operation. Such VM exits are called MTF VM exits. An MTF VM exit may occur on an instruction

boundary in VMX non-root operation as follows:

•

If the “monitor trap flag” VM-execution control is 1 and VM entry is injecting a vectored event (see Section

27.6.1), an MTF VM exit is pending on the instruction boundary before the first instruction following the

VM entry.

•

If VM entry is injecting a pending MTF VM exit (see Section 27.6.2), an MTF VM exit is pending on the

instruction boundary before the first instruction following the VM entry. This is the case even if the “monitor

trap flag” VM-execution control is 0.

•

If the “monitor trap flag” VM-execution control is 1, VM entry is not injecting an event, and a pending event

(e.g., debug exception or interrupt) is delivered before an instruction can execute, an MTF VM exit is pending

on the instruction boundary following delivery of the event (or any nested exception).

•

Suppose that the “monitor trap flag” VM-execution control is 1, VM entry is not injecting an event, and the first

instruction following VM entry is a REP-prefixed string instruction:

— If the first iteration of the instruction causes a fault, an MTF VM exit is pending on the instruction boundary

following delivery of the fault (or any nested exception).

— If the first iteration of the instruction does not cause a fault, an MTF VM exit is pending on the instruction

boundary after that iteration.

•

Suppose that the “monitor trap flag” VM-execution control is 1, VM entry is not injecting an event, and the first

instruction following VM entry is the XBEGIN instruction. In this case, an MTF VM exit is pending at the fallback

instruction address of the XBEGIN instruction. This behavior applies regardless of whether advanced debugging

of RTM transactional regions has been enabled (see Section 16.3.7, “RTM-Enabled Debugger Support,” of

Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1).

•

Suppose that the “monitor trap flag” VM-execution control is 1, VM entry is not injecting an event, and the first

instruction following VM entry is neither a REP-prefixed string instruction or the XBEGIN instruction:

— If the instruction causes a fault, an MTF VM exit is pending on the instruction boundary following delivery of

the fault (or any nested exception).¹

— If the instruction does not cause a fault, an MTF VM exit is pending on the instruction boundary following

execution of that instruction. If the instruction is INT1, INT3, or INTO, this boundary follows delivery of any

software exception. If the instruction is INT n, this boundary follows delivery of a software interrupt. If the

instruction is HLT, the MTF VM exit will be from the HLT activity state.

No MTF VM exit occurs if another VM exit occurs before reaching the instruction boundary on which an MTF VM exit

would be pending (e.g., due to an exception or triple fault).

1. This item includes the cases of an invalid opcode exception—#UD— generated by the UD0, UD1, and UD2 instructions and a BOUND-

range exceeded exception—#BR—generated by the BOUND instruction.

Vol. 3C

26-15

VMX NON-ROOT OPERATION

Suppose, for example, that software wants to enable EPTP switching (VM function 0; see Section 25.6.14).To do

so, it must set the “activate secondary controls” VM-execution control (bit 31 of the primary processor-based VM-

execution controls), the “enable VM functions” VM-execution control (bit 13 of the secondary processor-based VM-

execution controls) and the “EPTP switching” VM-function control (bit 0 of the VM-function controls).

26.5.6.2 General Operation of the VMFUNC Instruction

The VMFUNC instruction causes an invalid-opcode exception (#UD) if the “enable VM functions” VM-execution

controls is 0¹ or the value of EAX is greater than 63 (only VM functions 0-63 can be enable). Otherwise, the instruc-

tion causes a VM exit if the bit at position EAX is 0 in the VM-function controls (the selected VM function is not

enabled). If such a VM exit occurs, the basic exit reason used is 59 (3BH), indicating “VMFUNC”, and the length of

the VMFUNC instruction is saved into the VM-exit instruction-length field. If the instruction causes neither an

invalid-opcode exception nor a VM exit due to a disabled VM function, it performs the functionality of the

VM function specified by the value in EAX.

Individual VM functions may perform additional fault checking (e.g., one might cause a general-protection excep-

tion if CPL > 0). In addition, specific VM functions may include checks that might result in a VM exit. If such a

VM exit occurs, VM-exit information is saved as described in the previous paragraph. The specification of a

VM function may indicate that additional VM-exit information is provided.

The specific behavior of the EPTP-switching VM function (including checks that result in VM exits) is given in

Section 26.5.6.3.

26.5.6.3 EPTP Switching

EPTP switching is VM function 0. This VM function allows software in VMX non-root operation to load a new value

for the EPT pointer (EPTP), thereby establishing a different EPT paging-structure hierarchy (see Section 29.3 for

details of the operation of EPT). Software is limited to selecting from a list of potential EPTP values configured in

advance by software in VMX root operation.

Specifically, the value of ECX is used to select an entry from the EPTP list, the 4-KByte structure referenced by the

EPTP-list address (see Section 25.6.14; because this structure contains 512 8-Byte entries, VMFUNC causes a

VM exit if ECX ≥ 512). The EPTP value in the selected entry is evaluated to determine whether it is valid for EPTP

switching: a value is valid if (1) it is the same as the current EPTP value in bits 5:3 (these bits specify the EPT page-

walk length); and (2) it would not cause VM entry to fail (see Section 27.2.1.1). If the value is invalid, a VM exit

occurs. Otherwise, the value is stored in the EPTP field of the current VMCS and is used for subsequent accesses

using guest-physical addresses. The following pseudocode provides details:

IF ECX ≥ 512

THEN VM exit;

ELSE

tent_EPTP := 8 bytes from EPTP-list address + 8 * ECX;

IF tent_EPTP is not a valid EPTP value (would cause VM entry to fail if in EPTP or change EPT page-walk length)

THEN VM exit;

ELSE

write tent_EPTP to the EPTP field in the current VMCS;

use tent_EPTP as the new EPTP value for address translation;

IF processor supports the 1-setting of the “EPT-violation #VE” VM-execution control

THEN

write ECX[15:0] to EPTP-index field in current VMCS;

use ECX[15:0] as EPTP index for subsequent EPT-violation virtualization exceptions (see Section 26.5.7.2);

FI;

FI;

FI;

Execution of the EPTP-switching VM function does not modify the state of any registers; no flags are modified.

1.

“Enable VM functions” is a secondary processor-based VM-execution control. If bit 31 of the primary processor-based VM-execution

controls is 0, VMX non-root operation functions as if the “enable VM functions” VM-execution control were 0. See Section 25.6.2.

26-18

Vol. 3C

VMX NON-ROOT OPERATION

If the “Intel PT uses guest physical addresses” VM-execution control is 1 and IA32_RTIT_CTL.TraceEn = 1, any

execution of the EPTP-switching VM function causes a VM exit.¹

As noted in Section 26.5.6.2, an execution of the EPTP-switching VM function that causes a VM exit (as specified

above), uses the basic exit reason 59, indicating “VMFUNC”. The length of the VMFUNC instruction is saved into the

VM-exit instruction-length field. No additional VM-exit information is provided.

An execution of VMFUNC loads EPTP from the EPTP list (and thus does not cause a fault or VM exit) is called an

EPTP-switching VMFUNC. After an EPTP-switching VMFUNC, control passes to the next instruction. The logical

processor starts creating and using guest-physical and combined mappings associated with the new value of bits

51:12 of EPTP; the combined mappings created and used are associated with the current VPID and PCID (these are

not changed by VMFUNC).² If the “enable VPID” VM-execution control is 0, an EPTP-switching VMFUNC invalidates

combined mappings associated with VPID 0000H (for all PCIDs and for all EPTRTA values, where EPTRTA is the

value of bits 51:12 of EPTP).

Because an EPTP-switching VMFUNC may change the translation of guest-physical addresses, it may affect use of

the guest-physical address in CR3. The EPTP-switching VMFUNC cannot itself cause a VM exit due to an EPT viola-

tion or an EPT misconfiguration due to the translation of that guest-physical address through the new EPT paging

structures. The following items provide details that apply if CR0.PG = 1:

• If 32-bit paging or 4-level paging³ is in use (either CR4.PAE = 0 or IA32_EFER.LMA = 1), the next memory

access with a linear address uses the translation of the guest-physical address in CR3 through the new EPT

paging structures. As a result, this access may cause a VM exit due to an EPT violation or an EPT misconfigu-

ration encountered during that translation.

• If PAE paging is in use (CR4.PAE = 1 and IA32_EFER.LMA = 0), an EPTP-switching VMFUNC does not load the

four page-directory-pointer-table entries (PDPTEs) from the guest-physical address in CR3. The logical

processor continues to use the four guest-physical addresses already present in the PDPTEs. The guest-

physical address in CR3 is not translated through the new EPT paging structures (until some operation that

would load the PDPTEs).

The EPTP-switching VMFUNC cannot itself cause a VM exit due to an EPT violation or an EPT misconfiguration

encountered during the translation of a guest-physical address in any of the PDPTEs. A subsequent memory

access with a linear address uses the translation of the guest-physical address in the appropriate PDPTE

through the new EPT paging structures. As a result, such an access may cause a VM exit due to an EPT

violation or an EPT misconfiguration encountered during that translation.

If an EPTP-switching VMFUNC establishes an EPTP value that enables accessed and dirty flags for EPT (by setting

bit 6), subsequent memory accesses may fail to set those flags as specified if there has been no appropriate execu-

tion of INVEPT since the last use of an EPTP value that does not enable accessed and dirty flags for EPT (because

bit 6 is clear) and that is identical to the new value on bits 51:12.

IF the processor supports the 1-setting of the “EPT-violation #VE” VM-execution control, an EPTP-switching

VMFUNC loads the value in ECX[15:0] into to EPTP-index field in current VMCS. Subsequent EPT-violation virtual-

ization exceptions will save this value into the virtualization-exception information area (see Section 26.5.7.2).

26.5.7 Virtualization Exceptions

A virtualization exception is a new processor exception. It uses vector 20 and is abbreviated #VE.

A virtualization exception can occur only in VMX non-root operation. Virtualization exceptions occur only with

certain settings of certain VM-execution controls. Generally, these settings imply that certain conditions that would

normally cause VM exits instead cause virtualization exceptions

In particular, the 1-setting of the “EPT-violation #VE” VM-execution control causes some EPT violations to generate

virtualization exceptions instead of VM exits. Section 26.5.7.1 provides the details of how the processor deter-

mines whether an EPT violation causes a virtualization exception or a VM exit.

1. Such a VM exit ensures the proper recording of trace data that might otherwise be lost during the change of EPT paging-structure

hierarchy. Software handling the VM exit can change emulate the VM function and then resume the guest.

2. If the “enable VPID” VM-execution control is 0, the current VPID is 0000H; if CR4.PCIDE = 0, the current PCID is 000H.

3. Earlier versions of this manual used the term “IA-32e paging” to identify 4-level paging.

Vol. 3C

26-19

VMX NON-ROOT OPERATION

When the processor encounters a virtualization exception, it saves information about the exception to the virtual-

ization-exception information area; see Section 26.5.7.2.

After saving virtualization-exception information, the processor delivers a virtualization exception as it would any

other exception; see Section 26.5.7.3 for details.

26.5.7.1 Convertible EPT Violations

If the “EPT-violation #VE” VM-execution control is 0 (e.g., on processors that do not support this feature), EPT

violations always cause VM exits. If instead the control is 1, certain EPT violations may be converted to cause virtu-

alization exceptions instead; such EPT violations are convertible.

The values of certain EPT paging-structure entries determine which EPT violations are convertible. Specifically,

bit 63 of certain EPT paging-structure entries may be defined to mean suppress #VE:

• If bits 2:0 of an EPT paging-structure entry are all 0, the entry is not present.¹ If the processor encounters

such an entry while translating a guest-physical address, it causes an EPT violation. The EPT violation is

convertible if and only if bit 63 of the entry is 0.

• If an EPT paging-structure entry is present, the following cases apply:

— If the value of the EPT paging-structure entry is not supported, the entry is misconfigured. If the

processor encounters such an entry while translating a guest-physical address, it causes an EPT misconfig-

uration (not an EPT violation). EPT misconfigurations always cause VM exits.

— If the value of the EPT paging-structure entry is supported, the following cases apply:

• If bit 7 of the entry is 1, or if the entry is an EPT PTE, the entry maps a page. If the processor uses such

an entry to translate a guest-physical address, and if an access to that address causes an EPT violation,

the EPT violation is convertible if and only if bit 63 of the entry is 0.

• If bit 7 of the entry is 0 and the entry is not an EPT PTE, the entry references another EPT paging

structure. The processor does not use the value of bit 63 of the entry to determine whether any

subsequent EPT violation is convertible.

If an access to a guest-physical address causes an EPT violation, bit 63 of exactly one of the EPT paging-structure

entries used to translate that address is used to determine whether the EPT violation is convertible: either a entry

that is not present (if the guest-physical address does not translate to a physical address) or an entry that maps a

page (if it does).

A convertible EPT violation instead causes a virtualization exception if the following all hold:

• CR0.PE = 1;

• the logical processor is not in the process of delivering an event through the IDT;

• the EPT violation did not cause a shadow stack to become prematurely busy (see Section 26.4.3);

• the EPT violation does not result from the output process of Intel Processor Trace (Section 26.5.4); and

• the 32 bits at offset 4 in the virtualization-exception information area are all 0.

Delivery of virtualization exceptions writes the value FFFFFFFFH to offset 4 in the virtualization-exception informa-

tion area (see Section 26.5.7.2). Thus, once a virtualization exception occurs, another can occur only if software

clears this field.

26.5.7.2 Virtualization-Exception Information

Virtualization exceptions save data into the virtualization-exception information area (see Section 25.6.20).

Table 26-1 enumerates the data saved and the format of the area.

A VMM may allow guest software to access the virtualization-exception information area. If it does, the guest soft-

ware may modify that memory (e.g., to clear the 32-bit value at offset 4; see Section 26.5.7.1). (This is an excep-

tion to the general requirement given in Section 25.11.4.)

1. 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.

26-20

Vol. 3C

VMX NON-ROOT OPERATION

Table 26-1. Format of the Virtualization-Exception Information Area

Byte Offset

Contents

0

The 32-bit value that would have been saved into the VMCS as an exit reason had a VM exit occurred

instead of the virtualization exception. For EPT violations, this value is 48 (00000030H)

4

FFFFFFFFH

8

The 64-bit value that would have been saved into the VMCS as an exit qualification had a VM exit

occurred instead of the virtualization exception

16

The 64-bit value that would have been saved into the VMCS as a guest-linear address had a VM exit

occurred instead of the virtualization exception

24

The 64-bit value that would have been saved into the VMCS as a guest-physical address had a VM

exit occurred instead of the virtualization exception

32

The current 16-bit value of the EPTP index VM-execution control (see Section 25.6.20 and Section

26.5.6.3)

26.5.7.3 Delivery of Virtualization Exceptions

After saving virtualization-exception information, the processor treats a virtualization exception as it does other

exceptions:

• If bit 20 (#VE) is 1 in the exception bitmap in the VMCS, a virtualization exception causes a VM exit (see

below). If the bit is 0, the virtualization exception is delivered using gate descriptor 20 in the IDT.

• Virtualization exceptions produce no error code. Delivery of a virtualization exception pushes no error code on

the stack.

• With respect to double faults, virtualization exceptions have the same severity as page faults. If delivery of a

virtualization exception encounters a nested fault that is either contributory or a page fault, a double fault

(#DF) is generated. See Chapter 6, “Interrupt 8—Double Fault Exception (#DF)” in Intel^® 64 and IA-32 Archi-

tectures Software Developer’s Manual, Volume 3A.

It is not possible for a virtualization exception to be encountered while delivering another exception (see

Section 26.5.7.1).

If a virtualization exception causes a VM exit directly (because bit 20 is 1 in the exception bitmap), information

about the exception is saved normally in the VM-exit interruption information field in the VMCS (see Section

28.2.2). Specifically, the event is reported as a hardware exception with vector 20 and no error code. Bit 12 of the

field (NMI unblocking due to IRET) is set normally.

If a virtualization exception causes a VM exit indirectly (because bit 20 is 0 in the exception bitmap and delivery of

the exception generates an event that causes a VM exit), information about the exception is saved normally in the

IDT-vectoring information field in the VMCS (see Section 28.2.4). Specifically, the event is reported as a hardware

exception with vector 20 and no error code.

26.5.8 PASID Translation

The ENQCMD and ENQCMDS instructions each performs a 64-byte enqueue store that includes a 20-bit PASID

value in bits 19:0. For ENQCMD, the PASID is normally the value of IA32_PASID[19:0], while for ENQCMDS, the

PASID is normally read from memory.

If the “PASID translation” VM-execution control is 1, the PASID value identified in the previous paragraph is treated

as a guest PASID. PASID translation converts this guest PASID to a 20-bit host PASID. After this translation, the

enqueue store is performed, using the host PASID in place of the guest PASID.

PASID translation is implemented by two hierarchies of data structures (PASID-translation hierarchies) config-

ured by a VMM. Guest PASIDs 00000H to 7FFFFH are translated through the low PASID-translation hierarchy, while

guest PASIDs 80000 to FFFFFH are translated through the high PASID-translation hierarchy.

Vol. 3C

26-21

VMX NON-ROOT OPERATION

The root of each PASID-translation hierarchy is a 4-KByte PASID directory. The low PASID directory is located at

the low PASID directory address, and the high PASID directory is located at the high PASID directory address

(these physical addresses are VM-execution control fields in the VMCS). A PASID directory comprises 512 8-byte

entries, each of which has the following format:

• Bit 0 is the entry’s present bit. The entry is used only if this bit is 1.

• Bits 11:1 are reserved and must be 0.

• Bits M-1:12 specify the 4-KByte aligned address of a PASID table (see below), where M is the processor’s

physical-address width.

• Bits 63:M are reserved and must be 0.

A PASID-translation hierarchy also includes up to 512 4-KByte PASID tables; each of these is referenced by a

PASID directory entry (see above). A PASID table comprises 1024 4-byte entries, each of which has the following

format:

• Bits 19:0 are the host PASID specified by the entry.

• Bits 30:20 are reserved and must be 0.

• Bits 31 is the entry’s valid bit. The entry is used only if this bit is 1.

When PASID translation is enabled, the guest PASID determined by the instruction (see above) is converted to a

host PASID using the following process:

• If bit 19 of guest PASID is clear, the low PASID directory is used; otherwise, the high PASID directory is used.

• Bits 18:10 of the guest PASID select an entry from the PASID directory. A VM exit occurs if the entry’s present

bit is clear or if any reserved bit is set. Otherwise, bits M:0 of the entry (with bit 0 cleared) contain the physical

address of a PASID table.

• Bits 9:0 of the guest PASID select an entry from the PASID table. A VM exit occurs if the entry’s valid bit is clear

or if any reserved bit is set. Otherwise, bits 19:0 of the entry are the host PASID.

If PASID translation results in a VM exit (due to a present or valid bit being clear, or a reserved bit being set), the

instruction does not complete and no enqueue store is performed.

26.6

UNRESTRICTED GUESTS

The first processors to support VMX operation require CR0.PE and CR0.PG to be 1 in VMX operation (see Section

24.8). This restriction implies that guest software cannot be run in unpaged protected mode or in real-address

mode. Later processors support a VM-execution control called “unrestricted guest”.¹ If this control is 1, CR0.PE and

CR0.PG may be 0 in VMX non-root operation. Such processors allow guest software to run in unpaged protected

mode or in real-address mode. The following items describe the behavior of such software:

• The MOV CR0 instructions does not cause a general-protection exception simply because it would set either

CR0.PE and CR0.PG to 0. See Section 26.3 for details.

• A logical processor treats the values of CR0.PE and CR0.PG in VMX non-root operation just as it does outside

VMX operation. Thus, if CR0.PE = 0, the processor operates as it does normally in real-address mode (for

example, it uses the 16-bit interrupt table to deliver interrupts and exceptions). If CR0.PG = 0, the processor

operates as it does normally when paging is disabled.

• Processor operation is modified by the fact that the processor is in VMX non-root operation and by the settings

of the VM-execution controls just as it is in protected mode or when paging is enabled. Instructions, interrupts,

and exceptions that cause VM exits in protected mode or when paging is enabled also do so in real-address

mode or when paging is disabled. The following examples should be noted:

— If CR0.PG = 0, page faults do not occur and thus cannot cause VM exits.

— If CR0.PE = 0, invalid-TSS exceptions do not occur and thus cannot cause VM exits.

1.

“Unrestricted guest” is a secondary processor-based VM-execution control. If bit 31 of the primary processor-based VM-execution

controls is 0, VMX non-root operation functions as if the “unrestricted guest” VM-execution control were 0. See Section 25.6.2.

26-22

Vol. 3C

VMX NON-ROOT OPERATION

— If CR0.PE = 0, the following instructions cause invalid-opcode exceptions and do not cause VM exits:

INVEPT, INVVPID, LLDT, LTR, SLDT, STR, VMCLEAR, VMLAUNCH, VMPTRLD, VMPTRST, VMREAD,

VMRESUME, VMWRITE, VMXOFF, and VMXON.

• If CR0.PG = 0, each linear address is passed directly to the EPT mechanism for translation to a physical

address.¹ The guest memory type passed on to the EPT mechanism is WB (writeback).

1. As noted in Section 27.2.1.1, the “enable EPT” VM-execution control must be 1 if the “unrestricted guest” VM-execution control is 1.

Vol. 3C

26-23

CHAPTER 27

VM ENTRIES

Software can enter VMX non-root operation using either of the VM-entry instructions VMLAUNCH and VMRESUME.

VMLAUNCH can be used only with a VMCS whose launch state is clear and VMRESUME can be used only with a

VMCS whose the launch state is launched. VMLAUNCH should be used for the first VM entry after VMCLEAR; VMRE-

SUME should be used for subsequent VM entries with the same VMCS.

Each VM entry performs the following steps in the order indicated:

1. Basic checks are performed to ensure that VM entry can commence (Section 27.1).

2. The control and host-state areas of the VMCS are checked to ensure that they are proper for supporting VMX

non-root operation and that the VMCS is correctly configured to support the next VM exit (Section 27.2).

3. The following may be performed in parallel or in any order (Section 27.3):

• The guest-state area of the VMCS is checked to ensure that, after the VM entry completes, the state of the

logical processor is consistent with IA-32 and Intel 64 architectures.

• Processor state is loaded from the guest-state area and based on controls in the VMCS.

• Address-range monitoring is cleared.

4. MSRs are loaded from the VM-entry MSR-load area (Section 27.4).

5. If VMLAUNCH is being executed, the launch state of the VMCS is set to “launched.”

6. If the “Intel PT uses guest physical addresses” VM-execution control is 1, trace-address pre-translation (TAPT)

may occur (see Section 26.5.4 and Section 27.5).

7. An event may be injected in the guest context (Section 27.6).

Steps 1-4 above perform checks that may cause VM entry to fail. Such failures occur in one of the following three

ways:

• Some of the checks in Section 27.1 may generate ordinary faults (for example, an invalid-opcode exception).

Such faults are delivered normally.

• Some of the checks in Section 27.1 and all the checks in Section 27.2 cause control to pass to the instruction

following the VM-entry instruction. The failure is indicated by setting RFLAGS.ZF¹ (if there is a current VMCS)

or RFLAGS.CF (if there is no current VMCS). If there is a current VMCS, an error number indicating the cause of

the failure is stored in the VM-instruction error field. See Chapter 31 for the error numbers.

• The checks in Section 27.3 and Section 27.4 cause processor state to be loaded from the host-state area of the

VMCS (as would be done on a VM exit). Information about the failure is stored in the VM-exit information fields.

See Section 27.8 for details.

EFLAGS.TF = 1 causes a VM-entry instruction to generate a single-step debug exception only if failure of one of the

checks in Section 27.1 and Section 27.2 causes control to pass to the following instruction. A VM-entry does not

generate a single-step debug exception in any of the following cases: (1) the instruction generates a fault; (2)

failure of one of the checks in Section 27.3 or in loading MSRs causes processor state to be loaded from the host-

state area of the VMCS; or (3) the instruction passes all checks in Section 27.1, Section 27.2, and Section 27.3 and

there is no failure in loading MSRs.

Section 32.15 describes the dual-monitor treatment of system-management interrupts (SMIs) and system-

management mode (SMM). Under this treatment, code running in SMM returns using VM entries instead of the RSM

instruction. A VM entry returns from SMM if it is executed in SMM and the “entry to SMM” VM-entry control is 0.

VM entries that return from SMM differ from ordinary VM entries in ways that are detailed in Section 32.15.4.

1. This chapter uses the notation RAX, RIP, RSP, RFLAGS, etc. for processor registers because most processors that support VMX oper-

ation also support Intel 64 architecture. For IA-32 processors, this notation refers to the 32-bit forms of those registers (EAX, EIP,

ESP, EFLAGS, etc.). In a few places, notation such as EAX is used to refer specifically to lower 32 bits of the indicated register.

Vol. 3C

27-1

VM ENTRIES

27.1

BASIC VM-ENTRY CHECKS

Before a VM entry commences, the current state of the logical processor is checked in the following order:

1. If the logical processor is in virtual-8086 mode or compatibility mode, an invalid-opcode exception is

generated.

2. If the current privilege level (CPL) is not zero, a general-protection exception is generated.

3. If there is no current VMCS, RFLAGS.CF is set to 1 and control passes to the next instruction.

4. If there is a current VMCS but the current VMCS is a shadow VMCS (see Section 25.10), RFLAGS.CF is set to 1

and control passes to the next instruction.

5. If there is a current VMCS that is not a shadow VMCS, the following conditions are evaluated in order; any of

these cause VM entry to fail:

a. If there is MOV-SS blocking (see Table 25-3).

b. If the VM entry is invoked by VMLAUNCH and the VMCS launch state is not clear.

c. If the VM entry is invoked by VMRESUME and the VMCS launch state is not launched.

If any of these checks fail, RFLAGS.ZF is set to 1 and control passes to the next instruction. An error number

indicating the cause of the failure is stored in the VM-instruction error field. See Chapter 31 for the error

numbers.

27.2

CHECKS ON VMX CONTROLS AND HOST-STATE AREA

If the checks in Section 27.1 do not cause VM entry to fail, the control and host-state areas of the VMCS are

checked to ensure that they are proper for supporting VMX non-root operation, that the VMCS is correctly config-

ured to support the next VM exit, and that, after the next VM exit, the processor’s state is consistent with the Intel

64 and IA-32 architectures.

VM entry fails if any of these checks fail. When such failures occur, control is passed to the next instruction,

RFLAGS.ZF is set to 1 to indicate the failure, and the VM-instruction error field is loaded with an error number that

indicates whether the failure was due to the controls or the host-state area (see Chapter 31).

These checks may be performed in any order. Thus, an indication by error number of one cause (for example, host

state) does not imply that there are not also other errors. Different processors may thus give different error

numbers for the same VMCS. Some checks prevent establishment of settings (or combinations of settings) that are

currently reserved. Future processors may allow such settings (or combinations) and may not perform the corre-

sponding checks. The correctness of software should not rely on VM-entry failures resulting from the checks docu-

mented in this section.

The checks on the controls and the host-state area are presented in Section 27.2.1 through Section 27.2.4. These

sections reference VMCS fields that correspond to processor state. Unless otherwise stated, these references are to

fields in the host-state area.

27.2.1 Checks on VMX Controls

This section identifies VM-entry checks on the VMX control fields.

27.2.1.1 VM-Execution Control Fields

VM entries perform the following checks on the VM-execution control fields:¹

• Reserved bits in the pin-based VM-execution controls must be set properly. Software may consult the VMX

capability MSRs to determine the proper settings (see Appendix A.3.1).

1. If the “activate secondary controls” primary processor-based VM-execution control is 0, VM entry operates as if each secondary pro-

cessor-based VM-execution control were 0. Similarly, if the “activate tertiary controls” primary processor-based VM-execution con-

trol is 0, VM entry operates as if each tertiary processor-based VM-execution control were 0. See Section 25.6.2.

27-2

Vol. 3C

VM ENTRIES

•

Reserved bits in the primary processor-based VM-execution controls must be set properly. Software may

consult the VMX capability MSRs to determine the proper settings (see Appendix A.3.2).

•

If the “activate secondary controls” primary processor-based VM-execution control is 1, reserved bits in the

secondary processor-based VM-execution controls must be cleared. Software may consult the VMX capability

MSRs to determine which bits are reserved (see Appendix A.3.3).

If the “activate secondary controls” primary processor-based VM-execution control is 0 (or if the processor

does not support the 1-setting of that control), no checks are performed on the secondary processor-based

VM-execution controls. The logical processor operates as if all the secondary processor-based VM-execution

controls were 0.

•

If the “activate tertiary controls” primary processor-based VM-execution control is 1, reserved bits in the

tertiary processor-based VM-execution controls must be cleared. Software may consult the VMX capability

MSRs to determine which bits are reserved (see Appendix A.3.4).

If the “activate tertiary controls” primary processor-based VM-execution control is 0 (or if the processor does

not support the 1-setting of that control), no checks are performed on the tertiary processor-based VM-

execution controls. The logical processor operates as if all the tertiary processor-based VM-execution controls

were 0.

•

The CR3-target count must not be greater than 4. Future processors may support a different number of CR3-

target values. Software should read the VMX capability MSR IA32_VMX_MISC to determine the number of

values supported (see Appendix A.6).

•

If the “use I/O bitmaps” VM-execution control is 1, bits 11:0 of each I/O-bitmap address must be 0. Neither

address should set any bits beyond the processor’s physical-address width.^1,2

•

If the “use MSR bitmaps” VM-execution control is 1, bits 11:0 of the MSR-bitmap address must be 0. The

address should not set any bits beyond the processor’s physical-address width.³

•

If the “use TPR shadow” VM-execution control is 1, the virtual-APIC address must satisfy the following checks:

— Bits 11:0 of the address must be 0.

— The address should not set any bits beyond the processor’s physical-address width.⁴

If all of the above checks are satisfied and the “use TPR shadow” VM-execution control is 1, bytes 3:1 of VTPR

(see Section 30.1.1) may be cleared (behavior may be implementation-specific).

The clearing of these bytes may occur even if the VM entry fails. This is true either if the failure causes control

to pass to the instruction following the VM-entry instruction or if it causes processor state to be loaded from

the host-state area of the VMCS.

•

If the “use TPR shadow” VM-execution control is 1 and the “virtual-interrupt delivery” VM-execution control is

0, bits 31:4 of the TPR threshold VM-execution control field must be 0.

•

The following check is performed if the “use TPR shadow” VM-execution control is 1 and the “virtualize APIC

accesses” and “virtual-interrupt delivery” VM-execution controls are both 0: the value of bits 3:0 of the TPR

threshold VM-execution control field should not be greater than the value of bits 7:4 of VTPR (see Section

30.1.1).

•

If the “NMI exiting” VM-execution control is 0, the “virtual NMIs” VM-execution control must be 0.

•

If the “virtual NMIs” VM-execution control is 0, the “NMI-window exiting” VM-execution control must be 0.

•

If the “virtualize APIC-accesses” VM-execution control is 1, the APIC-access address must satisfy the following

checks:

— Bits 11:0 of the address must be 0.

— The address should not set any bits beyond the processor’s physical-address width.⁵

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.

2.

If IA32_VMX_BASIC[48] is read as 1, these addresses must not set any bits in the range 63:32; see Appendix A.1.

3.

If IA32_VMX_BASIC[48] is read as 1, this address must not set any bits in the range 63:32; see Appendix A.1.

4.

If IA32_VMX_BASIC[48] is read as 1, this address must not set any bits in the range 63:32; see Appendix A.1.

5.

If IA32_VMX_BASIC[48] is read as 1, this address must not set any bits in the range 63:32; see Appendix A.1.

Vol. 3C

27-3

VM ENTRIES

•

If the “use TPR shadow” VM-execution control is 0, the following VM-execution controls must also be 0:

“virtualize x2APIC mode”, “APIC-register virtualization”, “virtual-interrupt delivery”, and “IPI virtualization”.

•

If the “virtualize x2APIC mode” VM-execution control is 1, the “virtualize APIC accesses” VM-execution control

must be 0.

•

If the “virtual-interrupt delivery” VM-execution control is 1, the “external-interrupt exiting” VM-execution

control must be 1.

•

If the “process posted interrupts” VM-execution control is 1, the following must be true:

— The “virtual-interrupt delivery” VM-execution control is 1.

— The “acknowledge interrupt on exit” VM-exit control is 1.

— The posted-interrupt notification vector has a value in the range 0-255 (bits 15:8 are all 0).

— Bits 5:0 of the posted-interrupt descriptor address are all 0.

— The posted-interrupt descriptor address does not set any bits beyond the processor's physical-address

width.¹

•

If the “IPI virtualization” VM-execution control is 1, the following must be true:

— Bits 2:0 of the PID-pointer table address are all 0.

— The PID-pointer table address does not set any bits beyond the processor’s physical-address width.

— The address of the last entry in the PID-pointer table does not set any bits beyond the processor’s physical-

address width. (This address is the PID-pointer table address plus 8 times the last PID-pointer index.)

•

If the “enable VPID” VM-execution control is 1, the value of the VPID VM-execution control field must not be

0000H.

•

If the “enable EPT” VM-execution control is 1, the EPTP VM-execution control field (see Table 25-9 in Section

25.6.11) must satisfy the following checks:

— The EPT memory type (bits 2:0) must be a value supported by the processor as indicated in the

IA32_VMX_EPT_VPID_CAP MSR (see Appendix A.10).

— Bits 5:3 must contain a value 1 less than an EPT page-walk length supported by the processor as indicated

in the IA32_VMX_EPT_VPID_CAP MSR (see Section 29.3.2 and Appendix A.10).

— Bit 6 (enable bit for accessed and dirty flags for EPT) must be 0 if bit 21 of the IA32_VMX_EPT_VPID_CAP

MSR (see Appendix A.10) is read as 0, indicating that the processor does not support accessed and dirty

flags for EPT.

— Reserved bits 11:7 and 63:N (where N is the processor’s physical-address width) must all be 0.

•

The “enable EPT” VM-execution control must be 1 if any of the following VM-execution controls is 1: “enable

PML,” “unrestricted guest,” “mode-based execute control for EPT,” “sub-page write permissions for EPT,” “Intel

PT uses guest physical addresses,” “enable HLAT,” “EPT paging-write control,” or “guest-paging verification.”

•

If the “enable PML” VM-execution control is 1, the PML address must satisfy the following checks:

— Bits 11:0 of the address must be 0.

— The address should not set any bits beyond the processor’s physical-address width.

•

If the “sub-page write permissions for EPT” VM-execution control is 1, the SPPTP VM-execution control field

(see Table 25-11 in Section 25.6.22) must satisfy the following checks:

— Bits 11:0 of the address must be 0.

— The address should not set any bits beyond the processor’s physical-address width.

•

If the “enable VM functions” processor-based VM-execution control is 1, reserved bits in the VM-function

controls must be clear. Software may consult the VMX capability MSRs to determine which bits are reserved

(see Appendix A.11). In addition, the following check is performed based on the setting of bits in the VM-

function controls (see Section 25.6.14):

1. If IA32_VMX_BASIC[48] is read as 1, this address must not set any bits in the range 63:32; see Appendix A.1.

27-4

Vol. 3C

VM ENTRIES

— If “EPTP switching” VM-function control is 1, the “enable EPT” VM-execution control must also be 1. In

addition, the EPTP-list address must satisfy the following checks:

• Bits 11:0 of the address must be 0.

• The address must not set any bits beyond the processor’s physical-address width.

If the “enable VM functions” processor-based VM-execution control is 0, no checks are performed on the VM-

function controls.

•

If the “VMCS shadowing” VM-execution control is 1, the VMREAD-bitmap and VMWRITE-bitmap addresses

must each satisfy the following checks:

— Bits 11:0 of the address must be 0.

— The address must not set any bits beyond the processor’s physical-address width.

•

If the “EPT-violation #VE” VM-execution control is 1, the virtualization-exception information address must

satisfy the following checks:

— Bits 11:0 of the address must be 0.

— The address must not set any bits beyond the processor’s physical-address width.

•

If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of

VM entry, the “load IA32_RTIT_CTL” VM-entry control must be 0.

•

If the “Intel PT uses guest physical addresses” VM-execution control is 1, the “load IA32_RTIT_CTL” VM-entry

control and the “clear IA32_RTIT_CTL” VM-exit control must both be 1.

•

If the “use TSC scaling” VM-execution control is 1, the TSC-multiplier must not be zero.

•

If the “enable HLAT” VM-execution control is 1, the following bits in the HLATP VM-execution control field (see

Table 25-12 in Section 25.6.23) must be zero: bits 2:0, bits 11:5, and bits beyond the processor’s physical-

address width.

•

If the “PASID translation” VM-execution control is 1, the low PASID directory address and the high PASID

directory address must each satisfy the following checks:

— Bits 11:0 of the address must be 0.

— The address must not set any bits beyond the processor’s physical-address width.

27.2.1.2 VM-Exit Control Fields

VM entries perform the following checks on the VM-exit control fields.

• Reserved bits in the primary VM-exit controls must be set properly. Software may consult the VMX capability

MSRs to determine the proper settings (see Appendix A.4.1).

• If the “activate secondary controls” primary VM-exit control is 1, reserved bits in the secondary VM-exit

controls must be cleared. Software may consult the VMX capability MSRs to determine which bits are reserved

(see Appendix A.4.2).

• If the “activate secondary controls” primary VM-exit control is 0 (or if the processor does not support the 1-

setting of that control), no checks are performed on the secondary VM-exit controls. The logical processor

operates as if all the secondary VM-exit controls were 0.

• If the “activate VMX-preemption timer” VM-execution control is 0, the “save VMX-preemption timer value” VM-

exit control must also be 0.

• The following checks are performed for the VM-exit MSR-store address if the VM-exit MSR-store count field is

non-zero:

— The lower 4 bits of the VM-exit MSR-store address must be 0. The address should not set any bits beyond

the processor’s physical-address width.¹

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.

Vol. 3C

27-5

VM ENTRIES

— The address of the last byte in the VM-exit MSR-store area should not set any bits beyond the processor’s

physical-address width. The address of this last byte is VM-exit MSR-store address + (MSR count * 16) - 1.

(The arithmetic used for the computation uses more bits than the processor’s physical-address width.)

If IA32_VMX_BASIC[48] is read as 1, neither address should set any bits in the range 63:32; see Appendix

A.1.

• The following checks are performed for the VM-exit MSR-load address if the VM-exit MSR-load count field is

non-zero:

— The lower 4 bits of the VM-exit MSR-load address must be 0. The address should not set any bits beyond

the processor’s physical-address width.

— The address of the last byte in the VM-exit MSR-load area should not set any bits beyond the processor’s

physical-address width. The address of this last byte is VM-exit MSR-load address + (MSR count * 16) - 1.

(The arithmetic used for the computation uses more bits than the processor’s physical-address width.)

If IA32_VMX_BASIC[48] is read as 1, neither address should set any bits in the range 63:32; see Appendix

A.1.

27.2.1.3 VM-Entry Control Fields

VM entries perform the following checks on the VM-entry control fields.

•

Reserved bits in the VM-entry controls must be set properly. Software may consult the VMX capability MSRs to

determine the proper settings (see Appendix A.5).

•

Fields relevant to VM-entry event injection must be set properly. These fields are the VM-entry interruption-

information field (see Table 25-17 in Section 25.8.3), the VM-entry exception error code, and the VM-entry

instruction length. If the valid bit (bit 31) in the VM-entry interruption-information field is 1, the following must

hold:

— The field’s interruption type (bits 10:8) is not set to a reserved value. Value 1 is reserved on all logical

processors; value 7 (other event) is reserved on logical processors that do not support the 1-setting of the

“monitor trap flag” VM-execution control.

— The field’s vector (bits 7:0) is consistent with the interruption type:

• If the interruption type is non-maskable interrupt (NMI), the vector is 2.

• If the interruption type is hardware exception, the vector is at most 31.

• If the interruption type is other event, the vector is 0 (pending MTF VM exit).

— The field's deliver-error-code bit (bit 11) is 1 if each of the following holds: (1) the interruption type is

hardware exception; (2) bit 0 (corresponding to CR0.PE) is set in the CR0 field in the guest-state area;

(3) IA32_VMX_BASIC[56] is read as 0 (see Appendix A.1); and (4) the vector indicates one of the following

exceptions: #DF (vector 8), #TS (10), #NP (11), #SS (12), #GP (13), #PF (14), or #AC (17).

— The field's deliver-error-code bit is 0 if any of the following holds: (1) the interruption type is not hardware

exception; (2) bit 0 is clear in the CR0 field in the guest-state area; or (3) IA32_VMX_BASIC[56] is read as

0 and the vector is in one of the following ranges: 0-7, 9, 15, 16, or 18-31.

— Reserved bits in the field (30:12) are 0.

— If the deliver-error-code bit (bit 11) is 1, bits 31:16 of the VM-entry exception error-code field are 0.

— If the interruption type is software interrupt, software exception, or privileged software exception, the

VM-entry instruction-length field is in the range 0-15. A VM-entry instruction length of 0 is allowed only if

IA32_VMX_MISC[30] is read as 1; see Appendix A.6.

•

The following checks are performed for the VM-entry MSR-load address if the VM-entry MSR-load count field is

non-zero:

— The lower 4 bits of the VM-entry MSR-load address must be 0. The address should not set any bits beyond

the processor’s physical-address width.¹

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.

27-6

Vol. 3C

VM ENTRIES

— The address of the last byte in the VM-entry MSR-load area should not set any bits beyond the processor’s

physical-address width. The address of this last byte is VM-entry MSR-load address + (MSR count * 16) -

1. (The arithmetic used for the computation uses more bits than the processor’s physical-address width.)

If IA32_VMX_BASIC[48] is read as 1, neither address should set any bits in the range 63:32; see Appendix

A.1.

• If the processor is not in SMM, the “entry to SMM” and “deactivate dual-monitor treatment” VM-entry controls

must be 0.

• The “entry to SMM” and “deactivate dual-monitor treatment” VM-entry controls cannot both be 1.

27.2.2 Checks on Host Control Registers, MSRs, and SSP

The following checks are performed on fields in the host-state area that correspond to control registers and MSRs:

• The CR0 field must not set any bit to a value not supported in VMX operation (see Section 24.8).¹

• The CR4 field must not set any bit to a value not supported in VMX operation (see Section 24.8).

• If bit 23 in the CR4 field (corresponding to CET) is 1, bit 16 in the CR0 field (WP) must also be 1.

• On processors that support Intel 64 architecture, the CR3 field must be such that bits 63:52 and bits in the

range 51:32 beyond the processor’s physical-address width must be 0.^2,3

• On processors that support Intel 64 architecture, the IA32_SYSENTER_ESP field and the IA32_SYSENTER_EIP

field must each contain a canonical address.

• If the “load IA32_PERF_GLOBAL_CTRL” VM-exit control is 1, bits reserved in the IA32_PERF_GLOBAL_CTRL

MSR must be 0 in the field for that register (see Figure 20-3).

• If the “load IA32_PAT” VM-exit control is 1, the value of the field for the IA32_PAT MSR must be one that could

be written by WRMSR without fault at CPL 0. Specifically, each of the 8 bytes in the field must have one of the

values 0 (UC), 1 (WC), 4 (WT), 5 (WP), 6 (WB), or 7 (UC-).

• If the “load IA32_EFER” VM-exit control is 1, bits reserved in the IA32_EFER MSR must be 0 in the field for that

register. In addition, the values of the LMA and LME bits in the field must each be that of the “host address-

space size” VM-exit control.

• If the “load CET state” VM-exit control is 1, the IA32_S_CET field must not set any bits reserved in the

IA32_S_CET MSR, and bit 10 (corresponding to SUPPRESS) and bit 11 (TRACKER) in the field cannot both be

set.

• If the “load CET state” VM-exit control is 1, bits 1:0 must be 0 in the SSP field.

• If the “load PKRS” VM-exit control is 1, bits 63:32 must be 0 in the IA32_PKRS field.

27.2.3 Checks on Host Segment and Descriptor-Table Registers

The following checks are performed on fields in the host-state area that correspond to segment and descriptor-

table registers:

• In the selector field for each of CS, SS, DS, ES, FS, GS, and TR, the RPL (bits 1:0) and the TI flag (bit 2) must

be 0.

• The selector fields for CS and TR cannot be 0000H.

• The selector field for SS cannot be 0000H if the “host address-space size” VM-exit control is 0.

• On processors that support Intel 64 architecture, the base-address fields for FS, GS, GDTR, IDTR, and TR must

contain canonical addresses.

1. The bits corresponding to CR0.NW (bit 29) and CR0.CD (bit 30) are never checked because the values of these bits are not changed

by VM exit; see Section 28.5.1.

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.

3. Bit 63 of the CR3 field in the host-state area must be 0. This is true even though, If CR4.PCIDE = 1, bit 63 of the source operand to

MOV to CR3 is used to determine whether cached translation information is invalidated.

Vol. 3C

27-7

VM ENTRIES

•

The CR0 field must not set any bit to a value not supported in VMX operation (see Section 24.8). The following

are exceptions:

— Bit 0 (corresponding to CR0.PE) and bit 31 (PG) are not checked if the “unrestricted guest” VM-execution

control is 1.¹

— Bit 29 (corresponding to CR0.NW) and bit 30 (CD) are never checked because the values of these bits are

not changed by VM entry; see Section 27.3.2.1.

•

If bit 31 in the CR0 field (corresponding to PG) is 1, bit 0 in that field (PE) must also be 1.²

•

The CR4 field must not set any bit to a value not supported in VMX operation (see Section 24.8).

•

If bit 23 in the CR4 field (corresponding to CET) is 1, bit 16 in the CR0 field (WP) must also be 1.

•

If the “load debug controls” VM-entry control is 1, bits reserved in the IA32_DEBUGCTL MSR must be 0 in the

field for that register. The first processors to support the virtual-machine extensions supported only the 1-

setting of this control and thus performed this check unconditionally.

•

The following checks are performed on processors that support Intel 64 architecture:

— If the “IA-32e mode guest” VM-entry control is 1, bit 31 in the CR0 field (corresponding to CR0.PG) and

bit 5 in the CR4 field (corresponding to CR4.PAE) must each be 1.³

— If the “IA-32e mode guest” VM-entry control is 0, bit 17 in the CR4 field (corresponding to CR4.PCIDE)

must be 0.

— The CR3 field must be such that bits 63:52 and bits in the range 51:32 beyond the processor’s physical-

address width are 0.^4,5

— If the “load debug controls” VM-entry control is 1, bits 63:32 in the DR7 field must be 0. The first

processors to support the virtual-machine extensions supported only the 1-setting of this control and thus

performed this check unconditionally (if they supported Intel 64 architecture).

— The IA32_SYSENTER_ESP field and the IA32_SYSENTER_EIP field must each contain a canonical address.

— If the “load CET state” VM-entry control is 1, the IA32_S_CET field and the

IA32_INTERRUPT_SSP_TABLE_ADDR field must contain canonical addresses.

•

If the “load IA32_PERF_GLOBAL_CTRL” VM-entry control is 1, bits reserved in the IA32_PERF_GLOBAL_CTRL

MSR must be 0 in the field for that register (see Figure 20-3).

•

If the “load IA32_PAT” VM-entry control is 1, the value of the field for the IA32_PAT MSR must be one that could

be written by WRMSR without fault at CPL 0. Specifically, each of the 8 bytes in the field must have one of the

values 0 (UC), 1 (WC), 4 (WT), 5 (WP), 6 (WB), or 7 (UC-).

•

If the “load IA32_EFER” VM-entry control is 1, the following checks are performed on the field for the

IA32_EFER MSR:

— Bits reserved in the IA32_EFER MSR must be 0.

— Bit 10 (corresponding to IA32_EFER.LMA) must equal the value of the “IA-32e mode guest” VM-entry

control. It must also be identical to bit 8 (LME) if bit 31 in the CR0 field (corresponding to CR0.PG) is 1.⁶

1.

“Unrestricted guest” is a secondary processor-based VM-execution control. If bit 31 of the primary processor-based VM-execution

controls is 0, VM entry functions as if the “unrestricted guest” VM-execution control were 0. See Section 25.6.2.

2. If the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PE must be 1 in VMX operation, bit 0 in the CR0 field must be 1

unless the “unrestricted guest” VM-execution control and bit 31 of the primary processor-based VM-execution controls are both 1.

3. If the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PG must be 1 in VMX operation, bit 31 in the CR0 field must be 1

unless the “unrestricted guest” VM-execution control and bit 31 of the primary processor-based VM-execution controls are both 1.

4. 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.

5. Bit 63 of the CR3 field in the guest-state area must be 0. This is true even though, If CR4.PCIDE = 1, bit 63 of the source operand to

MOV to CR3 is used to determine whether cached translation information is invalidated.

6. If the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PG must be 1 in VMX operation, bit 31 in the CR0 field must be 1

unless the “unrestricted guest” VM-execution control and bit 31 of the primary processor-based VM-execution controls are both 1.

Vol. 3C

27-9

VM ENTRIES

• If the “load IA32_BNDCFGS” VM-entry control is 1, the following checks are performed on the field for the

IA32_BNDCFGS MSR:

— Bits reserved in the IA32_BNDCFGS MSR must be 0.

— The linear address in bits 63:12 must be canonical.

• If the “load IA32_RTIT_CTL” VM-entry control is 1, bits reserved in the IA32_RTIT_CTL MSR must be 0 in the

field for that register (see Table 33-6).

• If the “load CET state” VM-entry control is 1, the IA32_S_CET field must not set any bits reserved in the

IA32_S_CET MSR, and bit 10 (corresponding to SUPPRESS) and bit 11 (TRACKER) of the field cannot both be

set.

• If the “load guest IA32_LBR_CTL” VM-entry control is 1, bits reserved in the IA32_LBR_CTL MSR must be 0 in

the field for that register.

• If the “load PKRS” VM-entry control is 1, bits 63:32 must be 0 in the IA32_PKRS field.

• If the “load UINV” VM-entry control is 1, bits 15:8 must be 0 in the guest UINV field.

27.3.1.2 Checks on Guest Segment Registers

This section specifies the checks on the fields for CS, SS, DS, ES, FS, GS, TR, and LDTR. The following terms are

used in defining these checks:

• The guest will be virtual-8086 if the VM flag (bit 17) is 1 in the RFLAGS field in the guest-state area.

• The guest will be IA-32e mode if the “IA-32e mode guest” VM-entry control is 1. (This is possible only on

processors that support Intel 64 architecture.)

• Any one of these registers is said to be usable if the unusable bit (bit 16) is 0 in the access-rights field for that

register.

The following are the checks on these fields:

•

Selector fields.

— TR. The TI flag (bit 2) must be 0.

— LDTR. If LDTR is usable, the TI flag (bit 2) must be 0.

— SS. If the guest will not be virtual-8086 and the “unrestricted guest” VM-execution control is 0, the RPL

(bits 1:0) must equal the RPL of the selector field for CS.¹

•

Base-address fields.

— CS, SS, DS, ES, FS, GS. If the guest will be virtual-8086, the address must be the selector field shifted left

4 bits (multiplied by 16).

— The following checks are performed on processors that support Intel 64 architecture:

• TR, FS, GS. The address must be canonical.

• LDTR. If LDTR is usable, the address must be canonical.

• CS. Bits 63:32 of the address must be zero.

• SS, DS, ES. If the register is usable, bits 63:32 of the address must be zero.

•

Limit fields for CS, SS, DS, ES, FS, GS. If the guest will be virtual-8086, the field must be 0000FFFFH.

•

Access-rights fields.

— CS, SS, DS, ES, FS, GS.

• If the guest will be virtual-8086, the field must be 000000F3H. This implies the following:

— Bits 3:0 (Type) must be 3, indicating an expand-up read/write accessed data segment.

— Bit 4 (S) must be 1.

1.

“Unrestricted guest” is a secondary processor-based VM-execution control. If bit 31 of the primary processor-based VM-execution

controls is 0, VM entry functions as if the “unrestricted guest” VM-execution control were 0. See Section 25.6.2.

27-10

Vol. 3C

VM ENTRIES

— Bits 6:5 (DPL) must be 3.

— Bit 7 (P) must be 1.

— Bits 11:8 (reserved), bit 12 (software available), bit 13 (reserved/L), bit 14 (D/B), bit 15 (G),

bit 16 (unusable), and bits 31:17 (reserved) must all be 0.

•

If the guest will not be virtual-8086, the different sub-fields are considered separately:

— Bits 3:0 (Type).

• CS. The values allowed depend on the setting of the “unrestricted guest” VM-execution

control:

— If the control is 0, the Type must be 9, 11, 13, or 15 (accessed code segment).

— If the control is 1, the Type must be either 3 (read/write accessed expand-up data

segment) or one of 9, 11, 13, and 15 (accessed code segment).

• SS. If SS is usable, the Type must be 3 or 7 (read/write, accessed data segment).

• DS, ES, FS, GS. The following checks apply if the register is usable:

— Bit 0 of the Type must be 1 (accessed).

— If bit 3 of the Type is 1 (code segment), then bit 1 of the Type must be 1 (readable).

— Bit 4 (S). If the register is CS or if the register is usable, S must be 1.

— Bits 6:5 (DPL).

• CS.

— If the Type is 3 (read/write accessed expand-up data segment), the DPL must be 0. The

Type can be 3 only if the “unrestricted guest” VM-execution control is 1.

— If the Type is 9 or 11 (non-conforming code segment), the DPL must equal the DPL in the

access-rights field for SS.

— If the Type is 13 or 15 (conforming code segment), the DPL cannot be greater than the

DPL in the access-rights field for SS.

• SS.

— If the “unrestricted guest” VM-execution control is 0, the DPL must equal the RPL from the

selector field.

— The DPL must be 0 either if the Type in the access-rights field for CS is 3 (read/write

accessed expand-up data segment) or if bit 0 in the CR0 field (corresponding to CR0.PE) is

0.¹

• DS, ES, FS, GS. The DPL cannot be less than the RPL in the selector field if

(1) the

“unrestricted guest” VM-execution control is 0; (2) the register is usable; and (3) the Type in

the access-rights field is in the range 0 - 11 (data segment or non-conforming code segment).

— Bit 7 (P). If the register is CS or if the register is usable, P must be 1.

— Bits 11:8 (reserved). If the register is CS or if the register is usable, these bits must all be 0.

— Bit 14 (D/B). For CS, D/B must be 0 if the guest will be IA-32e mode and the L bit (bit 13) in the

access-rights field is 1.

— Bit 15 (G). The following checks apply if the register is CS or if the register is usable:

• If any bit in the limit field in the range 11:0 is 0, G must be 0.

• If any bit in the limit field in the range 31:20 is 1, G must be 1.

— Bits 31:17 (reserved). If the register is CS or if the register is usable, these bits must all be 0.

1.

The following apply if either the “unrestricted guest” VM-execution control or bit 31 of the primary processor-based VM-execution

controls is 0: (1) bit 0 in the CR0 field must be 1 if the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PE must be 1 in VMX

operation; and (2) the Type in the access-rights field for CS cannot be 3.

Vol. 3C

27-11

VM ENTRIES

— TR. The different sub-fields are considered separately:

• Bits 3:0 (Type).

— If the guest will not be IA-32e mode, the Type must be 3 (16-bit busy TSS) or 11 (32-bit busy

TSS).

— If the guest will be IA-32e mode, the Type must be 11 (64-bit busy TSS).

• Bit 4 (S). S must be 0.

• Bit 7 (P). P must be 1.

• Bits 11:8 (reserved). These bits must all be 0.

• Bit 15 (G).

— If any bit in the limit field in the range 11:0 is 0, G must be 0.

— If any bit in the limit field in the range 31:20 is 1, G must be 1.

• Bit 16 (Unusable). The unusable bit must be 0.

• Bits 31:17 (reserved). These bits must all be 0.

— LDTR. The following checks on the different sub-fields apply only if LDTR is usable:

• Bits 3:0 (Type). The Type must be 2 (LDT).

• Bit 4 (S). S must be 0.

• Bit 7 (P). P must be 1.

• Bits 11:8 (reserved). These bits must all be 0.

• Bit 15 (G).

— If any bit in the limit field in the range 11:0 is 0, G must be 0.

— If any bit in the limit field in the range 31:20 is 1, G must be 1.

• Bits 31:17 (reserved). These bits must all be 0.

27.3.1.3 Checks on Guest Descriptor-Table Registers

The following checks are performed on the fields for GDTR and IDTR:

• On processors that support Intel 64 architecture, the base-address fields must contain canonical addresses.

• Bits 31:16 of each limit field must be 0.

27.3.1.4 Checks on Guest RIP, RFLAGS, and SSP

The following checks are performed on fields in the guest-state area corresponding to RIP, RFLAGS, and SSP

(shadow-stack pointer):

• RIP. The following checks are performed on processors that support Intel 64 architecture:

— Bits 63:32 must be 0 if the “IA-32e mode guest” VM-entry control is 0 or if the L bit (bit 13) in the access-

rights field for CS is 0.

— If the processor supports N < 64 linear-address bits, bits 63:N must be identical if the “IA-32e mode guest”

VM-entry control is 1 and the L bit in the access-rights field for CS is 1.¹ (No check applies if the processor

supports 64 linear-address bits.) The guest RIP value is not required to be canonical; the value of bit N-1

may differ from that of bit N.

• RFLAGS.

— Reserved bits 63:22 (bits 31:22 on processors that do not support Intel 64 architecture), bit 15, bit 5 and

bit 3 must be 0 in the field, and reserved bit 1 must be 1.

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.

27-12

Vol. 3C

VM ENTRIES

— The VM flag (bit 17) must be 0 either if the “IA-32e mode guest” VM-entry control is 1 or if bit 0 in the CR0

field (corresponding to CR0.PE) is 0.¹

— The IF flag (RFLAGS[bit 9]) must be 1 if the valid bit (bit 31) in the VM-entry interruption-information field

is 1 and the interruption type (bits 10:8) is external interrupt.

• SSP. The following checks are performed if the “load CET state” VM-entry control is 1

— Bits 1:0 must be 0.

— If the processor supports the Intel 64 architecture, bits 63:N must be identical, where N is the CPU’s

maximum linear-address width. (This check does not apply if the processor supports 64 linear-address

bits.) The guest SSP value is not required to be canonical; the value of bit N-1 may differ from that of bit N.

27.3.1.5 Checks on Guest Non-Register State

The following checks are performed on fields in the guest-state area corresponding to non-register state:

•

Activity state.

— The activity-state field must contain a value in the range 0 - 3, indicating an activity state supported by the

implementation (see Section 25.4.2). Future processors may include support for other activity states.

Software should read the VMX capability MSR IA32_VMX_MISC (see Appendix A.6) to determine what

activity states are supported.

— The activity-state field must not indicate the HLT state if the DPL (bits 6:5) in the access-rights field for SS

is not 0.²

— The activity-state field must indicate the active state if the interruptibility-state field indicates blocking by

either MOV-SS or by STI (if either bit 0 or bit 1 in that field is 1).

— If the valid bit (bit 31) in the VM-entry interruption-information field is 1, the interruption to be delivered

(as defined by interruption type and vector) must not be one that would normally be blocked while a logical

processor is in the activity state corresponding to the contents of the activity-state field. The following

items enumerate the interruptions (as specified in the VM-entry interruption-information field) whose

injection is allowed for the different activity states:

• Active. Any interruption is allowed.

• HLT. The only events allowed are the following:

— Those with interruption type external interrupt or non-maskable interrupt (NMI).

— Those with interruption type hardware exception and vector 1 (debug exception) or vector 18

(machine-check exception).

— Those with interruption type other event and vector 0 (pending MTF VM exit).

See Table 25-17 in Section 25.8.3 for details regarding the format of the VM-entry interruption-

information field.

• Shutdown. Only NMIs and machine-check exceptions are allowed.

• Wait-for-SIPI. No interruptions are allowed.

— The activity-state field must not indicate the wait-for-SIPI state if the “entry to SMM” VM-entry control is 1.

•

Interruptibility state.

— The reserved bits (bits 31:5) must be 0.

— The field cannot indicate blocking by both STI and MOV SS (bits 0 and 1 cannot both be 1).

— Bit 0 (blocking by STI) must be 0 if the IF flag (bit 9) is 0 in the RFLAGS field.

1. If the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PE must be 1 in VMX operation, bit 0 in the CR0 field must be 1

unless the “unrestricted guest” VM-execution control and bit 31 of the primary processor-based VM-execution controls are both 1.

2. As noted in Section 25.4.1, SS.DPL corresponds to the logical processor’s current privilege level (CPL).

Vol. 3C

27-13

VM ENTRIES

— Bit 0 (blocking by STI) and bit 1 (blocking by MOV-SS) must both be 0 if the valid bit (bit 31) in the

VM-entry interruption-information field is 1 and the interruption type (bits 10:8) in that field has value 0,

indicating external interrupt, or value 2, indicating non-maskable interrupt (NMI).

— Bit 2 (blocking by SMI) must be 0 if the processor is not in SMM.

— Bit 2 (blocking by SMI) must be 1 if the “entry to SMM” VM-entry control is 1.

— Bit 3 (blocking by NMI) must be 0 if the “virtual NMIs” VM-execution control is 1, the valid bit (bit 31) in the

VM-entry interruption-information field is 1, and the interruption type (bits 10:8) in that field has value 2

(indicating NMI).

— If bit 4 (enclave interruption) is 1, bit 1 (blocking by MOV-SS) must be 0 and the processor must support

for SGX by enumerating CPUID.(EAX=07H,ECX=0):EBX.SGX[bit 2] as 1.

NOTE

If the “virtual NMIs” VM-execution control is 0, there is no requirement that bit 3 be 0 if the valid bit

in the VM-entry interruption-information field is 1 and the interruption type in that field has value 2.

•

Pending debug exceptions.

— Bits 11:4, bit 13, bit 15, and bits 63:17 (bits 31:17 on processors that do not support Intel 64 architecture)

must be 0.

— The following checks are performed if any of the following holds: (1) the interruptibility-state field indicates

blocking by STI (bit 0 in that field is 1); (2) the interruptibility-state field indicates blocking by MOV SS

(bit 1 in that field is 1); or (3) the activity-state field indicates HLT:

• Bit 14 (BS) must be 1 if the TF flag (bit 8) in the RFLAGS field is 1 and the BTF flag (bit 1) in the

IA32_DEBUGCTL field is 0.

• Bit 14 (BS) must be 0 if the TF flag (bit 8) in the RFLAGS field is 0 or the BTF flag (bit 1) in the

IA32_DEBUGCTL field is 1.

— The following checks are performed if bit 16 (RTM) is 1:

• Bits 11:0, bits 15:13, and bits 63:17 (bits 31:17 on processors that do not support Intel 64 archi-

tecture) must be 0; bit 12 must be 1.

• The processor must support for RTM by enumerating CPUID.(EAX=07H,ECX=0):EBX[bit 11] as 1.

• The interruptibility-state field must not indicate blocking by MOV SS (bit 1 in that field must be 0).

•

VMCS link pointer. The following checks apply if the field contains a value other than FFFFFFFF_FFFFFFFFH:

— Bits 11:0 must be 0.

— Bits beyond the processor’s physical-address width must be 0.^1,2

— The 4 bytes located in memory referenced by the value of the field (as a physical address) must satisfy the

following:

• Bits 30:0 must contain the processor’s VMCS revision identifier (see Section 25.2).³

• Bit 31 must contain the setting of the “VMCS shadowing” VM-execution control.⁴ This implies that the

referenced VMCS is a shadow VMCS (see Section 25.10) if and only if the “VMCS shadowing” VM-

execution control is 1.

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.

2. If IA32_VMX_BASIC[48] is read as 1, this field must not set any bits in the range 63:32; see Appendix A.1.

3. Earlier versions of this manual specified that the VMCS revision identifier was a 32-bit field. For all processors produced prior to this

change, bit 31 of the VMCS revision identifier was 0.

4.

“VMCS shadowing” is a secondary processor-based VM-execution control. If bit 31 of the primary processor-based VM-execution

controls is 0, VM entry functions as if the “VMCS shadowing” VM-execution control were 0. See Section 25.6.2.

27-14

Vol. 3C

VM ENTRIES

— If the processor is not in SMM or the “entry to SMM” VM-entry control is 1, the field must not contain the

current VMCS pointer.

— If the processor is in SMM and the “entry to SMM” VM-entry control is 0, the field must differ from the

executive-VMCS pointer.

27.3.1.6

Checks on Guest Page-Directory-Pointer-Table Entries

If CR0.PG =1, CR4.PAE = 1, and IA32_EFER.LME = 0, the logical processor uses PAE paging (see Section 4.4 in

the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A).¹ When 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.

A VM entry is to a guest that uses PAE paging if (1) bit 31 (corresponding to CR0.PG) is set in the CR0 field in the

guest-state area; (2) bit 5 (corresponding to CR4.PAE) is set in the CR4 field; and (3) the “IA-32e mode guest”

VM-entry control is 0. Such a VM entry checks the validity of the PDPTEs:

• If the “enable EPT” VM-execution control is 0, VM entry checks the validity of the PDPTEs referenced by the CR3

field in the guest-state area if either (1) PAE paging was not in use before the VM entry; or (2) the value of CR3

is changing as a result of the VM entry. VM entry may check their validity even if neither (1) nor (2) hold.²

• If the “enable EPT” VM-execution control is 1, VM entry checks the validity of the PDPTE fields in the guest-

state area (see Section 25.4.2).

A VM entry to a guest that does not use PAE paging does not check the validity of any PDPTEs.

A VM entry 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), the VM entry fails.

27.3.2

Loading Guest State

Processor state is updated on VM entries in the following ways:

• Some state is loaded from the guest-state area.

• Some state is determined by VM-entry controls.

• The page-directory pointers are loaded based on the values of certain control registers.

This loading may be performed in any order and in parallel with the checking of VMCS contents (see Section

27.3.1).

The loading of guest state is detailed in Section 27.3.2.1 to Section 27.3.2.4. These sections reference VMCS fields

that correspond to processor state. Unless otherwise stated, these references are to fields in the guest-state area.

In addition to the state loading described in this section, VM entries may load MSRs from the VM-entry MSR-load

area (see Section 27.4). This loading occurs only after the state loading described in this section and the checking

of VMCS contents described in Section 27.3.1.

27.3.2.1 Loading Guest Control Registers, Debug Registers, and MSRs

The following items describe how guest control registers, debug registers, and MSRs are loaded on VM entry:

1. On processors that support Intel 64 architecture, the physical-address extension may support more than 36 physical-address bits.

Software can determine the number physical-address bits supported by executing CPUID with 80000008H in EAX. The physical-

address width is returned in bits 7:0 of EAX.

2.

“Enable EPT” is a secondary processor-based VM-execution control. If bit 31 of the primary processor-based VM-execution controls

is 0, VM entry functions as if the “enable EPT” VM-execution control were 0. See Section 25.6.2.

3. This implies that (1) bits 11:9 in each PDPTE are ignored; and (2) if bit 0 (present) is clear in one of the PDPTEs, bits 63:1 of that

PDPTE are ignored.

Vol. 3C

27-15

VM ENTRIES

•

CR0 is loaded from the CR0 field with the exception of the following bits, which are never modified on VM entry:

ET (bit 4); reserved bits 15:6, 17, and 28:19; NW (bit 29) and CD (bit 30).¹ The values of these bits in the CR0

field are ignored.

•

CR3 and CR4 are loaded from the CR3 field and the CR4 field, respectively.

•

If the “load debug controls” VM-entry control is 1, DR7 is loaded from the DR7 field with the exception that

bit 12 and bits 15:14 are always 0 and bit 10 is always 1. The values of these bits in the DR7 field are ignored.

The first processors to support the virtual-machine extensions supported only the 1-setting of the “load

debug controls” VM-entry control and thus always loaded DR7 from the DR7 field.

•

The following describes how certain MSRs are loaded using fields in the guest-state area:

— If the “load debug controls” VM-entry control is 1, the IA32_DEBUGCTL MSR is loaded from the

IA32_DEBUGCTL field. The first processors to support the virtual-machine extensions supported only the 1-

setting of this control and thus always loaded the IA32_DEBUGCTL MSR from the IA32_DEBUGCTL field.

— The IA32_SYSENTER_CS MSR is loaded from the IA32_SYSENTER_CS field. Since this 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 field

and the IA32_SYSENTER_EIP field, respectively. On processors that do not support Intel 64 architecture,

these fields have only 32 bits; bits 63:32 of the MSRs are cleared to 0.

— The following 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 27.3.2.2).

• If the “load IA32_EFER” VM-entry control is 0, bits in the IA32_EFER MSR are modified as follows:

— IA32_EFER.LMA is loaded with the setting of the “IA-32e mode guest” VM-entry control.

— If CR0 is being loaded so that CR0.PG = 1, IA32_EFER.LME is also loaded with the setting of the

“IA-32e mode guest” VM-entry control.² Otherwise, IA32_EFER.LME is unmodified.

See below for the case in which the “load IA32_EFER” VM-entry control is 1

— If the “load IA32_PERF_GLOBAL_CTRL” VM-entry control is 1, the IA32_PERF_GLOBAL_CTRL MSR is loaded

from the IA32_PERF_GLOBAL_CTRL field.

— If the “load IA32_PAT” VM-entry control is 1, the IA32_PAT MSR is loaded from the IA32_PAT field.

— If the “load IA32_EFER” VM-entry control is 1, the IA32_EFER MSR is loaded from the IA32_EFER field.

— If the “load IA32_BNDCFGS” VM-entry control is 1, the IA32_BNDCFGS MSR is loaded from the

IA32_BNDCFGS field.

— If the “load IA32_RTIT_CTL” VM-entry control is 1, the IA32_RTIT_CTL MSR is loaded from the

IA32_RTIT_CTL field.

— If the “load CET” VM-entry control is 1, the IA32_S_CET and IA32_INTERRUPT_SSP_TABLE_ADDR MSRs

are loaded from the IA32_S_CET field and the IA32_INTERRUPT_SSP_TABLE_ADDR field, respectively. On

processors that do not support Intel 64 architecture, these fields have only 32 bits; bits 63:32 of the MSRs

are cleared to 0.

— If the “load guest IA32_LBR_CTL” VM-entry control is 1, the IA32_LBR_CTL MSR is loaded from the

IA32_LBR_CTL guest state field.

— If the “load PKRS” VM-entry control is 1, the IA32_PKRS MSR is loaded from the IA32_PKRS field.

— If the “load UINV” VM-entry control is 1, UINV is loaded with the low 8 bits of the UINV field. UINV is

represented in bits 39:32 of the IA32_UINTR_MISC MSR. The remainder of the MSR is not modified.

1.

Bits 15:6, bit 17, and bit 28:19 of CR0 and CR0.ET are unchanged by executions of MOV to CR0. Bits 15:6, bit 17, and bit 28:19 of

CR0 are always 0 and CR0.ET is always 1.

2.

If the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PG must be 1 in VMX operation, VM entry must be loading CR0 so

that CR0.PG = 1 unless the “unrestricted guest” VM-execution control and bit 31 of the primary processor-based VM-execution con-

trols are both 1.

27-16

Vol. 3C

VM ENTRIES

• Bits 63:32 of RSP are undefined outside 64-bit mode. Thus, a logical processor may ignore the contents of

bits 63:32 of the RSP field on VM entries that are not to 64-bit mode.

• As noted in Section 27.3.1.4, bits 63:32 of the RIP and RFLAGS fields must be 0 on VM entries that are not to

64-bit mode. (The same is true for SSP for VM entries that are not to 64-bit mode when the “load CET” VM-

entry control is 1.)

27.3.2.4 Loading Page-Directory-Pointer-Table Entries

As noted in Section 27.3.1.6, the logical processor uses PAE paging if CR0.PG = 1, CR4.PAE = 1, and

IA32_EFER.LME = 0. A VM entry to a guest that uses PAE paging loads the PDPTEs into internal, non-architectural

registers based on the setting of the “enable EPT” VM-execution control:

• If the control is 0, the PDPTEs are loaded from the page-directory-pointer table referenced by the physical

address in the value of CR3 being loaded by the VM entry (see Section 27.3.2.1). The values loaded are treated

as physical addresses in VMX non-root operation.

• If the control is 1, the PDPTEs are loaded from corresponding fields in the guest-state area (see Section

25.4.2). The values loaded are treated as guest-physical addresses in VMX non-root operation.

27.3.2.5 Updating Non-Register State

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 entries 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 entries 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.

If the “virtual-interrupt delivery” VM-execution control is 1, VM entry loads the values of RVI and SVI from the

guest interrupt-status field in the VMCS (see Section 25.4.2). After doing so, the logical processor first causes PPR

virtualization (Section 30.1.3) and then evaluates pending virtual interrupts (Section 30.2.1).

If a virtual interrupt is recognized, it may be delivered in VMX non-root operation immediately after VM entry

(including any specified event injection) completes; see Section 27.7.5. See Section 30.2.2 for details regarding

the delivery of virtual interrupts.

27.3.3 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 entries clear any address-range monitoring that may be in effect.

27.4

LOADING MSRS

VM entries may load MSRs from the VM-entry MSR-load area (see Section 25.8.2). Specifically each entry in that

area (up to the number specified in the VM-entry 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 C0000101 (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.

1. Because attempts to modify the value of IA32_EFER.LMA by WRMSR are ignored, attempts to modify it using the VM-entry MSR-

load area are also ignored.

27-18

Vol. 3C

VM ENTRIES

• The value of bits 31:0 indicates an MSR that can be written only in system-management mode (SMM) and the

VM entry did not commence 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 entries 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.¹

The VM entry fails if processing fails for any entry. The logical processor responds to such failures by loading state

from the host-state area, as it would for a VM exit. See Section 27.8.

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 entry, the logical processor will not use any translations that were cached before the transition.

27.5

TRACE-ADDRESS PRE-TRANSLATION (TAPT)

When the “Intel PT uses guest physical addresses” VM-execution control is 1, the addresses used by Intel PT are

treated as guest-physical addresses, and these are translated to physical addresses using EPT.

VM entry uses trace-address pre-translation (TAPT) to prevent buffered trace data from being lost due to an

EPT violation; see Section 26.5.4.2. VM entry uses TAPT only if Intel PT will be enabled following VM entry

(IA32_RTIT_CTL.TraceEn = 1) and only if the “Intel PT uses guest physical addresses” VM-execution control is 1

As noted in Section 26.5.4, TAPT may cause a VM exit due to an EPT violation, EPT misconfiguration, page-modifi-

cation log-full event, or APIC access. If such a VM exit occurs as a result of TAPT during VM entry, the VM exit oper-

ates as if it had occurred in VMX non-root operation after the VM entry completed (in the guest context).

If TAPT during VM entry causes a VM exit, the VM entry does not perform event injection (Section 27.6), even if the

valid bit in the VM-entry interruption-information field is 1. Such VM exits save the contents of VM-entry interrup-

tion-information and VM-entry exception error code fields into the IDT-vectoring information and IDT-vectoring

error code fields, respectively.

27.6

EVENT INJECTION

If the valid bit in the VM-entry interruption-information field (see Section 25.8.3) is 1, VM entry causes an event to

be delivered (or made pending) after all components of guest state have been loaded (including MSRs) and after

the VM-execution control fields have been established.

• If the interruption type in the field is 0 (external interrupt), 2 (non-maskable interrupt); 3 (hardware

exception), 4 (software interrupt), 5 (privileged software exception), or 6 (software exception), the event is

delivered as described in Section 27.6.1.

• If the interruption type in the field is 7 (other event) and the vector field is 0, an MTF VM exit is pending after

VM entry. See Section 27.6.2.

27.6.1 Vectored-Event Injection

VM entry delivers an injected vectored event within the guest context established by VM entry. This means that

delivery occurs after all components of guest state have been loaded (including MSRs) and after the VM-execution

control fields have been established.² The event is delivered using the vector in that field to select a descriptor in

the IDT. Since event injection occurs after loading IDTR from the guest-state area, this is the guest IDT.

1. If CR0.PG = 1, WRMSR to the IA32_EFER MSR causes a general-protection exception if it would modify the LME bit. If VM entry has

established CR0.PG = 1, the IA32_EFER MSR should not be included in the VM-entry MSR-load area for the purpose of modifying the

LME bit.

Vol. 3C

27-19

VM ENTRIES

Section 27.6.1.1 provides details of vectored-event injection. In general, the event is delivered exactly as if it had

been generated normally.

An exception is made if the following all hold: bit 25 (UINTR) is set to 1 in the guest CR4 field and the “IA-32e mode

guest” VM-entry control is 1, and VM entry is modified if it is injecting an external interrupt whose vector is the

value that UINV would have after VM entry. In this case, the logical processor then performs user-interrupt notifi-

cation processing as specified in Section 7.5.2 instead of the process described in Section 27.6.1.1. (If the guest

activity-state field indicated the HLT state, the logical processor enters the HLT state following user-interrupt noti-

fication processing.)

If event delivery (or user-interrupt notification processing; see above) encounters a nested exception (for

example, a general-protection exception because the vector indicates a descriptor beyond the IDT limit), the

exception bitmap is consulted using the vector of that exception:

• If the bit for the nested exception is 0, the nested exception is delivered normally. If the nested exception is

benign, it is delivered through the IDT. If it is contributory or a page fault, a double fault may be generated,

depending on the nature of the event whose delivery encountered the nested exception. See Chapter 6,

“Interrupt 8—Double Fault Exception (#DF)” in the Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 3A.¹

• If the bit for the nested exception is 1, a VM exit occurs. Section 27.6.1.2 details cases in which event injection

causes a VM exit.

27.6.1.1 Details of Vectored-Event Injection

The event-injection process is controlled by the contents of the VM-entry interruption information field (format

given in Table 25-17), the VM-entry exception error-code field, and the VM-entry instruction-length field. The

following items provide details of the process:

•

The value pushed on the stack for RFLAGS is generally that which was loaded from the guest-state area. The

value pushed for the RF flag is not modified based on the type of event being delivered. However, the pushed

value of RFLAGS may be modified if a software interrupt is being injected into a guest that will be in virtual-

8086 mode (see below). After RFLAGS is pushed on the stack, the value in the RFLAGS register is modified as

is done normally when delivering an event through the IDT.

•

The instruction pointer that is pushed on the stack depends on the type of event and whether nested exceptions

occur during its delivery. The term current guest RIP refers to the value to be loaded from the guest-state

area. The value pushed is determined as follows:²

— If VM entry successfully injects (with no nested exception) an event with interruption type external

interrupt, NMI, or hardware exception, the current guest RIP is pushed on the stack.

— If VM entry successfully injects (with no nested exception) an event with interruption type software

interrupt, privileged software exception, or software exception, the current guest RIP is incremented by the

VM-entry instruction length before being pushed on the stack.

— If VM entry encounters an exception while injecting an event and that exception does not cause a VM exit,

the current guest RIP is pushed on the stack regardless of event type or VM-entry instruction length. If the

encountered exception does cause a VM exit that saves RIP, the saved RIP is current guest RIP.

•

If the deliver-error-code bit (bit 11) is set in the VM-entry interruption-information field, the contents of the

VM-entry exception error-code field is pushed on the stack as an error code would be pushed during delivery of

an exception.

•

DR6, DR7, and the IA32_DEBUGCTL MSR are not modified by event injection, even if the event has vector 1

(normal deliveries of debug exceptions, which have vector 1, do update these registers).

2.

This does not imply that injection of an exception or interrupt will cause a VM exit due to the settings of VM-execution control fields

(such as the exception bitmap) that would cause a VM exit if the event had occurred in VMX non-root operation. In contrast, a nested

exception encountered during event delivery may cause a VM exit; see Section 27.6.1.1.

1.

Hardware exceptions with the following unused vectors are considered benign: 15 and 21-31. A hardware exception with vector 20

is considered benign unless the processor supports the 1-setting of the “EPT-violation #VE” VM-execution control; in that case, it

has the same severity as page faults.

2.

While these items refer to RIP, the width of the value pushed (16 bits, 32 bits, or 64 bits) is determined normally.

27-20

Vol. 3C

VM ENTRIES

• If event delivery generates a double-fault exception (due to a nested exception); the logical processor

encounters another nested exception while attempting to call the double-fault handler; and that exception does

not cause a VM exit due to the exception bitmap; then a VM exit occurs due to triple fault (see Section 26.2).

• If event delivery injects a double-fault exception and encounters a nested exception that does not cause a

VM exit due to the exception bitmap, then a VM exit occurs due to triple fault (see Section 26.2).

• If the “virtualize APIC accesses” VM-execution control is 1 and event delivery generates an access to the APIC-

access page, that access is treated as described in Section 30.4 and may cause a VM exit.¹

If the event-delivery process does cause a VM exit, the processor state before the VM exit is determined just as it

would be had the injected event occurred during normal execution in VMX non-root operation. If the injected event

directly accesses a task gate that cause a VM exit or if the first nested exception encountered causes a VM exit,

information about the injected event is saved in the IDT-vectoring information field (see Section 28.2.4).

The material in this section applies also if injection of an external interrupt results in user-interrupt notification

processing instead of event delivery (see Section 27.6.1 earlier).

27.6.1.3 Event Injection for VM Entries to Real-Address Mode

If VM entry is loading CR0.PE with 0, any injected vectored event is delivered as would normally be done in real-

address mode.² Specifically, VM entry uses the vector provided in the VM-entry interruption-information field to

select a 4-byte entry from an interrupt-vector table at the linear address in IDTR.base. Further details are provided

in Section 15.1.4 in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A.

Because bit 11 (deliver error code) in the VM-entry interruption-information field must be 0 if CR0.PE will be 0 after

VM entry (see Section 27.2.1.3), vectored events injected with CR0.PE = 0 do not push an error code on the stack.

This is consistent with event delivery in real-address mode.

If event delivery encounters a fault (due to a violation of IDTR.limit or of SS.limit), the fault is treated as if it had

occurred during event delivery in VMX non-root operation. Such a fault may lead to a VM exit as discussed in

Section 27.6.1.2.

27.6.2 Injection of Pending MTF VM Exits

If the interruption type in the VM-entry interruption-information field is 7 (other event) and the vector field is 0,

VM entry causes an MTF VM exit to be pending on the instruction boundary following VM entry. This is the case

even if the “monitor trap flag” VM-execution control is 0. See Section 26.5.2 for the treatment of pending MTF

VM exits.

27.7

SPECIAL FEATURES OF VM ENTRY

This section details a variety of features of VM entry. It uses the following terminology: a VM entry is vectoring if

the valid bit (bit 31) of the VM-entry interruption information field is 1 and the interruption type in the field is 0

(external interrupt), 2 (non-maskable interrupt); 3 (hardware exception), 4 (software interrupt), 5 (privileged

software exception), or 6 (software exception).

27.7.1 Interruptibility State

The interruptibility-state field in the guest-state area (see Table 25-3) contains bits that control blocking by STI,

blocking by MOV SS, and blocking by NMI. This field impacts event blocking after VM entry as follows:

1.

“Virtualize APIC accesses” is a secondary processor-based VM-execution control. If bit 31 of the primary processor-based VM-execu-

tion controls is 0, VM entry functions as if the “virtualize APIC accesses” VM-execution control were 0. See Section 25.6.2.

2. If the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PE must be 1 in VMX operation, VM entry must be loading CR0.PE

with 1 unless the “unrestricted guest” VM-execution control and bit 31 of the primary processor-based VM-execution controls are

both 1.

27-22

Vol. 3C

VM ENTRIES

•

If the VM entry is vectoring, there is no blocking by STI or by MOV SS following the VM entry, regardless of the

contents of the interruptibility-state field.

•

If the VM entry is not vectoring, the following apply:

— Events are blocked by STI if and only if bit 0 in the interruptibility-state field is 1. This blocking is cleared

after the guest executes one instruction or incurs an exception (including a debug exception made pending

by VM entry; see Section 27.7.3).

— Events are blocked by MOV SS if and only if bit 1 in the interruptibility-state field is 1. This may affect the

treatment of pending debug exceptions; see Section 27.7.3. This blocking is cleared after the guest

executes one instruction or incurs an exception (including a debug exception made pending by VM entry).

•

The blocking of non-maskable interrupts (NMIs) is determined as follows:

— If the “virtual NMIs” VM-execution control is 0, NMIs are blocked if and only if bit 3 (blocking by NMI) in the

interruptibility-state field is 1. If the “NMI exiting” VM-execution control is 0, execution of the IRET

instruction removes this blocking (even if the instruction generates a fault). If the “NMI exiting” control is

1, IRET does not affect this blocking.

— The following items describe the use of bit 3 (blocking by NMI) in the interruptibility-state field if the

“virtual NMIs” VM-execution control is 1:

• The bit’s value does not affect the blocking of NMIs after VM entry. NMIs are not blocked in VMX non-

root operation (except for ordinary blocking for other reasons, such as by the MOV SS instruction, the

wait-for-SIPI state, etc.)

• The bit’s value determines whether there is virtual-NMI blocking after VM entry. If the bit is 1, virtual-

NMI blocking is in effect after VM entry. If the bit is 0, there is no virtual-NMI blocking after VM entry

unless the VM entry is injecting an NMI (see Section 27.6.1.1). Execution of IRET removes virtual-NMI

blocking (even if the instruction generates a fault).

If the “NMI exiting” VM-execution control is 0, the “virtual NMIs” control must be 0; see Section 27.2.1.1.

•

Blocking of system-management interrupts (SMIs) is determined as follows:

— If the VM entry was not executed in system-management mode (SMM), SMI blocking is unchanged by

VM entry.

— If the VM entry was executed in SMM, SMIs are blocked after VM entry if and only if the bit 2 in the inter-

ruptibility-state field is 1.

27.7.2 Activity State

The activity-state field in the guest-state area controls whether, after VM entry, the logical processor is active or in

one of the inactive states identified in Section 25.4.2. The use of this field is determined as follows:

• If the VM entry is vectoring, the logical processor is in the active state after VM entry. While the consistency

checks described in Section 27.3.1.5 on the activity-state field do apply in this case, the contents of the

activity-state field do not determine the activity state after VM entry.

• If the VM entry is not vectoring, the logical processor ends VM entry in the activity state specified in the guest-

state area. If VM entry ends with the logical processor in an inactive activity state, the VM entry generates any

special bus cycle that is normally generated when that activity state is entered from the active state. If

VM entry would end with the logical processor in the shutdown state and the logical processor is in SMX

operation,¹ an Intel^® TXT shutdown condition occurs. The error code used is 0000H, indicating “legacy

shutdown.” See the Intel^® Trusted Execution Technology Preliminary Architecture Specification.

• Some activity states unconditionally block certain events. The following blocking is in effect after any VM entry

that puts the processor in the indicated state:

— The active state blocks start-up IPIs (SIPIs). SIPIs that arrive while a logical processor is in the active state

and in VMX non-root operation are discarded and do not cause VM exits.

1. A logical processor is in SMX operation if GETSEC[SEXIT] has not been executed since the last execution of GETSEC[SENTER]. See

Chapter 6, “Safer Mode Extensions Reference,” in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2B.

Vol. 3C

27-23

VM ENTRIES

27.7.4 VMX-Preemption Timer

If the “activate VMX-preemption timer” VM-execution control is 1, VM entry starts the VMX-preemption timer with

the unsigned value in the VMX-preemption timer-value field.

It is possible for the VMX-preemption timer to expire during VM entry (e.g., if the value in the VMX-preemption

timer-value field is zero). If this happens (and if the VM entry was not to the wait-for-SIPI state), a VM exit occurs

with its normal priority after any event injection and before execution of any instruction following VM entry. For

example, any pending debug exceptions established by VM entry (see Section 27.7.3) take priority over a timer-

induced VM exit. (The timer-induced VM exit will occur after delivery of the debug exception, unless that exception

or its delivery causes a different VM exit.)

See Section 26.5.1 for details of the operation of the VMX-preemption timer in VMX non-root operation, including

the blocking and priority of the VM exits that it causes.

27.7.5 Interrupt-Window Exiting and Virtual-Interrupt Delivery

If “interrupt-window exiting” VM-execution control is 1, an open interrupt window may cause a VM exit immedi-

ately after VM entry (see Section 26.2 for details). If the “interrupt-window exiting” VM-execution control is 0 but

the “virtual-interrupt delivery” VM-execution control is 1, a virtual interrupt may be delivered immediately after

VM entry (see Section 27.3.2.5 and Section 30.2.1).

The following items detail the treatment of these events:

• These events occur after any event injection specified for VM entry.

• Non-maskable interrupts (NMIs) and higher priority events take priority over these events. These events take

priority over external interrupts and lower priority events.

• These events wake the logical processor if it just entered the HLT state because of a VM entry (see Section

27.7.2). They do not occur if the logical processor just entered the shutdown state or the wait-for-SIPI state.

27.7.6 NMI-Window Exiting

The “NMI-window exiting” VM-execution control may cause a VM exit to occur immediately after VM entry (see

Section 26.2 for details).

The following items detail the treatment of these VM exits:

• These VM exits follow event injection if such injection is specified for VM entry.

• Debug-trap exceptions (see Section 27.7.3) and higher priority events take priority over VM exits caused by

this control. VM exits caused by this control take priority over non-maskable interrupts (NMIs) and lower

priority events.

• VM exits caused by this control wake the logical processor if it just entered either the HLT state or the shutdown

state because of a VM entry (see Section 27.7.2). They do not occur if the logical processor just entered the

wait-for-SIPI state.

27.7.7 VM Exits Induced by the TPR Threshold

If the “use TPR shadow” and “virtualize APIC accesses” VM-execution controls are both 1 and the “virtual-interrupt

delivery” VM-execution control is 0, a VM exit occurs immediately after VM entry if the value of bits 3:0 of the TPR

threshold VM-execution control field is greater than the value of bits 7:4 of VTPR (see Section 30.1.1).¹

The following items detail the treatment of these VM exits:

• The VM exits are not blocked if RFLAGS.IF = 0 or by the setting of bits in the interruptibility-state field in guest-

state area.

• The VM exits follow event injection if such injection is specified for VM entry.

1.

“Virtualize APIC accesses” and “virtual-interrupt delivery” are secondary processor-based VM-execution controls. If bit 31 of the pri-

mary processor-based VM-execution controls is 0, VM entry functions as if these controls were 0. See Section 25.6.2.

Vol. 3C

27-25

VM ENTRIES

— Exit qualification. This field is set based on the exit reason.

• VM-entry failure due to invalid guest state. In most cases, the exit qualification is cleared to 0. The

following non-zero values are used in the cases indicated:

1. Not used.

2. Failure was due to a problem loading the PDPTEs (see Section 27.3.1.6).

3. Failure was due to an attempt to inject a non-maskable interrupt (NMI) into a guest that is blocking

events through the STI blocking bit in the interruptibility-state field.

4. Failure was due to an invalid VMCS link pointer (see Section 27.3.1.5).

VM-entry checks on guest-state fields may be performed in any order. Thus, an indication by exit

qualification of one cause does not imply that there are not also other errors. Different processors

may give different exit qualifications for the same VMCS.

• VM-entry failure due to MSR loading. The exit qualification is loaded to indicate which entry in the

VM-entry MSR-load area caused the problem (1 for the first entry, 2 for the second, etc.).

— All other VM-exit information fields are unmodified.

2. Processor state is loaded as would be done on a VM exit (see Section 28.5). If this results in

[CR4.PAE & CR0.PG & ~IA32_EFER.LMA] = 1, page-directory-pointer-table entries (PDPTEs) may be checked

and loaded (see Section 28.5.4).

3. The state of blocking by NMI is what it was before VM entry.

4. MSRs are loaded as specified in the VM-exit MSR-load area (see Section 28.6).

Although this process resembles that of a VM exit, many steps taken during a VM exit do not occur for these

VM-entry failures:

• Most VM-exit information fields are not updated (see step 1 above).

• The valid bit in the VM-entry interruption-information field is not cleared.

• The guest-state area is not modified.

• No MSRs are saved into the VM-exit MSR-store area.

27.9

MACHINE-CHECK EVENTS DURING VM ENTRY

If a machine-check event occurs during a VM entry, one of the following occurs:

• The machine-check event is handled as if it occurred before the VM entry:

— If CR4.MCE = 0, operation of the logical processor depends on whether the logical processor is in SMX

operation:¹

• 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 delivered through the IDT.

• The machine-check event is handled after VM entry completes:

— If the VM entry ends with CR4.MCE = 0, operation of the logical processor depends on whether the logical

processor is in SMX operation:

• 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.

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 the Intel^® 64 and IA-32 Architectures Soft-

ware Developer’s Manual, Volume 2D.

Vol. 3C

27-27

CHAPTER 28

VM EXITS

VM exits occur in response to certain instructions and events in VMX non-root operation as detailed in Section 26.1

through Section 26.2. VM exits perform the following operations:

1. Information about the cause of the VM exit is recorded in the VM-exit information fields and VM-entry control

fields are modified as described in Section 28.2.

2. Processor state is saved in the guest-state area (Section 28.3).

3. MSRs may be saved in the VM-exit MSR-store area (Section 28.4). This step is not performed for SMM VM exits

that activate the dual-monitor treatment of SMIs and SMM.

4. The following may be performed in parallel and in any order (Section 28.5):

— Processor state is loaded based in part on the host-state area and some VM-exit controls. This step is not

performed for SMM VM exits that activate the dual-monitor treatment of SMIs and SMM. See Section

32.15.6 for information on how processor state is loaded by such VM exits.

— Address-range monitoring is cleared.

5. MSRs may be loaded from the VM-exit MSR-load area (Section 28.6). This step is not performed for SMM

VM exits that activate the dual-monitor treatment of SMIs and SMM.

VM exits are not logged with last-branch records, do not produce branch-trace messages, and do not update the

branch-trace store.

Section 28.1 clarifies the nature of the architectural state before a VM exit begins. The steps described above are

detailed in Section 28.2 through Section 28.6.

Section 32.15 describes the dual-monitor treatment of system-management interrupts (SMIs) and system-

management mode (SMM). Under this treatment, ordinary transitions to SMM are replaced by VM exits to a sepa-

rate SMM monitor. Called SMM VM exits, these are caused by the arrival of an SMI or the execution of VMCALL in

VMX root operation. SMM VM exits differ from other VM exits in ways that are detailed in Section 32.15.2.

28.1

ARCHITECTURAL STATE BEFORE A VM EXIT

This section describes the architectural state that exists before a VM exit, especially for VM exits caused by events

that would normally be delivered through the IDT. Note the following:

• An exception causes a VM exit directly if the bit corresponding to that exception is set in the exception bitmap.

A non-maskable interrupt (NMI) causes a VM exit directly if the “NMI exiting” VM-execution control is 1. An

external interrupt causes a VM exit directly if the “external-interrupt exiting” VM-execution control is 1. A start-

up IPI (SIPI) that arrives while a logical processor is in the wait-for-SIPI activity state causes a VM exit directly.

INIT signals that arrive while the processor is not in the wait-for-SIPI activity state cause VM exits directly.

• An exception, NMI, external interrupt, or software interrupt causes a VM exit indirectly if it does not do so

directly but delivery of the event causes a nested exception, double fault, task switch, APIC access (see Section

30.4), EPT violation, EPT misconfiguration, page-modification log-full event (see Section 29.3.6), or SPP-

related event (see Section 29.3.4) that causes a VM exit.

• An event results in a VM exit if it causes a VM exit (directly or indirectly).

The following bullets detail when architectural state is and is not updated in response to VM exits:

• If an event causes a VM exit directly, it does not update architectural state as it would have if it had it not

caused the VM exit:

— A debug exception does not update DR6, DR7, or IA32_DEBUGCTL. (Information about the nature of the

debug exception is saved in the exit qualification field.)

— A page fault does not update CR2. (The linear address causing the page fault is saved in the exit-qualifi-

cation field.)

Vol. 3C

28-1

VM EXITS

— An NMI causes subsequent NMIs to be blocked, but only after the VM exit completes.

— An external interrupt does not acknowledge the interrupt controller and the interrupt remains pending,

unless the “acknowledge interrupt on exit” VM-exit control is 1. In such a case, the interrupt controller is

acknowledged and the interrupt is no longer pending.

— The flags L0 - L3 in DR7 (bit 0, bit 2, bit 4, and bit 6) are not cleared when a task switch causes a VM exit.

— If a task switch causes a VM exit, none of the following are modified by the task switch: old task-state

segment (TSS); new TSS; old TSS descriptor; new TSS descriptor; RFLAGS.NT¹; or the TR register.

— No last-exception record is made if the event that would do so directly causes a VM exit.

— If a machine-check exception causes a VM exit directly, this does not prevent machine-check MSRs from

being updated. These are updated by the machine-check event itself and not the resulting machine-check

exception.

— If the logical processor is in an inactive state (see Section 25.4.2) and not executing instructions, some

events may be blocked but others may return the logical processor to the active state. Unblocked events

may cause VM exits.² If an unblocked event causes a VM exit directly, a return to the active state occurs

only after the VM exit completes.³ The VM exit generates any special bus cycle that is normally generated

when the active state is entered from that activity state.

MTF VM exits (see Section 26.5.2 and Section 27.7.8) are not blocked in the HLT activity state. If an MTF

VM exit occurs in the HLT activity state, the logical processor returns to the active state only after the

VM exit completes. MTF VM exits are blocked the shutdown state and the wait-for-SIPI state.

•

If an event causes a VM exit indirectly, the event does update architectural state:

— A debug exception updates DR6, DR7, and the IA32_DEBUGCTL MSR. No debug exceptions are considered

pending.

— A page fault updates CR2.

— An NMI causes subsequent NMIs to be blocked before the VM exit commences.

— An external interrupt acknowledges the interrupt controller and the interrupt is no longer pending.

— If the logical processor had been in an inactive state, it enters the active state and, before the VM exit

commences, generates any special bus cycle that is normally generated when the active state is entered

from that activity state.

— There is no blocking by STI or by MOV SS when the VM exit commences.

— Processor state that is normally updated as part of delivery through the IDT (CS, RIP, SS, RSP, RFLAGS) is

not modified. However, the incomplete delivery of the event may write to the stack.

— The treatment of last-exception records is implementation dependent:

• Some processors make a last-exception record when beginning the delivery of an event through the IDT

(before it can encounter a nested exception). Such processors perform this update even if the event

encounters a nested exception that causes a VM exit (including the case where nested exceptions lead

to a triple fault).

• Other processors delay making a last-exception record until event delivery has reached some event

handler successfully (perhaps after one or more nested exceptions). Such processors do not update the

last-exception record if a VM exit or triple fault occurs before an event handler is reached.

1. This chapter uses the notation RAX, RIP, RSP, RFLAGS, etc. for processor registers because most processors that support VMX oper-

ation also support Intel 64 architecture. For processors that do not support Intel 64 architecture, this notation refers to the 32-bit

forms of those registers (EAX, EIP, ESP, EFLAGS, etc.). In a few places, notation such as EAX is used to refer specifically to lower 32

bits of the indicated register.

2. If a VM exit takes the processor from 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.

3. An exception is made if the logical processor had been inactive due to execution of MWAIT; in this case, it is considered to have

become active before the VM exit.

28-2

Vol. 3C

VM EXITS

28.2

RECORDING VM-EXIT INFORMATION AND UPDATING VM-ENTRY CONTROL

FIELDS

VM exits begin by recording information about the nature of and reason for the VM exit in the VM-exit information

fields. Section 28.2.1 to Section 28.2.5 detail the use of these fields.

In addition to updating the VM-exit information fields, the valid bit (bit 31) is cleared in the VM-entry interruption-

information field. If bit 5 of the IA32_VMX_MISC MSR (index 485H) is read as 1 (see Appendix A.6), the value of

IA32_EFER.LMA is stored into the “IA-32e mode guest” VM-entry control.¹

28.2.1 Basic VM-Exit Information

Section 25.9.1 defines the basic VM-exit information fields. The following items detail their use.

•

Exit reason.

— Bits 15:0 of this field contain the basic exit reason. It is loaded with a number indicating the general cause

of the VM exit. Appendix C lists the numbers used and their meaning.

— Bit 25 is set if the “prematurely busy shadow stack” VM-exit control is 1 and the VM exit caused a shadow

stack become prematurely busy (see Section 26.4.3). Otherwise, the bit is cleared.

— Bit 26 of this field is set to 1 if the VM exit occurred after assertion of a bus lock while the “VMM bus-lock

detection” VM-execution control was 1. Such VM exits include those that occur due to the 1-setting of that

control as well as others that might occur during execution of an instruction that asserted a bus lock.

— Bit 27 of this field is set to 1 if the VM exit occurred while the logical processor was in enclave mode.

Such VM exits include 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 also sets this bit if it is incident to delivery of an event injected by VM entry and the guest inter-

ruptibility-state field indicates an enclave interruption (bit 4 of the field is 1).

— The remainder of the field (bits 31:28 and bits 24:16) is cleared to 0 (certain SMM VM exits may set some

of these bits; see Section 32.15.2.3).²

•

Exit qualification. This field is saved for VM exits due to the following causes: debug exceptions; page-fault

exceptions; start-up IPIs (SIPIs); system-management interrupts (SMIs) that arrive immediately after the

execution of I/O instructions; task switches; INVEPT; INVLPG; INVPCID; INVVPID; LGDT; LIDT; LLDT; LTR;

SGDT; SIDT; SLDT; STR; VMCLEAR; VMPTRLD; VMPTRST; VMREAD; VMWRITE; VMXON; WBINVD;

WBNOINVD; XRSTORS; XSAVES; control-register accesses; MOV DR; I/O instructions; MWAIT; accesses to the

APIC-access page (see Section 30.4); EPT violations (see Section 29.3.3.2); EOI virtualization (see Section

30.1.4); APIC-write emulation (see Section 30.4.3.3); page-modification log full (see Section 29.3.6); SPP-

related events (see Section 29.3.4); and instruction timeout (see Section 26.2). For all other VM exits, this field

is cleared. The following items provide details:

— For a debug exception, the exit qualification contains information about the debug exception. The

information has the format given in Table 28-1.

Table 28-1. Exit Qualification for Debug Exceptions

Bit Position(s)

Contents

3:0

B3 - B0. When set, each of these bits indicates that the corresponding breakpoint condition was met. Any of

these bits may be set even if its corresponding enabling bit in DR7 is not set.

10:4

Not currently defined.

1. Bit 5 of the IA32_VMX_MISC MSR is read as 1 on any logical processor that supports the 1-setting of the “unrestricted guest” VM-

execution control.

2. Bit 31 of this field is set on certain VM-entry failures; see Section 27.8.

28-4

Vol. 3C

VM EXITS

Table 28-1. Exit Qualification for Debug Exceptions (Contd.)

Bit Position(s)

Contents

11

BLD. When set, this bit indicates that a bus lock was asserted while OS bus-lock detection was enabled and

CPL > 0 (see Section 18.3.1.6 (‘‘OS Bus-Lock Detection”)).¹

12

Not currently defined.

13

BD. When set, this bit indicates that the cause of the debug exception is “debug register access detected.”

14

BS. When set, this bit indicates that the cause of the debug exception is either the execution of a single

instruction (if RFLAGS.TF = 1 and IA32_DEBUGCTL.BTF = 0) or a taken branch (if

RFLAGS.TF = DEBUGCTL.BTF = 1).

15

Not currently defined.

16

RTM. When set, this bit indicates that a debug exception (#DB) or a breakpoint exception (#BP) occurred

inside an RTM region while advanced debugging of RTM transactional regions was enabled (see Section

16.3.7, “RTM-Enabled Debugger Support,” of the Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 1).²

63:17

Not currently defined. Bits 63:32 exist only on processors that support Intel 64 architecture.

NOTES:

1. In general, the format of this field matches that of DR6. However, DR6 clears bit 11 to indicate detection of a bus lock, while this field

sets the bit to indicate that condition.

2. In general, the format of this field matches that of DR6. However, DR6 clears bit 16 to indicate an RTM-related exception, while this

field sets the bit to indicate that condition.

— For a page-fault exception, the exit qualification contains the linear address that caused the page fault. On

processors that support Intel 64 architecture, bits 63:32 are cleared if the logical processor was not in 64-

bit mode before the VM exit.

If the page-fault exception occurred during execution of an instruction in enclave mode (and not during

delivery of an event incident to enclave mode), bits 11:0 of the exit qualification are cleared.

— For a start-up IPI (SIPI), the exit qualification contains the SIPI vector information in bits 7:0. Bits 63:8 of

the exit qualification are cleared to 0.

— For a task switch, the exit qualification contains details about the task switch, encoded as shown in

Table 28-2.

— For INVLPG, the exit qualification contains the linear-address operand of the instruction.

• On processors that support Intel 64 architecture, bits 63:32 are cleared if the logical processor was not

in 64-bit mode before the VM exit.

• If the INVLPG source operand specifies an unusable segment, the linear address specified in the exit

qualification will match the linear address that the INVLPG would have used if no VM exit occurred. This

address is not architecturally defined and may be implementation-specific.

Table 28-2. Exit Qualification for Task Switches

Bit Position(s)

Contents

15:0

Selector of task-state segment (TSS) to which the guest attempted to switch

29:16

Not currently defined

Vol. 3C

28-5

VM EXITS

Table 28-2. Exit Qualification for Task Switches (Contd.)

Bit Position(s)

Contents

31:30

Source of task switch initiation:

0: CALL instruction

1: IRET instruction

2: JMP instruction

3: Task gate in IDT

63:32

Not currently defined. These bits exist only on processors that support Intel 64 architecture.

— For INVEPT, INVPCID, INVVPID, LGDT, LIDT, LLDT, LTR, SGDT, SIDT, SLDT, STR, VMCLEAR, VMPTRLD,

VMPTRST, VMREAD, VMWRITE, VMXON, XRSTORS, and XSAVES, the exit qualification receives the value of

the instruction’s displacement field, which is sign-extended to 64 bits if necessary (32 bits on processors

that do not support Intel 64 architecture). If the instruction has no displacement (for example, has a

register operand), zero is stored into the exit qualification.

On processors that support Intel 64 architecture, an exception is made for RIP-relative addressing (used

only in 64-bit mode). Such addressing causes an instruction to use an address that is the sum of the

displacement field and the value of RIP that references the following instruction. In this case, the exit

qualification is loaded with the sum of the displacement field and the appropriate RIP value.

In all cases, bits of this field beyond the instruction’s address size are undefined. For example, suppose

that the address-size field in the VM-exit instruction-information field (see Section 25.9.4 and Section

28.2.5) reports an n-bit address size. Then bits 63:n (bits 31:n on processors that do not support Intel 64

architecture) of the instruction displacement are undefined.

— For a control-register access, the exit qualification contains information about the access and has the

format given in Table 28-3.

— For MOV DR, the exit qualification contains information about the instruction and has the format given in

Table 28-4.

— For an I/O instruction, the exit qualification contains information about the instruction and has the format

given in Table 28-5.

— For MWAIT, the exit qualification contains a value that indicates whether address-range monitoring

hardware was armed. The exit qualification is set either to 0 (if address-range monitoring hardware is not

armed) or to 1 (if address-range monitoring hardware is armed).

— WBINVD and WBNOINVD use the same basic exit reason (see Appendix C). For WBINVD, the exit qualifi-

cation is 0, while for WBNOINVD it is 1.

— For an APIC-access VM exit resulting from a linear access or a guest-physical access to the APIC-access

page (see Section 30.4), the exit qualification contains information about the access and has the format

given in Table 28-6.¹

If the access to the APIC-access page occurred during execution of an instruction in enclave mode (and not

during delivery of an event incident to enclave mode), bits 11:0 of the exit qualification are cleared.

Such a VM exit that set bits 15:12 of the exit qualification to 0000b (data read during instruction execution)

or 0001b (data write during instruction execution) set bit 12—which distinguishes data read from data

write—to that which would have been stored in bit 1—W/R—of the page-fault error code had the access

caused a page fault instead of an APIC-access VM exit. This implies the following:

• For an APIC-access VM exit caused by the CLFLUSH and CLFLUSHOPT instructions, the access type is

“data read during instruction execution.”

• For an APIC-access VM exit caused by the ENTER instruction, the access type is “data write during

instruction execution.”

1.

The exit qualification is undefined if the access was part of the logging of a branch record or a processor-event-based-sampling

(PEBS) record to the DS save area. It is recommended that software configure the paging structures so that no address in the DS

save area translates to an address on the APIC-access page.

28-6

Vol. 3C

VM EXITS

Table 28-3. Exit Qualification for Control-Register Accesses

Bit Positions

Contents

3:0

Number of control register (0 for CLTS and LMSW). Bit 3 is always 0 on processors that do not support Intel 64

architecture as they do not support CR8.

5:4

Access type:

0 = MOV to CR

1 = MOV from CR

2 = CLTS

3 = LMSW

6

LMSW operand type:

0 = register

1 = memory

For CLTS and MOV CR, cleared to 0

7

Not currently defined

11:8

For MOV CR, the general-purpose 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)

For CLTS and LMSW, cleared to 0

15:12

Not currently defined

31:16

For LMSW, the LMSW source data

For CLTS and MOV CR, cleared to 0

63:32

Not currently defined. These bits exist only on processors that support Intel 64 architecture.

•

For an APIC-access VM exit caused by the MASKMOVQ instruction or the MASKMOVDQU instruction, the

access type is “data write during instruction execution.”

•

For an APIC-access VM exit caused by the MONITOR instruction, the access type is “data read during

instruction execution.”

•

For an APIC-access VM exit caused directly by an access to a linear address in the DS save area (BTS or

PEBS), the access type is “linear access for monitoring.”

•

For an APIC-access VM exit caused by a guest-physical access performed for an access to the DS save

area (e.g., to access a paging structure to translate a linear address), the access type is “guest-physical

access for monitoring or trace.”

•

For an APIC-access VM exit caused by trace-address pre-translation (TAPT) when the “Intel PT uses

guest physical addresses” VM-execution control is 1, the access type is “guest-physical access for

monitoring or trace.”

Such a VM exit stores 1 for bit 31 for IDT-vectoring information field (see Section 28.2.4) if and only if it

sets bits 15:12 of the exit qualification to 0011b (linear access during event delivery) or 1010b (guest-

physical access during event delivery).

Vol. 3C

28-7

VM EXITS

See Section 30.4.4 for further discussion of these instructions and APIC-access VM exits.

For APIC-access VM exits resulting from physical accesses to the APIC-access page (see Section 30.4.6),

the exit qualification is undefined.

— For an EPT violation, the exit qualification contains information about the access causing the EPT violation

and has the format given in Table 28-7.

As noted in that table, the format and meaning of the exit qualification depends on the setting of the

“mode-based execute control for EPT” VM-execution control and whether the processor supports advanced

VM-exit information for EPT violations.¹

An EPT violation that occurs during as a result of execution of a read-modify-write operation sets bit 1 (data

write). Whether it also sets bit 0 (data read) is implementation-specific and, for a given implementation,

may differ for different kinds of read-modify-write operations.

Table 28-4. Exit Qualification for MOV DR

Bit Position(s)

Contents

2:0

Number of debug register

3

Not currently defined

4

Direction of access (0 = MOV to DR; 1 = MOV from DR)

7:5

Not currently defined

11:8

General-purpose register:

0 = RAX

1 = RCX

2 = RDX

3 = RBX

4 = RSP

5 = RBP

6 = RSI

7 = RDI

8 -15 = R8 - R15, respectively

63:12

Not currently defined. Bits 63:32 exist only on processors that support Intel 64 architecture.

Table 28-5. Exit Qualification for I/O Instructions

Bit Position(s)

Contents

2:0

Size of access:

0 = 1-byte

1 = 2-byte

3 = 4-byte

Other values not used

3

Direction of the attempted access (0 = OUT, 1 = IN)

4

String instruction (0 = not string; 1 = string)

1. 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).

28-8

Vol. 3C

Content      ..     112      113      114      115     ..