Information Technology Reference
In-Depth Information
On the original CP/67 hypervisor, the only timer mechanism was an interval
timer based on a location in memory that was decremented on a periodic basis
and caused a timer interrupt when it underflowed. Clearly, this practice could not
scale, as it would have required the hypervisor to accurately update a location in
each guest's memory many times per second. The next hardware architecture
added hardware timers that were accessed by privileged instructions and main-
tained both the current time of day and the accumulated CPU time. The guest
OS referred to these clocks via intercepted instructions, giving the hypervisor a
chance to provide correctly adjusted time-of-day clock values, and updated CPU-
usage timers that reflected the time that the virtual machine was dispatched and
executing instructions.
This problem persists among current hypervisors. x86 has several hardware
time facilities, and hypervisors such as VirtualBox, VMware, and Xen have provi-
sions for dealing with clock skew. For example, VMware emulates the x86 CMOS
Real Time Clock (RTC) and Programmable Interval Timer (PIT) and provides
“apparent time” that can lag real time but catch up to it. Clock skew may also
occur when several operating systems (Windows, Linux) keep time by record-
ing timer interrupts (ticks, or “jiffies”) whose duration may be longer than the
specified timer interval. VMware provides add-on tools for different hypervisors
to compensate for clock skew. Modern operating systems can also use the Network
Time Protocol (NTP) for coordinating time against an external standard.
Solaris Containers completely bypasses this problem, as each container runs off
the same clock and timer environment provided by the kernel. Clock skew is also
avoided with Logical Domains, as clock resolution is provided by the firmware and
per-CPU hardware. The hypervisor additionally maintains a TOD offset for each
domain.
Synthetic Instructions for Guest-Hypervisor Service Protocols
VM/370 introduced a private interface using a synthetic instruction for guest com-
munication with the hypervisor and access to the APIs it exports. The DIAGNOSE
instruction is one of the few instructions on the 370 defined to have model-depen-
dent behavior; it is used only by operating systems in the supervisor state, so it
could be borrowed for this new purpose when in a virtual machine. The trap and
emulate operation still occurred, but DIAGNOSE-based services permitted shorter
path lengths than the real-machine instructions they replaced. This advance was
especially significant for I/O, where a simple synchronous, interrupt-free protocol
provided a lower-cost I/O interface than emulation of native instructions.
Synthetic instructions also made it possible to add services to make a virtual
machine more functional than a real one. Different APIs provided a command in-
terface to the hypervisor, inter-user message passing, input/output services, timer
Search WWH ::
Custom Search