Vol. 3C 32-3

VIRTUALIZATION OF SYSTEM RESOURCES

32.3.3 

Virtualizing Virtual Memory by Brute Force

VMX provides the hardware features required to fully virtualize guest virtual memory accesses. VMX allows the 
VMM to trap guest accesses to the PAT (Page Attribute Table) MSR and the MTRR (Memory Type Range Registers). 
This control allows the VMM to virtualize the specific memory type of a guest memory. The VMM may control 
caching by controlling the guest CR0.CRD and CR0.NW bits, as well as by trapping guest execution of the INVD 
instruction. The VMM can trap guest CR3 loads and stores, and it may trap guest execution of INVLPG.
Because a VMM must retain control of physical memory, it must also retain control over the processor’s address-
translation mechanisms. Specifically, this means that only the VMM can access CR3 (which contains the base of the 
page directory) and can execute INVLPG (the only other instruction that directly manipulates the TLB). 
At the same time that the VMM controls address translation, a guest operating system will also expect to perform 
normal memory management functions. It will access CR3, execute INVLPG, and modify (what it believes to be) 
page directories and page tables. Virtualization of address translation must tolerate and support guest attempts to 
control address translation. 
A simple-minded way to do this would be to ensure that all guest attempts to access address-translation hardware 
trap to the VMM where such operations can be properly emulated. It must ensure that accesses to page directories 
and page tables also get trapped. This may be done by protecting these in-memory structures with conventional 
page-based protection. The VMM can do this because it can locate the page directory because its base address is 
in CR3 and the VMM receives control on any change to CR3; it can locate the page tables because their base 
addresses are in the page directory.
Such a straightforward approach is not necessarily desirable. Protection of the in-memory translation structures 
may be cumbersome. The VMM may maintain these structures with different values (e.g., different page base 
addresses) than guest software. This means that there must be traps on guest attempt to read these structures 
and that the VMM must maintain, in auxiliary data structures, the values to return to these reads. There must also 
be traps on modifications to these structures even if the translations they effect are never used. All this implies 
considerable overhead that should be avoided.

32.3.4 

Alternate Approach to Memory Virtualization

Guest software is allowed to freely modify the guest page-table hierarchy without causing traps to the VMM. 
Because of this, the active page-table hierarchy might not always be consistent with the guest hierarchy. Any 
potential problems arising from inconsistencies can be solved using techniques analogous to those used by the 
processor and its TLB.
This section describes an alternative approach that allows guest software to freely access page directories and 
page tables. Traps occur on CR3 accesses and executions of INVLPG. They also occur when necessary to ensure 
that guest modifications to the translation structures actually take effect. The software mechanisms to support this 
approach are collectively called virtual TLB. This is because they emulate the functionality of the processor’s phys-
ical translation look-aside buffer (TLB).
The basic idea behind the virtual TLB is similar to that behind the processor TLB. While the page-table hierarchy 
defines the relationship between physical to linear address, it does not directly control the address translation of 
each memory access. Instead, translation is controlled by the TLB, which is occasionally filled by the processor with 
translations derived from the page-table hierarchy. With a virtual TLB, the page-table hierarchy established by 
guest software (specifically, the guest operating system) does not control translation, either directly or indirectly. 
Instead, translation is controlled by the processor (through its TLB) and by the VMM (through a page-table hier-
archy that it maintains).
Specifically, the VMM maintains an alternative page-table hierarchy that effectively caches translations derived 
from the hierarchy maintained by guest software. The remainder of this document refers to the former as the 
active page-table hierarchy (because it is referenced by CR3 and may be used by the processor to load its TLB) and 
the latter as the guest page-table hierarchy (because it is maintained by guest software). The entries in the active 
hierarchy may resemble the corresponding entries in the guest hierarchy in some ways and may differ in others.
Guest software is allowed to freely modify the guest page-table hierarchy without causing VM exits to the VMM. 
Because of this, the active page-table hierarchy might not always be consistent with the guest hierarchy. Any 
potential problems arising from any inconsistencies can be solved using techniques analogous to those used by the 
processor and its TLB. Note the following: