31-2 Vol. 3C

VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONS

processors supporting the 1-setting of the "unrestricted guest" VM-execution control save the (guest) value of 
IA32_EFER.LMA into the "IA-32e mode guest" VM entry control.

31.3 

MANAGING VMCS REGIONS AND POINTERS

A VMM must observe necessary procedures when working with a VMCS, the associated VMCS pointer, and the 
VMCS region. It must also not assume the state of persistency for VMCS regions in memory or cache. 
Before entering VMX operation, the host VMM allocates a VMXON region. A VMM can host several virtual machines 
and have many VMCSs active under its management. A unique VMCS region is required for each virtual machine; 
a VMXON region is required for the VMM itself. 
A VMM determines the VMCS region size by reading IA32_VMX_BASIC MSR; it creates VMCS regions of this size 
using a 4-KByte-aligned area of physical memory. Each VMCS region needs to be initialized with a VMCS revision 
identifier (at byte offset 0) identical to the revision reported by the processor in the VMX capability MSR.

NOTE

Software must not read or write directly to the VMCS data region as the format is not architecturally 
defined. Consequently, Intel recommends that the VMM remove any linear-address mappings to 
VMCS regions before loading. 

System software does not need to do special preparation to the VMXON region before entering into VMX operation. 
The address of the VMXON region for the VMM is provided as an operand to VMXON instruction. Once in VMX root 
operation, the VMM needs to prepare data fields in the VMCS that control the execution of a VM upon a VM entry. 
The VMM can make a VMCS the current VMCS by using the VMPTRLD instruction. VMCS data fields must be read or 
written only through VMREAD and VMWRITE commands respectively. 
Every component of the VMCS is identified by a 32-bit encoding that is provided as an operand to VMREAD and 
VMWRITE. Appendix B provides the encodings. A VMM must properly initialize all fields in a VMCS before using the 
current VMCS for VM entry. 
A VMCS is referred to as a controlling VMCS if it is the current VMCS on a logical processor in VMX non-root opera-
tion. A current VMCS for controlling a logical processor in VMX non-root operation may be referred to as a working 
VMCS if the logical processor is not in VMX non-root operation. The relationship of active, current (i.e. working) and 
controlling VMCS during VMX operation is shown in Figure 31-1.

NOTE

As noted in Section 24.1, the processor may optimize VMX operation by maintaining the state of an 
active VMCS (one for which VMPTRLD has been executed) on the processor. Before relinquishing 
control to other system software that may, without informing the VMM, remove power from the 
processor (e.g., for transitions to S3 or S4) or leave VMX operation, a VMM must VMCLEAR all active 
VMCSs. This ensures that all VMCS data cached by the processor are flushed to memory and that 
no other software can corrupt the current VMM’s VMCS data. It is also recommended that the VMM 
execute VMXOFF after such executions of VMCLEAR.

The VMX capability MSR IA32_VMX_BASIC reports the memory type used by the processor for accessing a VMCS 
or any data structures referenced through pointers in the VMCS. Software must maintain the VMCS structures in 
cache-coherent memory. Software must always map the regions hosting the I/O bitmaps, MSR bitmaps, VM-exit 
MSR-store area, VM-exit MSR-load area, and VM-entry MSR-load area to the write-back (WB) memory type. 
Mapping these regions to uncacheable (UC) memory type is supported, but strongly discouraged due to negative 
impact on performance.

31.4 

USING VMX INSTRUCTIONS

VMX instructions are allowed only in VMX root operation. An attempt to execute a VMX instruction in VMX non-root 
operation causes a VM exit.