Vol. 3C 31-11

VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONS

31.8.1 Initialization

Before enabling VMX, an MP-aware VMM must check to make sure that all processors in the system are compatible 
and support features required. This can be done by:

•

Checking the CPUID on each logical processor to ensure VMX is supported and that the overall feature set of 
each logical processor is compatible.

•

Checking VMCS revision identifiers on each logical processor.

•

Checking each of the “allowed-1” or “allowed-0” fields of the VMX capability MSR’s on each processor.

31.8.2 

Moving a VMCS Between Processors

An MP-aware VMM is free to assign any logical processor to a VM. But for performance considerations, moving a 
guest VMCS to another logical processor is slower than resuming that guest VMCS on the same logical processor. 
Certain VMX performance features (such as caching of portions of the VMCS in the processor) are optimized for a 
guest VMCS that runs on the same logical processor. 
The reasons are:

•

To restart a guest on the same logical processor, a VMM can use VMRESUME. VMRESUME is expected to be 
faster than VMLAUNCH in general.

•

To migrate a VMCS to another logical processor, a VMM must use the sequence of VMCLEAR, VMPTRLD and 
VMLAUNCH.

•

Operations involving VMCLEAR can impact performance negatively. See
Section 24.11.3.

A VMM scheduler should make an effort to schedule a guest VMCS to run on the logical processor where it last ran. 
Such a scheduler might also benefit from doing lazy VMCLEARs (that is: performing a VMCLEAR on a VMCS only 
when the scheduler knows the VMCS is being moved to a new logical processor). The remainder of this section 
describes the steps a VMM must take to move a VMCS from one processor to another.
A VMM must check the VMCS revision identifier in the VMX capability MSR IA32_VMX_BASIC to determine if the 
VMCS regions are identical between all logical processors. If the VMCS regions are identical (same revision ID) the 
following sequence can be used to move or copy the VMCS from one logical processor to another:

•

Perform a VMCLEAR operation on the source logical processor. This ensures that all VMCS data that may be 
cached by the processor are flushed to memory.

•

Copy the VMCS region from one memory location to another location. This is an optional step assuming the 
VMM wishes to relocate the VMCS or move the VMCS to another system.

•

Perform a VMPTRLD of the physical address of VMCS region on the destination processor to establish its current 
VMCS pointer.

If the revision identifiers are different, each field must be copied to an intermediate structure using individual reads 
(VMREAD) from the source fields and writes (VMWRITE) to destination fields. Care must be taken on fields that are 
hard-wired to certain values on some processor implementations.

31.8.3 

Paired Index-Data Registers

A VMM may need to virtualize hardware that is visible to software using paired index-data registers. Paired index-
data register interfaces, such as those used in PCI (CF8, CFC), require special treatment in cases where a VM 
performing writes to these pairs can be moved during execution. In this case, the index (e.g. CF8) should be part 
of the virtualized state. If the VM is moved during execution, writes to the index should be redone so subsequent 
data reads/writes go to the right location.

31.8.4 

External Data Structures

Certain fields in the VMCS point to external data structures (for example: the MSR bitmap, the I/O bitmaps). If a 
logical processor is in VMX non-root operation, none of the external structures referenced by that logical