background image

Vol. 3C 27-3

VM EXITS

If a VM exit results from a fault, EPT violation, EPT misconfiguration, or page-modification log-full event is 
encountered during execution of IRET and the “NMI exiting” VM-execution control is 0, any blocking by NMI is 
cleared before the VM exit commences. However, the previous state of blocking by NMI may be recorded in the 
VM-exit interruption-information field; see Section 27.2.2.

If a VM exit results from a fault, EPT violation, EPT misconfiguration, or page-modification log-full event is 
encountered during execution of IRET and the “virtual NMIs” VM-execution control is 1, virtual-NMI blocking is 
cleared before the VM exit commences. However, the previous state of virtual-NMI blocking may be recorded 
in the VM-exit interruption-information field; see Section 27.2.2.

Suppose that a VM exit is caused directly by an x87 FPU Floating-Point Error (#MF) or by any of the following 
events if the event was unblocked due to (and given priority over) an x87 FPU Floating-Point Error: an INIT 
signal, an external interrupt, an NMI, an SMI; or a machine-check exception. In these cases, there is no 
blocking by STI or by MOV SS when the VM exit commences.

Normally, a last-branch record may be made when an event is delivered through the IDT. However, if such an 
event results in a VM exit before delivery is complete, no last-branch record is made.

If machine-check exception results in a VM exit, processor state is suspect and may result in suspect state 
being saved to the guest-state area. A VM monitor should consult the RIPV and EIPV bits in the 
IA32_MCG_STATUS MSR before resuming a guest that caused a VM exit resulting from a machine-check 
exception.

If a VM exit results from a fault, APIC access (see Section 29.4), EPT violation, EPT misconfiguration, or page-
modification log-full event is encountered while executing an instruction, data breakpoints due to that 
instruction may have been recognized and information about them may be saved in the pending debug 
exceptions field (see Section 27.3.4).

The following VM exits are considered to happen after an instruction is executed:
— VM exits resulting from debug traps (single-step, I/O breakpoints, and data breakpoints).
— VM exits resulting from debug exceptions whose recognition was delayed by blocking by MOV SS.
— VM exits resulting from some machine-check exceptions.
— Trap-like VM exits due to execution of MOV to CR8 when the “CR8-load exiting” VM-execution control is 0 

and the “use TPR shadow” VM-execution control is 1 (see Section 29.3). (Such VM exits can occur only from 
64-bit mode and thus only on processors that support Intel 64 architecture.)

— Trap-like VM exits due to execution of WRMSR when the “use MSR bitmaps” VM-execution control is 1; the 

value of ECX is in the range 800H–8FFH; and the bit corresponding to the ECX value in write bitmap for low 
MSRs is 0; and the “virtualize x2APIC mode” VM-execution control is 1. See Section 29.5.

— VM exits caused by APIC-write emulation (see Section 29.4.3.2) that result from APIC accesses as part of 

instruction execution.

For these VM exits, the instruction’s modifications to architectural state complete before the VM exit occurs. 
Such modifications include those to the logical processor’s interruptibility state (see Table 24-3). If there had 
been blocking by MOV SS, POP SS, or STI before the instruction executed, such blocking is no longer in effect.

A VM exit that occurs in enclave mode sets bit 27 of the exit-reason field and bit 4 of the guest interruptibility-state 
field. Before such a VM exit is delivered, an Asynchronous Enclave Exit (AEX) occurs (see Chapter 40, “Enclave 
Exiting Events”). 
An AEX modifies architectural state (Section 40.3). In particular, the processor establishes the 
following architectural state as indicated:

The following bits in RFLAGS are cleared: CF, PF, AF, ZF, SF, OF, and RF.

FS and GS are restored to the values they had prior to the most recent enclave entry.

RIP is loaded with the AEP of interrupted enclave thread.

RSP is loaded from the URSP field in the enclave’s state-save area (SSA).