background image

Vol. 3C 24-27

VIRTUAL MACHINE CONTROL STRUCTURES

24.11.3  Initializing a VMCS

Software should initialize fields in a VMCS (using VMWRITE) before using the VMCS for VM entry. Failure to do so 
may result in unpredictable behavior; for example, a VM entry may fail for unexplained reasons, or a successful 
transition (VM entry or VM exit) may load processor state with unexpected values.
It is not necessary to initialize fields that the logical processor will not use. (For example, it is not necessary to 
unitize the MSR-bitmap address if the “use MSR bitmaps” VM-execution control is 0.)
A processor maintains some VMCS information that cannot be modified with the VMWRITE instruction; this 
includes a VMCS’s launch state (see Section 24.1). Such information may be stored in the VMCS data portion of a 
VMCS region. Because the format of this information is implementation-specific, there is no way for software to 
know, when it first allocates a region of memory for use as a VMCS region, how the processor will determine this 
information from the contents of the memory region.
In addition to its other functions, the VMCLEAR instruction initializes any implementation-specific information in 
the VMCS region referenced by its operand. To avoid the uncertainties of implementation-specific behavior, soft-
ware should execute VMCLEAR on a VMCS region before making the corresponding VMCS active with VMPTRLD for 
the first time. (Figure 24-1 illustrates how execution of VMCLEAR puts a VMCS into a well-defined state.)
The following software usage is consistent with these limitations:

VMCLEAR should be executed for a VMCS before it is used for VM entry for the first time.

VMLAUNCH should be used for the first VM entry using a VMCS after VMCLEAR has been executed for that 
VMCS.

VMRESUME should be used for any subsequent VM entry using a VMCS (until the next execution of VMCLEAR 
for the VMCS).

It is expected that, in general, VMRESUME will have lower latency than VMLAUNCH. Since “migrating” a VMCS from 
one logical processor to another requires use of VMCLEAR (see Section 24.11.1), which sets the launch state of the 
VMCS to “clear”, such migration requires the next VM entry to be performed using VMLAUNCH. Software devel-
opers can avoid the performance cost of increased VM-entry latency by avoiding unnecessary migration of a VMCS 
from one logical processor to another.

24.11.4  Software Access to Related Structures

In addition to data in the VMCS region itself, VMX non-root operation can be controlled by data structures that are 
referenced by pointers in a VMCS (for example, the I/O bitmaps). While the pointers to these data structures are 
parts of the VMCS, the data structures themselves are not. They are not accessible using VMREAD and VMWRITE 
but by ordinary memory writes.
Software should ensure that each such data structure is modified only when no logical processor with a current 
VMCS that references it is in VMX non-root operation. Doing otherwise may lead to unpredictable behavior 
(including behaviors identified in Section 24.11.1).

24.11.5 VMXON 

Region

Before executing VMXON, software allocates a region of memory (called the VMXON region)

1

 that the logical 

processor uses to support VMX operation. The physical address of this region (the VMXON pointer) is provided in 
an operand to VMXON. The VMXON pointer is subject to the limitations that apply to VMCS pointers:

The VMXON pointer must be 4-KByte aligned (bits 11:0 must be zero).

The VMXON pointer must not set any bits beyond the processor’s physical-address width.

2,3

1. The amount of memory required for the VMXON region is the same as that required for a VMCS region. This size is implementation 

specific and can be determined by consulting the VMX capability MSR IA32_VMX_BASIC (see Appendix A.1).

2. Software can determine a processor’s physical-address width by executing CPUID with 80000008H in EAX. The physical-address 

width is returned in bits 7:0 of EAX.

3. If IA32_VMX_BASIC[48] is read as 1, the VMXON pointer must not set any bits in the range 63:32; see Appendix A.1.