Volume 3B System Programming Guide_ Part 2 (794104), страница 65
Текст из файла (страница 65)
Read shadows should be used to ensure that theguest always reads the reserved value (usually 0) for such bits. The VMM response toVM exits due to attempts from a guest to modify reserved bits should be to emulatethe response which the processor would have normally produced (usually a #GP(0)).25.12PERFORMANCE CONSIDERATIONSVMX provides hardware features that may be used for improving processor virtualization performance. VMMs must be designed to use this support properly.
The basicidea behind most of these performance optimizations of the VMM is to reduce thenumber of VM exits while executing a guest VM.This section lists ways that VMMs can take advantage of the performance enhancingfeatures in VMX.•Read Access to Control Registers. Analysis of common client workloads withcommon PC operating systems in a virtual machine shows a large number ofVM-exits are caused by control register read accesses (particularly CR0). Readsof CR0 and CR4 does not cause VM exits. Instead, they return values from theCR0/CR4 read-shadows configured by the VMM in the guest controlling-VMCSwith the guest-expected values.•Write Access to Control Registers. Most VMM designs require only certain bitsof the control registers to be protected from direct guest access.
Write access toCR0/CR4 registers can be reduced by defining the host-owned and guest-ownedbits in them through the CR0/CR4 host/guest masks in the VMCS. CR0/CR4 writevalues by the guest are qualified with the mask bits. If they change only guestowned bits, they are allowed without causing VM exits. Any write that causechanges to host-owned bits cause VM exits and need to be handled by the VMM.•Access Rights based Page Table protection.
For VMM that implementaccess-rights-based page table protection, the VMCS provides a CR3 target valuelist that can be consulted by the processor to determine if a VM exit is required.Loading of CR3 with a value matching an entry in the CR3 target-list are allowedto proceed without VM exits. The VMM can utilize the CR3 target-list to savepage-table hierarchies whose state is previously verified by the VMM.•Page-fault handling.
Another common cause for a VM exit is due to page-faultsinduced by guest address remapping done through virtual memory virtualization.VMX provides page-fault error-code mask and match fields in the VMCS to filterVM exits due to page-faults based on their cause (reflected in the error-code).25-22 Vol. 3CHAPTER 26VIRTUALIZATION OF SYSTEM RESOURCES26.1OVERVIEWWhen a VMM is hosting multiple guest environments (VMs), it must monitor potentialinteractions between software components using the same system resources. Theseinteractions can require the virtualization of resources. This chapter describes thevirtualization of system resources. These include: debugging facilities, addresstranslation, physical memory, and microcode update facilities.26.2VIRTUALIZATION SUPPORT FOR DEBUGGINGFACILITIESThe Intel 64 and IA-32 debugging facilities (see Chapter 18) provide breakpointinstructions, exception conditions, register flags, debug registers, control registersand storage buffers for functions related to debugging system and application software.
In VMX operation, a VMM can support debugging system and application software from within virtual machines if the VMM properly virtualizes debuggingfacilities. The following list describes features relevant to virtualizing these facilities.•The VMM can program the exception-bitmap (see Section 20.6.3) to ensure itgets control on debug functions (like breakpoint exceptions occurring whileexecuting guest code such as INT3 instructions). Normally, debug exceptionsmodify debug registers (such as DR6, DR7, IA32_DEBUGCTL). However, if debugexceptions cause VM exits, exiting occurs before register modification.•The VMM may utilize the VM-entry event injection facilities described in Section22.5 to inject debug or breakpoint exceptions to the guest.
See Section 26.2.1for a more detailed discussion.•The MOV-DR exiting control bit in the processor-based VM-execution control field(see Section 20.6.2) can be enabled by the VMM to cause VM exits on explicitguest access of various processor debug registers (for example, MOV to/fromDR0-DR7). These exits would always occur on guest access of DR0-DR7 registersregardless of the values in CPL, DR4.DE or DR7.GD. Since all guest task switchescause VM exits, a VMM can control any indirect guest access or modification ofdebug registers during guest task switches.•Guest software access to debug-related model-specific registers (such asIA32_DEBUGCTL MSR) can be trapped by the VMM through MSR access controlfeatures (such as the MSR-bitmaps that are part of processor-based VMexecution controls). See Section 25.10 for details on MSR virtualization.Vol.
3 26-1VIRTUALIZATION OF SYSTEM RESOURCES•Debug registers such as DR7 and the IA32_DEBUGCTL MSR may be explicitlymodified by the guest (through MOV-DR or WRMSR instructions) or modifiedimplicitly by the processor as part of generating debug exceptions. The currentvalues of DR7 and the IA32_DEBUGCTL MSR are saved to guest-state area ofVMCS on every VM exit.
Pending debug exceptions are debug exceptions that arerecognized by the processor but not yet delivered. See Section 22.6.3 for detailson pending debug exceptions.•DR7 and the IA32-DEBUGCTL MSR are loaded from values in the guest-state areaof the VMCS on every VM entry. This allows the VMM to properly virtualize debugregisters when injecting debug exceptions to guest. Similarly, the RFLAGS1register is loaded on every VM entry (or pushed to stack if injecting a virtualevent) from guest-state area of the VMCS. Pending debug exceptions are alsoloaded from guest-state area of VMCS so that they may be delivered after VMentry is completed.26.2.1Debug ExceptionsIf a VMM emulates a guest instruction that would encounter a debug trap (single stepor data or I/O breakpoint), it should cause that trap to be delivered. The VMM shouldnot inject the debug exception using VM-entry event injection, but should set theappropriate bits in the pending debug exceptions field.
This method will give the trapthe right priority with respect to other events. (If the exception bitmap wasprogrammed to cause VM exits on debug exceptions, the debug trap will cause a VMexit. At this point, the trap can be injected during VM entry with the proper priority.)There is a valid pending debug exception if the BS bit (see Table 20-4) is set, regardless of the values of RFLAGS.TF or IA32_DEBUGCTL.BTF. The values of these bits donot impact the delivery of pending debug exceptions.VMMs should exercise care when emulating a guest write (attempted using WRMSR)to IA32_DEBUGCTL to modify BTF if this is occurring with RFLAGS.TF = 1 and after aMOV SS or POP SS instruction (for example: while debug exceptions are blocked).Note the following:•Normally, if WRMSR clears BTF while RFLAGS.TF = 1 and with debug exceptionsblocked, a single-step trap will occur after WRMSR. A VMM emulating such aninstruction should set the BS bit (see Table 20-4) in the pending debugexceptions field before VM entry.•Normally, if WRMSR sets BTF while RFLAGS.TF = 1 and with debug exceptionsblocked, neither a single-step trap nor a taken-branch trap can occur afterWRMSR.
A VMM emulating such an instruction should clear the BS bit (see Table20-4) in the pending debug exceptions field before VM entry.1. This chapter uses the notation RAX, RIP, RSP, RFLAGS, etc. for processor registers because mostprocessors that support VMX operation also support Intel 64 architecture. For processors that donot support Intel 64 architecture, this notation refers to the 32-bit forms of those registers(EAX, EIP, ESP, EFLAGS, etc.).26-2 Vol. 3VIRTUALIZATION OF SYSTEM RESOURCES26.3MEMORY VIRTUALIZATIONVMMs must control physical memory to ensure VM isolation and to remap guestphysical addresses in host physical address space for virtualization.
Memory virtualization allows the VMM to enforce control of physical memory and yet support guestOSs’ expectation to manage memory address translation.26.3.1Processor Operating Modes & Memory VirtualizationMemory virtualization is required to support guest execution in various processoroperating modes.
This includes: protected mode with paging, protected mode withno paging, real-mode and any other transient execution modes. VMX allows guestoperation in protected-mode with paging enabled and in virtual-8086 mode (withpaging enabled) to support guest real-mode execution. Guest execution in transientoperating modes (such as in real mode with one or more segment limits greater than64-KByte) must be emulated by the VMM.Since VMX operation requires processor execution in protected mode with paging(through CR0 and CR4 fixed bits), the VMM may utilize paging structures to supportmemory virtualization.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
