31-10 Vol. 3C
VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONS
should set bit 3 (blocking by NMI) in the interruptibility-state field (using VMREAD and VMWRITE) before
resuming guest software.
•
Bit 31 (valid) of the IDT-vectoring information field indicates, if set, that the exception causing the VM exit
occurred while another event was being delivered to guest software. The VMM should ensure that the other
event is delivered when guest software is resumed. It can do so using the VM-entry event injection described
in Section 26.5 and detailed in the following paragraphs:
— The VMM can copy (using VMREAD and VMWRITE) the contents of the IDT-vectoring information field
(which is presumed valid) to the VM-entry interruption-information field (which, if valid, will cause the
exception to be delivered as part of the next VM entry).
•
The VMM should ensure that reserved bits 30:12 in the VM-entry interruption-information field are 0. In
particular, the value of bit 12 in the IDT-vectoring information field is undefined after all VM exits. If this
bit is copied as 1 into the VM-entry interruption-information field, the next VM entry will fail because the
bit should be 0.
•
If the “virtual NMIs” VM-execution control is 1 and the value of bits 10:8 (interruption type) in the IDT-
vectoring information field is 2 (indicating NMI), the VM exit occurred during delivery of an NMI that had
been injected as part of the previous VM entry. In this case, bit 3 (blocking by NMI) will be 1 in the inter-
ruptibility-state field in the VMCS. The VMM should clear this bit; otherwise, the next VM entry will fail
(see Section 26.3.1.5).
— The VMM can also copy the contents of the IDT-vectoring error-code field to the VM-entry exception error-
code field. This need not be done if bit 11 (error code valid) is clear in the IDT-vectoring information field.
— The VMM can also copy the contents of the VM-exit instruction-length field to the VM-entry instruction-
length field. This need be done only if bits 10:8 (interruption type) in the IDT-vectoring information field
indicate either software interrupt, privileged software exception, or software exception.
31.8 MULTI-PROCESSOR
CONSIDERATIONS
The most common VMM design will be the symmetric VMM. This type of VMM runs the same VMM binary on all
logical processors. Like a symmetric operating system, the symmetric VMM is written to ensure all critical data is
updated by only one processor at a time, IO devices are accessed sequentially, and so forth. Asymmetric VMM
designs are possible. For example, an asymmetric VMM may run its scheduler on one processor and run just
enough of the VMM on other processors to allow the correct execution of guest VMs. The remainder of this section
focuses on the multi-processor considerations for a symmetric VMM.
A symmetric VMM design does not preclude asymmetry in its operations. For example, a symmetric VMM can
support asymmetric allocation of logical processor resources to guests. Multiple logical processors can be brought
into a single guest environment to support an MP-aware guest OS. Because an active VMCS can not control more
than one logical processor simultaneously, a symmetric VMM must make copies of its VMCS to control the VM allo-
cated to support an MP-aware guest OS. Care must be taken when accessing data structures shared between these
VMCSs. See Section 31.8.4.
Although it may be easier to develop a VMM that assumes a fully-symmetric view of hardware capabilities (with all
processors supporting the same processor feature sets, including the same revision of VMX), there are advantages
in developing a VMM that comprehends different levels of VMX capability (reported by VMX capability MSRs). One
possible advantage of such an approach could be that an existing software installation (VMM and guest software
stack) could continue to run without requiring software upgrades to the VMM, when the software installation is
upgraded to run on hardware with enhancements in the processor’s VMX capabilities. Another advantage could be
that a single software installation image, consisting of a VMM and guests, could be deployed to multiple hardware
platforms with varying VMX capabilities. In such cases, the VMM could fall back to a common subset of VMX
features supported by all VMX revisions, or choose to understand the asymmetry of the VMX capabilities and assign
VMs accordingly.
This section outlines some of the considerations to keep in mind when developing an MP-aware VMM.