Vol. 3C 26-1
CHAPTER 26
VM ENTRIES
Software can enter VMX non-root operation using either of the VM-entry instructions VMLAUNCH and VMRESUME.
VMLAUNCH can be used only with a VMCS whose launch state is clear and VMRESUME can be used only with a
VMCS whose the launch state is launched. VMLAUNCH should be used for the first VM entry after VMCLEAR; VMRE-
SUME should be used for subsequent VM entries with the same VMCS.
Each VM entry performs the following steps in the order indicated:
1. Basic checks are performed to ensure that VM entry can commence
2. The control and host-state areas of the VMCS are checked to ensure that they are proper for supporting VMX
non-root operation and that the VMCS is correctly configured to support the next VM exit (Section 26.2).
3. The following may be performed in parallel or in any order (Section 26.3):
•
The guest-state area of the VMCS is checked to ensure that, after the VM entry completes, the state of the
logical processor is consistent with IA-32 and Intel 64 architectures.
•
Processor state is loaded from the guest-state area and based on controls in the VMCS.
•
Address-range monitoring is cleared.
4. MSRs are loaded from the VM-entry MSR-load area (Section 26.4).
5. If VMLAUNCH is being executed, the launch state of the VMCS is set to “launched.”
6. An event may be injected in the guest context (Section 26.5).
Steps 1–4 above perform checks that may cause VM entry to fail. Such failures occur in one of the following three
ways:
•
Some of the checks in Section 26.1 may generate ordinary faults (for example, an invalid-opcode exception).
Such faults are delivered normally.
•
Some of the checks in Section 26.1 and all the checks in Section 26.2 cause control to pass to the instruction
following the VM-entry instruction. The failure is indicated by setting RFLAGS.ZF
1
(if there is a current VMCS)
or RFLAGS.CF (if there is no current VMCS). If there is a current VMCS, an error number indicating the cause of
the failure is stored in the VM-instruction error field. See Chapter 30 for the error numbers.
•
The checks in Section 26.3 and Section 26.4 cause processor state to be loaded from the host-state area of the
VMCS (as would be done on a VM exit). Information about the failure is stored in the VM-exit information fields.
See Section 26.7 for details.
EFLAGS.TF = 1 causes a VM-entry instruction to generate a single-step debug exception only if failure of one of the
checks in Section 26.1 and Section 26.2 causes control to pass to the following instruction. A VM-entry does not
generate a single-step debug exception in any of the following cases: (1) the instruction generates a fault; (2)
failure of one of the checks in Section 26.3 or in loading MSRs causes processor state to be loaded from the host-
state area of the VMCS; or (3) the instruction passes all checks in Section 26.1, Section 26.2, and Section 26.3 and
there is no failure in loading MSRs.
Section 34.15 describes the dual-monitor treatment of system-management interrupts (SMIs) and system-
management mode (SMM). Under this treatment, code running in SMM returns using VM entries instead of the
RSM instruction. A VM entry returns from SMM if it is executed in SMM and the “entry to SMM” VM-entry control
is 0. VM entries that return from SMM differ from ordinary VM entries in ways that are detailed in Section 34.15.4.
1. This chapter uses the notation RAX, RIP, RSP, RFLAGS, etc. for processor registers because most processors that support VMX oper-
ation also support Intel 64 architecture. For IA-32 processors, this notation refers to the 32-bit forms of those registers (EAX, EIP,
ESP, EFLAGS, etc.). In a few places, notation such as EAX is used to refer specifically to lower 32 bits of the indicated register.