Vol. 3C 31-17
VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONS
31.10.5 Handling Accesses to Reserved MSR Addresses
Privileged software (either a VMM or a guest OS) can access a model specific register by specifying addresses in
MSR address space. VMMs, however, must prevent a guest from accessing reserved MSR addresses in MSR address
space.
Consult Chapter 35 for lists of supported MSRs and their usage. Use the MSR bitmap control 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.
31.11 HANDLING ACCESSES TO CONTROL REGISTERS
Bit 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 are reserved at the time the VMM is written.
Guest/host masks should be used by the VMM to cause VM exits when a guest attempts to modify reserved bits.
Read shadows should be used to ensure that the guest always reads the reserved value (usually 0) for such bits.
The VMM response to VM exits due to attempts from a guest to modify reserved bits should be to emulate the
response which the processor would have normally produced (usually a #GP(0)).
31.12 PERFORMANCE
CONSIDERATIONS
VMX provides hardware features that may be used for improving processor virtualization performance. VMMs must
be designed to use this support properly. The basic idea behind most of these performance optimizations of the
VMM is to reduce the number of VM exits while executing a guest VM.
This section lists ways that VMMs can take advantage of the performance enhancing features in VMX.
•
Read Access to Control Registers. Analysis of common client workloads with common PC operating systems
in a virtual machine shows a large number of VM-exits are caused by control register read accesses (particu-
larly CR0). Reads of CR0 and CR4 does not cause VM exits. Instead, they return values from the CR0/CR4 read-
shadows configured by the VMM in the guest controlling-VMCS with the guest-expected values.
•
Write Access to Control Registers. Most VMM designs require only certain bits of the control registers to be
protected from direct guest access. Write access to CR0/CR4 registers can be reduced by defining the host-
owned and guest-owned bits in them through the CR0/CR4 host/guest masks in the VMCS. CR0/CR4 write
values by the guest are qualified with the mask bits. If they change only guest-owned bits, they are allowed
without causing VM exits. Any write that cause changes to host-owned bits cause VM exits and need to be
handled by the VMM.
•
Access Rights based Page Table protection. For VMM that implement access-rights-based page table
protection, the VMCS provides a CR3 target value list 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 allowed to proceed
without VM exits. The VMM can utilize the CR3 target-list to save page-table hierarchies whose state is
previously verified by the VMM.
•
Page-fault handling. Another common cause for a VM exit is due to page-faults induced by guest address
remapping done through virtual memory virtualization. VMX provides page-fault error-code mask and match
fields in the VMCS to filter VM exits due to page-faults based on their cause (reflected in the error-code).
31.13 USE OF THE VMX-PREEMPTION TIMER
The VMX-preemption timer allows VMM software to preempt guest VM execution after a specified amount of time.
Typical VMX-preemption timer usage is to program the initial VM quantum into the timer, save the timer value on
each successive VM-exit (using the VM-exit control “save preemption timer value”) and run the VM until the timer
expires.
In an alternative scenario, the VMM may use another timer (e.g. the TSC) to track the amount of time the VM has
run while still using the VMX-preemption timer for VM preemption. In this scenario the VMM would not save the