Intel 64 and IA-32 Architectures Software Developers Manual Volume 3B, System Programming Guide Part 2

Vol. 3 23-3
VM EXITS
— If the logical processor is in an inactive state (see Section 20.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.
1
If an unblocked event causes a VM exit directly, a return to the
active state occurs only after the VM exit completes.
2
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 21.7.2 and Section 22.6.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-
1. 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.
2. 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.