Vol. 3C 32-1
CHAPTER 32
VIRTUALIZATION OF SYSTEM RESOURCES
32.1 OVERVIEW
When a VMM is hosting multiple guest environments (VMs), it must monitor potential interactions between soft-
ware components using the same system resources. These interactions can require the virtualization of resources.
This chapter describes the virtualization of system resources. These include: debugging facilities, address transla-
tion, physical memory, and microcode update facilities.
32.2
VIRTUALIZATION SUPPORT FOR DEBUGGING FACILITIES
The Intel 64 and IA-32 debugging facilities (see Chapter 17) provide breakpoint instructions, exception conditions,
register flags, debug registers, control registers and 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 debugging facilities. The following list describes features relevant
to virtualizing these facilities.
•
The VMM can program the exception-bitmap (see Section 24.6.3) to ensure it gets control on debug functions
(like breakpoint exceptions occurring while executing guest code such as INT3 instructions). Normally, debug
exceptions modify debug registers (such as DR6, DR7, IA32_DEBUGCTL). However, if debug exceptions cause
VM exits, exiting occurs before register modification.
•
The VMM may utilize the VM-entry event injection facilities described in Section 26.5 to inject debug or
breakpoint exceptions to the guest. See Section 32.2.1 for a more detailed discussion.
•
The MOV-DR exiting control bit in the processor-based VM-execution control field (see Section 24.6.2) can be
enabled by the VMM to cause VM exits on explicit guest access of various processor debug registers (for
example, MOV to/from DR0-DR7). These exits would always occur on guest access of DR0-DR7 registers
regardless of the values in CPL, DR4.DE or DR7.GD. Since all guest task switches cause VM exits, a VMM can
control any indirect guest access or modification of debug registers during guest task switches.
•
Guest software access to debug-related model-specific registers (such as IA32_DEBUGCTL MSR) can be
trapped by the VMM through MSR access control features (such as the MSR-bitmaps that are part of processor-
based VM-execution controls). See Section 31.10 for details on MSR virtualization.
•
Debug registers such as DR7 and the IA32_DEBUGCTL MSR may be explicitly modified by the guest (through
MOV-DR or WRMSR instructions) or modified implicitly by the processor as part of generating debug
exceptions. The current values of DR7 and the IA32_DEBUGCTL MSR are saved to guest-state area of VMCS on
every VM exit. Pending debug exceptions are debug exceptions that are recognized by the processor but not yet
delivered. See Section 26.6.3 for details on pending debug exceptions.
•
DR7 and the IA32-DEBUGCTL MSR are loaded from values in the guest-state area of the VMCS on every VM
entry. This allows the VMM to properly virtualize debug registers when injecting debug exceptions to guest.
Similarly, the RFLAGS
1
register is loaded on every VM entry (or pushed to stack if injecting a virtual event) from
guest-state area of the VMCS. Pending debug exceptions are also loaded from guest-state area of VMCS so that
they may be delivered after VM entry is completed.
32.2.1 Debug
Exceptions
If a VMM emulates a guest instruction that would encounter a debug trap (single step or data or I/O breakpoint), it
should cause that trap to be delivered. The VMM should not inject the debug exception using VM-entry event injec-
tion, but should set the appropriate bits in the pending debug exceptions field. This method will give the trap the
1. This chapter uses the notation RAX, RIP, RSP, RFLAGS, etc. for processor registers because most processors that support VMX oper-
ation also support Intel 64 architecture. For processors that do not support Intel 64 architecture, this notation refers to the 32-bit
forms of those registers (EAX, EIP, ESP, EFLAGS, etc.).