26-20 Vol. 3C

VM ENTRIES

•

The last-exception record MSRs (LERs) may be updated based on the setting of the LBR bit in the 
IA32_DEBUGCTL MSR. Events such as debug exceptions, which normally clear the LBR bit before they are 
delivered, and therefore do not normally update the LERs, may do so as part of VM-entry event injection.

•

If injection of an event encounters a nested exception that does not itself cause a VM exit, the value of the EXT 
bit (bit 0) in any error code pushed on the stack is determined as follows:
— If event being injected has interruption type external interrupt, NMI, hardware exception, or privileged 

software exception and encounters a nested exception (but does not produce a double fault), the error code 
for the first such exception encountered sets the EXT bit.

— If event being injected is a software interrupt or an software exception and encounters a nested exception 

(but does not produce a double fault), the error code for the first such exception encountered clears the EXT 
bit.

— If event delivery encounters a nested exception and delivery of that exception encounters another 

exception (but does not produce a double fault), the error code for that exception sets the EXT bit. If a 
double fault is produced, the error code for the double fault is 0000H (the EXT bit is clear).

26.5.1.2   VM Exits During Event Injection

An event being injected never causes a VM exit directly regardless of the settings of the VM-execution controls. For 
example, setting the “NMI exiting” VM-execution control to 1 does not cause a VM exit due to injection of an NMI.
However, the event-delivery process may lead to a VM exit:

•

If the vector in the VM-entry interruption-information field identifies a task gate in the IDT, the attempted task 
switch may cause a VM exit just as it would had the injected event occurred during normal execution in VMX 
non-root operation (see Section 25.4.2).

•

If event delivery encounters a nested exception, a VM exit may occur depending on the contents of the 
exception bitmap (see Section 25.2).

•

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 25.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 25.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 29.4 and may cause a VM exit.

1

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

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

2

 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 Volume 3A of the IA-32 Intel

®

 Architecture Software Developer’s Manual.

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

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