Hardware Reference
In-Depth Information
executed by a guest OS, thereby increasing the complexity of the VMM and reducing the per-
formance of running the VM.
Sections 2.5 and 2.7 give concrete examples of problematic instructions in the 80x86 archi-
tecture.
Impact Of Virtual Machines On Virtual Memory And I/O
Another challenge is virtualization of virtual memory, as each guest OS in every VM manages
its own set of page tables. To make this work, the VMM separates the notions of real and phys-
ical memory (which are often treated synonymously) and makes real memory a separate, in-
termediate level between virtual memory and physical memory. (Some use the terms virtual
memory , physical memory , and machine memory to name the same three levels.) The guest OS
maps virtual memory to real memory via its page tables, and the VMM page tables map the
guests' real memory to physical memory. The virtual memory architecture is specified either
via page tables, as in IBM VM/370 and the 80x86, or via the TLB structure, as in many RISC
architectures.
Rather than pay an extra level of indirection on every memory access, the VMM maintains
a shadow page table that maps directly from the guest virtual address space to the physical ad-
dress space of the hardware. By detecting all modifications to the guest's page table, the VMM
can ensure the shadow page table entries being used by the hardware for translations corres-
pond to those of the guest OS environment, with the exception of the correct physical pages
substituted for the real pages in the guest tables. Hence, the VMM must trap any attempt by
the guest OS to change its page table or to access the page table pointer. This is commonly
done by write protecting the guest page tables and trapping any access to the page table point-
er by a guest OS. As noted above, the later happens naturally if accessing the page table point-
er is a privileged operation.
The IBM 370 architecture solved the page table problem in the 1970s with an additional level
of indirection that is managed by the VMM. The guest OS keeps its page tables as before, so
the shadow pages are unnecessary. AMD has proposed a similar scheme for their Pacifica re-
vision to the 80x86.
To virtualize the TLB in many RISC computers, the VMM manages the real TLB and has a
copy of the contents of the TLB of each guest VM. To pull this of, any instructions that ac-
cess the TLB must trap. TLBs with Process ID tags can support a mix of entries from different
VMs and the VMM, thereby avoiding flushing of the TLB on a VM switch. Meanwhile, in the
background, the VMM supports a mapping between the VMs' virtual Process IDs and the real
Process IDs.
The final portion of the architecture to virtualize is I/O. This is by far the most difficult part
of system virtualization because of the increasing number of I/O devices atached to the com-
puter and the increasing diversity of I/O device types. Another difficulty is the sharing of a real
device among multiple VMs, and yet another comes from supporting the myriad of device
drivers that are required, especially if different guest OSes are supported on the same VM sys-
time The VM illusion can be maintained by giving each VM generic versions of each type of
I/O device driver, and then leaving it to the VMM to handle real I/O.
The method for mapping a virtual to physical I/O device depends on the type of device. For
example, physical disks are normally partitioned by the VMM to create virtual disks for guest
VMs, and the VMM maintains the mapping of virtual tracks and sectors to the physical ones.
Network interfaces are often shared between VMs in very short time slices, and the job of the
Search WWH ::




Custom Search