Vol. 3C 26-23

VM ENTRIES

— If the logical processor is blocking such exceptions (due to blocking by MOV SS), the pending debug 

exceptions are held pending or lost as would normally be the case.

•

If the VM entry is vectoring (with interruption type software interrupt or software exception and with blocking 
by MOV SS), the following items apply:
— For injection of a software interrupt or of a software exception with vector 3 (#BP) or vector 4 (#OF), the 

pending debug exceptions are treated as they would had they been encountered normally in guest 
execution if the corresponding instruction (INT3 or INTO) were executed after a MOV SS that encountered 
a debug trap.

— For injection of a software exception with a vector other than 3 and 4, the pending debug exceptions may 

be lost or they may be delivered after injection (see below).

If there are no valid pending debug exceptions (as defined above), no pending debug exceptions are delivered after 
VM entry.
If a pending debug exception is delivered after VM entry, it has the priority of “traps on the previous instruction” 
(see Section 6.9 in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A). Thus, INIT 
signals and system-management interrupts (SMIs) take priority of such an exception, as do VM exits induced by 
the TPR threshold (see Section 26.6.7) and pending MTF VM exits (see Section 26.6.8. The exception takes priority 
over any pending non-maskable interrupt (NMI) or external interrupt and also over VM exits due to the 1-settings 
of the “interrupt-window exiting” and “NMI-window exiting” VM-execution controls.
A pending debug exception delivered after VM entry causes a VM exit if the bit 1 (#DB) is 1 in the exception 
bitmap. If it does not cause a VM exit, it updates DR6 normally.

26.6.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 26.6.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 25.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.

26.6.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 25.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 26.3.2.5 and Section 29.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 
26.6.2). They do not occur if the logical processor just entered the shutdown state or the wait-for-SIPI state.

26.6.6 NMI-Window 

Exiting

The “NMI-window exiting” VM-execution control may cause a VM exit to occur immediately after VM entry (see 
Section 25.2 for details).