Specifications

Intel
®
64 and IA-32 Architectures Software Developer’s Manual Documentation Changes 265
Documentation Changes
data of an active VMCS on the processor and not in the VMCS region. The following items
detail some of the hazards of accessing VMCS data using ordinary memory operations:
• Any data read from a VMCS with an ordinary memory read does not reliably reflect
the state of the VMCS. Results may vary from time to time or from logical processor
to logical processor.
• Writing to a VMCS with an ordinary memory write is not guaranteed to have a deter-
ministic effect on the VMCS. Doing so may cause the VMCS to become corrupted (see
below).
(Software can avoid these hazards by removing any linear-address mappings to a VMCS
region before executing a VMPTRLD for that region and by not remapping it until after
executing VMCLEAR for that region.)
If a logical processor leaves VMX operation, any VMCSs active on that logical processor
may be corrupted (see below). To prevent such corruption of a VMCS that may be used
either after a return to VMX operation or on another logical processor, software should
VMCLEAR that VMCS before executing the VMXOFF instruction or removing power from
the processor (e.g., as part of a transition to the S3 and S4 power states).
This section has identified operations that may cause a VMCS to become corrupted.
These operations may cause the VMCS’s data to become undefined. Behavior may be
unpredictable if that VMCS used subsequently on any logical processor. The following
items detail some hazards of VMCS corruption:
• VM entries may fail for unexplained reasons or may load undesired processor state.
• The processor may not correctly support VMX non-root operation as documented in
Chapter 21 and may generate unexpected VM exits.
• VM exits may load undesired processor state, save incorrect state into the VMCS, or
cause the logical processor to transition to a shutdown state.
...
21.10.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 initialize 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 21.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 implementa-
tion-specific information in the VMCS region referenced by its operand. To avoid the
uncertainties of implementation-specific behavior, software should execute VMCLEAR on
a VMCS region before making the corresponding VMCS active with VMPTRLD for the first
time. (Figure 21-1 illustrates how execution of VMCLEAR puts a VMCS into a well-defined
state.)