Vol. 3C 26-21

VM ENTRIES

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

26.5.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 25.5.2 for the treatment of pending MTF 
VM exits.

26.6 

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

26.6.1 Interruptibility 

State

The interruptibility-state field in the guest-state area (see Table 24-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:

•

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 26.6.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 26.6.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 26.5.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 26.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.