Volume 3B System Programming Guide_ Part 2 (794104), страница 62
Текст из файла (страница 62)
3VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONSan execution of the IRET instruction that removed virtual-NMI blocking. Inparticular, it provides this indication if the following are both true:— Bit 31 (valid) in the IDT-vectoring information field is 0.— The value of bits 7:0 (vector) of the VM-exit interruption-information field isnot 8 (the VM exit is not due to a double-fault exception).If both are true and bit 12 of the VM-exit interruption-information field is 1, therewas virtual-NMI blocking before guest software executed the IRET instructionthat caused the fault that caused the VM exit. The VMM should set bit 3 (blockingby NMI) in the interruptibility-state field (using VMREAD and VMWRITE) beforeresuming guest software.•Bit 31 (valid) of the IDT-vectoring information field indicates, if set, that theexception causing the VM exit occurred while another event was being deliveredto guest software. The VMM should ensure that the other event is delivered whenguest software is resumed.
It can do so using the VM-entry event injectiondescribed in Section 22.5 and detailed in the following paragraphs:— The VMM can copy (using VMREAD and VMWRITE) the contents of the IDTvectoring information field (which is presumed valid) to the VM-entry interruption-information field (which, if valid, will cause the exception to bedelivered 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 IDTvectoring information field is undefined after all VM exits. If this bit iscopied as 1 into the VM-entry interruption-information field, the nextVM 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 (indicatingNMI), the VM exit occurred during delivery of an NMI that had beeninjected as part of the previous VM entry.
In this case, bit 3 (blocking byNMI) will be 1 in the interruptibility-state field in the VMCS. The VMMshould clear this bit; otherwise, the next VM entry will fail (see Section22.3.1.5).— The VMM can also copy the contents of the IDT-vectoring error-code field tothe VM-entry exception error-code field. This need not be done if bit 11 (errorcode valid) is clear in the IDT-vectoring information field.— The VMM can also copy the contents of the VM-exit instruction-length field tothe VM-entry instruction-length field. This need be done only if bits 10:8(interruption type) in the IDT-vectoring information field indicate eithersoftware interrupt, privileged software exception, or software exception.Vol.
3 25-11VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONS25.8MULTI-PROCESSOR CONSIDERATIONSThe most common VMM design will be the symmetric VMM. This type of VMM runs thesame VMM binary on all logical processors. Like a symmetric operating system, thesymmetric VMM is written to ensure all critical data is updated by only one processorat a time, IO devices are accessed sequentially, and so forth. Asymmetric VMMdesigns are possible.
For example, an asymmetric VMM may run its scheduler on oneprocessor and run just enough of the VMM on other processors to allow the correctexecution of guest VMs. The remainder of this section focuses on the multi-processorconsiderations for a symmetric VMM.A symmetric VMM design does not preclude asymmetry in its operations. Forexample, a symmetric VMM can support asymmetric allocation of logical processorresources to guests. Multiple logical processors can be brought into a single guestenvironment to support an MP-aware guest OS.
Because an active VMCS can notcontrol more than one logical processor simultaneously, a symmetric VMM mustmake copies of its VMCS to control the VM allocated to support an MP-aware guestOS. Care must be taken when accessing data structures shared between theseVMCSs. See Section 25.8.4.Although it may be easier to develop a VMM that assumes a fully-symmetric view ofhardware capabilities (with all processors supporting the same processor featuresets, including the same revision of VMX), there are advantages in developing a VMMthat comprehends different levels of VMX capability (reported by VMX capabilityMSRs).
One possible advantage of such an approach could be that an existing software installation (VMM and guest software stack) could continue to run withoutrequiring software upgrades to the VMM, when the software installation is upgradedto run on hardware with enhancements in the processor’s VMX capabilities. Anotheradvantage could be that a single software installation image, consisting of a VMM andguests, 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 featuressupported by all VMX revisions, or choose to understand the asymmetry of the VMXcapabilities and assign VMs accordingly.This section outlines some of the considerations to keep in mind when developing anMP-aware VMM.25.8.1InitializationBefore enabling VMX, an MP-aware VMM must check to make sure that all processorsin 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 andthat 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 capabilityMSR’s on each processor.25-12 Vol.
3VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONS25.8.2Moving a VMCS Between ProcessorsAn 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 slowerthan 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 ofVMCLEAR, VMPTRLD and VMLAUNCH.•Operations involving VMCLEAR can impact performance negatively. SeeSection 20.11.A VMM scheduler should make an effort to schedule a guest VMCS to run on thelogical processor where it last ran.
Such a scheduler might also benefit from doinglazy VMCLEARs (that is: performing a VMCLEAR on a VMCS only when the schedulerknows the VMCS is being moved to a new logical processor). The remainder of thissection describes the steps a VMM must take to move a VMCS from one processor toanother.A VMM must check the VMCS revision identifier in the VMX capability MSRIA32_VMX_BASIC to determine if the VMCS regions are identical between all logicalprocessors.
If the VMCS regions are identical (same revision ID) the followingsequence can be used to move or copy the VMCS from one logical processor toanother:•Perform a VMCLEAR operation on the source logical processor. This ensures thatall 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 anoptional step assuming the VMM wishes to relocate the VMCS or move the VMCSto another system.•Perform a VMPTRLD of the physical address of VMCS region on the destinationprocessor to establish its current VMCS pointer.If the revision identifiers are different, each field must be copied to an intermediatestructure using individual reads (VMREAD) from the source fields and writes(VMWRITE) to destination fields.
Care must be taken on fields that are hard-wired tocertain values on some processor implementations.25.8.3Paired Index-Data RegistersA VMM may need to virtualize hardware that is visible to software using paired indexdata 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 pairscan be moved during execution. In this case, the index (e.g. CF8) should be part ofVol. 3 25-13VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONSthe virtualized state. If the VM is moved during execution, writes to the index shouldbe redone so subsequent data reads/writes go to the right location.25.8.4External Data StructuresCertain fields in the VMCS point to external data structures (for example: the MSRbitmap, the I/O bitmaps).
If a logical processor is in VMX non-root operation, none ofthe external structures referenced by that logical processor's current VMCS should bemodified by any logical processor or DMA. Before updating one of these structures,the VMM must ensure that no logical processor whose current VMCS references thestructure is in VMX non-root operation.If a VMM uses multiple VMCS with each VMCS using separate external structures,and these structures must be kept synchronized, the VMM must apply the same careto updating these structures.25.8.5CPUID EmulationCPUID reports information that is used by OS and applications to detect hardwarefeatures. It also provides multi-threading/multi-core configuration information.
Forexample, MP-aware OSs rely on data reported by CPUID to discover the topology oflogical processors in a platform (see Section 7.10, “Programming Considerations forHardware Multi-Threading Capable Processors,” in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A).If a VMM is to support asymmetric allocation of logical processor resources to guestOSs that are MP aware, then the VMM must emulate CPUID for its guests. The emulation of CPUID by the VMM must ensure the guest’s view of CPUID leaves are consistent with the logical processor allocation committed by the VMM to each guest OS.25.932-BIT AND 64-BIT GUEST ENVIRONMENTSFor the most part, extensions provided by VMX to support virtualization are orthogonal to the extensions provided by Intel 64 architecture.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
