Information Technology Reference
In-Depth Information
executed in a virtual machine, they do exactly the same thing, but the vector in
physical memory is owned by the hypervisor (which uses it for its own purposes)
and, therefore, points to a location in the hypervisor instead of the guest OS. The
hypervisor's interrupt service routine determines whether the trapped system call
was from a virtual machine. If so, it reflects the system call instruction to the
guest OS by using the equivalent guest's virtual memory address—a process that
inflates CPU path lengths and adds overhead.
A similar process occurs when reflecting a physical interrupt (timer or I/O event
completion) to a guest. The program running at that moment is interrupted with
a context switch to the hypervisor. The hypervisor then determines which virtual
machine the physical interrupt is associated with and maps the interrupt into the
virtual machine's state. Several context switches take place between hypervisor
and guest.
Instruction simulation and interrupt reflection require thousands of instruc-
tions and may occur thousands of times per second. As such, these operations
constitute a substantial source of overhead, especially for I/O intensive workloads
generating many system calls and many privileged operations, and pose a chal-
lenge on most hypervisor-based systems.
Sometimes the emulated hardware capability is trivial in nature and can be
implemented with a few instructions. For example, simulating an instruction to
mask interrupt classes might take just a few instructions. In such cases, most of
the added CPU time is spent context switching—purely overhead—and very little
time emulating the instruction causing the trap. In other cases, the instruction to
be simulated requires substantial processing. This is typical for I/O instructions,
which may have complex semantics on real hardware, and can require substantial
CPU time when emulated via software.
Early VM systems were seen to spend a majority of their CPU time emulating
instructions rather than running user applications. One obvious answer was to
instrument and tune high-frequency code paths. An alternative approach was to
move this privileged instruction simulation into “virtual machine” assist firmware.
Because IBM controlled the guest operating systems and hypervisor, and the
hardware they ran on, they could coordinate their designs and move heavily used
hypervisor software code paths into microcode. With these assists, privileged in-
structions caused a branch to a microcode routine in firmware rather than the
original trap. The microcode determined whether the interrupting instruction
was one it could handle, as many privileged instructions were too complex to emu-
late in firmware, or involved guest state changes that required intervention by
the hypervisor. If microcode could handle the instruction, it would emulate the
instruction entirely in firmware. This process was faster than the original trap
and software emulation approach, and reduced instruction simulation overhead.
These assists made it possible to run guest operating systems with near-native
 
Search WWH ::




Custom Search