Volume 3B System Programming Guide_ Part 2 (794104), страница 64
Текст из файла (страница 64)
3 25-17VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONS25.9.532-Bit GuestsTo launch or resume a 32-bit guest, VMM writers can follow the steps outlined inSection 25.6, making sure that the “IA-32e-Mode Guest” VM-entry control bit is setto 0. Then the “IA-32e-Mode Guest” control bit is copied into the guestIA32_EFER.LME bit, establishing IA32_EFER.LMA as 0.25.10HANDLING MODEL SPECIFIC REGISTERSModel specific registers (MSR) provide a wide range of functionality.
They affectprocessor features, control the programming interfaces, or are used in conjunctionwith specific instructions. As part of processor virtualization, a VMM may wish toprotect some or all MSR resources from direct guest access.VMX operation provides the following features to virtualize processor MSRs.25.10.1 Using VM-Execution ControlsProcessor-based VM-execution controls provide two levels of support for handlingguest access to processor MSRs using RDMSR and WRMSR:•MSR bitmaps: In VMX implementations that support a 1-setting (see AppendixG) of the user-MSR-bitmaps execution control bit, MSR bitmaps can be used toprovide flexibility in managing guest MSR accesses. The MSR-bitmap-address inthe guest VMCS can be programmed by VMM to point to a bitmap region whichspecifies VM-exit behavior when reading and writing individual MSRs.MSR bitmaps form a 4-KByte region in physical memory and are required to bealigned to a 4-KByte boundary. The first 1-KByte region manages read control ofMSRs in the range 00000000H-00001FFFH; the second 1-KByte region coversread control of MSR addresses in the range C0000000H-C0001FFFH.
The bitmapsfor write control of these MSRs are located in the 2-KByte region immediatelyfollowing the read control bitmaps. While the MSR bitmap address is part ofVMCS, the MSR bitmaps themselves are not. This implies MSR bitmaps are notaccessible through VMREAD and VMWRITE instructions but rather by usingordinary memory writes. Also, they are not specially cached by the processor andmay be placed in normal cache-coherent memory by the VMM.When MSR bitmap addresses are properly programmed and the use-MSR-bitmapcontrol (see Section 20.6.2) is set, the processor consults the associated bit inthe appropriate bitmap on guest MSR accesses to the corresponding MSR andcauses a VM exit if the bit in the bitmap is set.
Otherwise, the access is permittedto proceed. This level of protection may be utilized by VMMs to selectively allowguest access to some MSRs while virtualizing others.•Default MSR protection: If the use-MSR-bitmap control is not set, an attemptby a guest to access any MSR causes a VM exit. This also occurs for any attempt25-18 Vol. 3VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONSto access an MSR outside the ranges identified above (even if the use-MSRbitmap control is set).VM exits due to guest MSR accesses may be identified by the VMM through VM-exitreason codes.
The MSR-read exit reason implies guest software attempted to read anMSR protected either by default or through MSR bitmaps. The MSR-write exit reasonimplies guest software attempting to write a MSR protected through the VM-execution controls. Upon VM exits caused by MSR accesses, the VMM may virtualize theguest MSR access through emulation of RDMSR/WRMSR.25.10.2 Using VM-Exit Controls for MSRsIf a VMM allows its guest to access MSRs directly, the VMM may need to store guestMSR values and load host MSR values for these MSRs on VM exits. This is especiallytrue if the VMM uses the same MSRs while in VMX root operation.A VMM can use the VM-exit MSR-store-address and the VM-exit MSR-store-count exitcontrol fields (see Section 20.7.2) to manage how MSRs are stored on VM exits.
TheVM-exit MSR-store-address field contains the physical address (16-byte aligned) ofthe VM-exit MSR-store area (a table of entries with 16 bytes per entry). Each tableentry specifies an MSR whose value needs to be stored on VM exits. The VM-exitMSR-store-count contains the number of entries in the table.Similarly the VM-exit MSR-load-address and VM-exit MSR-load-count fields point tothe location and size of the VM-exit MSR load area. The entries in the VM-exit MSRload area contain the host expected values of specific MSRs when a VM exit occurs.Upon VM-exit, bits 127:64 of each entry in the VM-exit MSR-store area is updatedwith the contents of the MSR indexed by bits 31:0.
Also, bits 127:64 of each entry inthe VM-exit MSR-load area is updated by loading with values from bits 127:64 thecontents of the MSR indexed by bits 31:0.25.10.3 Using VM-Entry Controls for MSRsA VMM may require specific MSRs to be loaded explicitly on VM entries whilelaunching or resuming guest execution. The VM-entry MSR-load-address andVM-entry MSR-load-count entry control fields determine how MSRs are loaded onVM-entries. The VM-entry MSR-load-address and count fields are similar in structureand function to the VM-exit MSR-load address and count fields, except the MSRloading is done on VM-entries.25.10.4 Handling Special-Case MSRs and InstructionsA number of instructions make use of designated MSRs in their operation.
The VMMmay need to consider saving the states of those MSRs. Instructions that merit suchconsideration include SYSENTER/SYSEXIT, SYSCALL/SYSRET, SWAPGS.Vol. 3 25-19VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONS25.10.4.1 Handling IA32_EFER MSRThe IA32_EFER MSR provides bit fields that allow system software to enableprocessor features. For example: the SCE bit enables SYSCALL/SYSRET and the NXEbit enables Execute-Disable-Bit functionality.VMX provides hardware support to preserve the values of these bits upon a VM entryafter a VM exit, such that it does not require VMM to modify these bits in IA32_EFER.25.10.4.2 Handling the SYSENTER and SYSEXIT InstructionsThe SYSENTER and SYSEXIT instructions use three dedicated MSRs (i.e.IA32_SYSENTER_CS, IA32_SYSENTER_ESP and IA32_SYSENTER_EIP) to managefast system calls.
These MSRs may be utilized by both the VMM and the guest OS tomanage system calls in VMX root operation and VMX non-root operation respectively.VMX provides special handling of these MSRs on VM exits and VM entries:•The save-SYSENTER-MSRs VM-Exit control field can be set to 1 to save theseMSRs to guest-state area in VMCS on VM-exits.•The load-SYSENTER-MSRs VM-exit control field allows the processor to loadthese MSRs from values saved in the host-state area of the VMCS on VM-exits.The load-SYSENTER-MSRs VM-Entry control field allows loading of the SYSENTERMSRs from guest-state area of the VMCS on VM entries.25.10.4.3 Handling the SYSCALL and SYSRET InstructionsThe SYSCALL/SYSRET instructions are similar to SYSENTER/SYSEXIT but aredesigned to operate within the context of a 64-bit flat code segment.
They are available only in 64-bit mode and only when the SCE bit of the IA32_EFER MSR is set.SYSCALL/SYSRET invocations can occur from either 32-bit compatibility mode application code or from 64-bit application code. Three related MSR registers(IA32_STAR, IA32_LSTAR, IA32_FMASK) are used in conjunction with fast systemcalls/returns that use these instructions.64-Bit hosts which make use of these instructions in the VMM environment will needto save the guest state of the above registers on VM exit, load the host state, andrestore the guest state on VM entry. One possible approach is to use the VM-exitMSR-save and MSR-load areas and the VM-entry MSR-load area defined by controlsin the VMCS.
A disadvantage to this approach, however, is that the approach resultsin the unconditional saving, loading, and restoring of MSR registers on each VM exitor VM entry.Depending on the design of the VMM, it is likely that many VM-exits will require nofast system call support but the VMM will be burdened with the additional overheadof saving and restoring MSRs if the VMM chooses to support fast system calluniformly. Further, even if the host intends to support fast system calls during aVM-exit, some of the MSR values (such as the setting of the SCE bit in IA32_EFER)25-20 Vol.
3VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONSmay not require modification as they may already be set to the appropriate value inthe guest.For performance reasons, a VMM may perform lazy save, load, and restore of theseMSR values on certain VM exits when it is determined that this is acceptable. Thelazy-save-load-restore operation can be carried out “manually” using RDMSR andWRMSR.25.10.4.4 Handling the SWAPGS InstructionThe SWAPGS instruction is available only in 64-bit mode.
It swaps the contents oftwo specific MSRs (IA32_GSBASE and IA32_KERNEL_GSBASE). The IA32_GSBASEMSR shadows the base address portion of the GS descriptor register; theIA32_KERNEL_GSBASE MSR holds the base address of the GS segment used by thekernel (typically it houses kernel structures). SWAPGS is intended for use with fastsystem calls when in 64-bit mode to allow immediate access to kernel structures ontransition to kernel mode.Similar to SYSCALL/SYSRET, IA-32e mode hosts which use fast system calls mayneed to save, load, and restore these MSR registers on VM exit and VM entry usingthe guidelines discussed in previous paragraphs.25.10.4.5 Implementation Specific Behavior on Writing to Certain MSRsAs noted in Sections 22.4 and 23.4, a processor may prevent writing to certain MSRswhen loading guest states on VM entries or storing guest states on VM exits.
This isdone to ensure consistent operation. The subset and number of MSRs subject torestrictions are implementation specific. For initial VMX implementations, there aretwo MSRs: IA32_BIOS_UPDT_TRIG and IA32_BIOS_SIGN_ID (see Appendix B).25.10.5 Handling Accesses to Reserved MSR AddressesPrivileged software (either a VMM or a guest OS) can access a model specific registerby specifying addresses in MSR address space. VMMs, however, must prevent a guestfrom accessing reserved MSR addresses in MSR address space.Consult Appendix B for lists of supported MSRs and their usage.
Use the MSR bitmapcontrol to cause a VM exit when a guest attempts to access a reserved MSR address.The response to such a VM exit should be to reflect #GP(0) back to the guest.25.11HANDLING ACCESSES TO CONTROL REGISTERSBit fields in control registers (CR0, CR4) control various aspects of processor operation. The VMM must prevent guests from modifying bits in CR0 or CR4 that arereserved at the time the VMM is written.Vol. 3 25-21VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONSGuest/host masks should be used by the VMM to cause VM exits when a guestattempts to modify reserved bits.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
