Information Technology Reference
In-Depth Information
in which privileged instructions are suppressed and generate a program trap.
In non-virtualized environments, this architecture protects system integrity by
preventing malicious or buggy applications from issuing instructions that change
machine state (such as enabling or disabling interrupts, or changing memory
mapping) and potentially crashing the system or creating security exposures.
This mechanism works differently in virtual machine environments, as guest
operating systems are expected to execute privileged instructions and have them
function in the same way as they would on the real machine. An attempt by a
guest operating system to execute a privileged instruction generates a program
trap to the hypervisor, which then emulates the instruction (in software) solely in
the context of the virtual machine. This behavior has performance implications
that will be discussed later in this appendix.
This paradigm supports the Popek and Goldberg properties and is still used by
hypervisors. Note that the x86 architecture does not satisfy the “trap and execute”
virtualization described by Popek and Goldberg. Instead, x86 virtual machines can
tell that they have been “deprivileged,” and some privileged instructions (such as
popf
) are suppressed but do not cause a trap. The x86 hypervisors handle this
situation in different ways: VMware performs binary translation to replace these
instructions with code that manipulates guest state without privileged instruc-
tions, or with a call to the hypervisor, whereas Xen uses paravirtualization to
eliminate use of privileged instructions.
Virtual Machines Emerge from the Laboratory
CP-40 was ported to the System/360 model 67, IBM's first production virtual
memory computer, and renamed CP/67. The 360/67 was intended to be IBM's
official time-sharing system, as IBM began to adopt this style of computing as an
addition to OS/360's batch workloads. A new and ambitious operating system,
TSS/360, was written for it. While TSS/360 introduced novel concepts, it was
burdened by delays and had reliability and performance problems. CP/67, which
had a simpler design and was based on virtual machines, began to be used for
time sharing and program development using a simple interactive single-user OS
called the Cambridge Monitor System (CMS).
Instead of a single OS instance shared by multiple users, as in CTSS, Multics,
and UNIX, CMS provided a lightweight single-user OS instance for each user,
and exploited a separation of functions with the hypervisor for resource manage-
ment and access control. This strategy permitted use of a very simple design: a
single flat per-user address space, a non-multitasking program model (multitasking
was provided by overlapped execution of multiple CMS users), a minimal permis-
sion model (all security was implemented in the virtual machine monitor), and a
Search WWH ::
Custom Search