Vol. 3C 27-1

CHAPTER 27

VM EXITS

VM exits occur in response to certain instructions and events in VMX non-root operation as detailed in Section 25.1 
through Section 25.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 27.2.

2. Processor state is saved in the guest-state area (Section 27.3).
3. MSRs may be saved in the VM-exit MSR-store area (Section 27.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 27.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 
34.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 27.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 27.1 clarifies the nature of the architectural state before a VM exit begins. The steps described above are 
detailed in Section 27.2 through Section 27.6. 
Section 34.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 34.15.2.

27.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 
27.4), EPT violation, EPT misconfiguration, or page-modification log-full event 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.GD, or IA32_DEBUGCTL.LBR. (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.)

— An NMI causes subsequent NMIs to be blocked, but only after the VM exit completes.