Vol. 3C 24-3
VIRTUAL MACHINE CONTROL STRUCTURES
ware to avoid using a VMCS region formatted for one processor on a processor that uses a different format.
1
Bit 31
of this 4-byte region indicates whether the VMCS is a shadow VMCS (see Section 24.10).
Software should write the VMCS revision identifier to the VMCS region before using that region for a VMCS. The
VMCS revision identifier is never written by the processor; VMPTRLD fails if its operand references a VMCS region
whose VMCS revision identifier differs from that used by the processor. (VMPTRLD also fails if the shadow-VMCS
indicator is 1 and the processor does not support the 1-setting of the “VMCS shadowing” VM-execution control; see
Section 24.6.2) Software can discover the VMCS revision identifier that a processor uses by reading the VMX capa-
bility MSR IA32_VMX_BASIC
(see Appendix A.1).
Software should clear or set the shadow-VMCS indicator depending on whether the VMCS is to be an ordinary
VMCS or a shadow VMCS (see Section 24.10). VMPTRLD fails if the shadow-VMCS indicator is set and the processor
does not support the 1-setting of the “VMCS shadowing” VM-execution control. Software can discover support for
this setting by reading the VMX capability MSR IA32_VMX_PROCBASED_CTLS2 (see Appendix A.3.3).
The next 4 bytes of the VMCS region are used for the VMX-abort indicator. The contents of these bits do not
control processor operation in any way. A logical processor writes a non-zero value into these bits if a VMX abort
occurs (see Section 27.7). Software may also write into this field.
The remainder of the VMCS region is used for VMCS data (those parts of the VMCS that control VMX non-root
operation and the VMX transitions). The format of these data is implementation-specific. VMCS data are discussed
in Section 24.3 through Section 24.9. To ensure proper behavior in VMX operation, software should maintain the
VMCS region and related structures (enumerated in Section 24.11.4) in writeback cacheable memory. Future
implementations may allow or require a different memory type
2
. Software should consult the VMX capability MSR
IA32_VMX_BASIC (see Appendix A.1).
24.3
ORGANIZATION OF VMCS DATA
The VMCS data are organized into six logical groups:
•
Guest-state area. Processor state is saved into the guest-state area on VM exits and loaded from there on
VM entries.
•
Host-state area. Processor state is loaded from the host-state area on VM exits.
•
VM-execution control fields. These fields control processor behavior in VMX non-root operation. They
determine in part the causes of VM exits.
•
VM-exit control fields. These fields control VM exits.
•
VM-entry control fields. These fields control VM entries.
•
VM-exit information fields. These fields receive information on VM exits and describe the cause and the
nature of VM exits. On some processors, these fields are read-only.
3
The VM-execution control fields, the VM-exit control fields, and the VM-entry control fields are sometimes referred
to collectively as VMX controls.
2. Earlier versions of this manual specified that the VMCS revision identifier was a 32-bit field. For all processors produced prior to this
change, bit 31 of the VMCS revision identifier was 0.
1. Logical processors that use the same VMCS revision identifier use the same size for VMCS regions.
2. Alternatively, software may map any of these regions or structures with the UC memory type. Doing so is strongly discouraged
unless necessary as it will cause the performance of transitions using those structures to suffer significantly. In addition, the pro-
cessor will continue to use the memory type reported in the VMX capability MSR IA32_VMX_BASIC with exceptions noted in Appen-
3. Software can discover whether these fields can be written by reading the VMX capability MSR IA32_VMX_MISC (see Appendix A.6).