Information Technology Reference
In-Depth Information
the slow table lookup is used, but the resulting address is stored in a PTE in the
TLB for later reuse. If the TLB is full, the least recently used PTE is replaced. If
the page is not resident in memory, a page exception trap is generated.
Normally this approach works very well. In fact, contemporary processors have
separate TLBs for instructions and data, just as they typically have separate on-
chip instruction and data caches. SPARC processors keep statistics that Oracle
Solaris can probe to determine the hit rate being achieved, and large page sizes
(up to 256 MB) can be used to reduce the number of TLB entries needed for a
large memory application. This SPARC feature helps reduce TLB thrashing for
vertically scaling applications like Oracle.
Unfortunately, a serious complication arises in a virtual machine environment.
The TLB translates from a virtual address to a real one—that is, it uses two levels
of address. In contrast, a virtual machine environment typically uses three ad-
dress levels:
1. The address of the machine's RAM—sometimes called the physical address,
or “host real”—which is visible only to the hypervisor.
2. The virtual address for each virtual machine's virtual memory, which appears
to the guest OS as if it was a physical memory address. This is called a “guest
real” or simply “real” address, or “host virtual,” indicating that what the
guest thinks is an address in RAM is actual a virtual memory address. The
hypervisor maintains segment and page tables to map a guest's level 2
address to a level 1 address.
3. The virtual address spaces created by the guest OS for each guest application
process, called “guest virtual.” Each guest OS maintains segment and page
tables to map every process virtual address (level 3) to what it thinks is a
level 1 address.
Non-virtualized systems perform one translation from the virtual address to a
real one, but two translations are needed in a virtual machine environment.
VM/370 bypassed this problem for its CMS time-sharing users by having CMS
run only one program at a time and use only a single address space. For guest op-
erating systems that themselves provided virtual memory (MVS, or VM/370 itself),
the solution was to create per-guest shadow page tables that are indexed by the
guest-virtual segment and page numbers, and contain the host-real addresses cor-
responding to those guest pages. While implementation details vary, this is concep-
tually the same method used today in virtual machine monitors such as VMware.
Maintaining these tables can be a resource-intensive endeavor. When the guest
OS context switches between different processes, the hypervisor must intercept
the change in guest address spaces and switch to a different shadow page table.
When the hypervisor context switches from one guest to another, it must purge
the contents of the hardware-provided TLBs (so that address references from
Search WWH ::
Custom Search