--- background.tex~ 2007-04-07 15:44:41.000000000 -0500
+++ background.tex 2007-04-07 21:19:46.000000000 -0500
@@ -1,36 +1,30 @@
-\section {BACKGROUND}
-
-The x86 platform today is evolving to better support hardware
-virtualization. New processors marketed by AMD and Intel now include
-hardware support for virtualizing the CPU and Memory Management Unit
-(MMU). More hardware support is forthcoming, for example, separate I/O
-Memory Management.
-
-Linux recently gained self-virtualizing capabilities for
-both older and newer x86 processors. The inclusion of the
-\texttt{paravirt\_ops} interface in \texttt{2.6.20}
-provides support for kernel
-paravirtualization\footnote{\url{http://ozlabs.org/~rusty/index.cgi/tech/2006-07-28.html}}.
-KVM\footnote{\url{http://sourceforge.net/projects/kvm}}, which is also included in \texttt{2.6.20} uses processor
-virtualization instructions to create virtual machines that run as
-normal Linux processes. module, which uses
-new hardware virtualization support to make Linux self\- virtualizing.
-
-
-The \texttt{lguest}
-hypervisor\footnote{\url{http://lguest.ozlabs.org/}}, which will
-probably be included in future version of Linux, provides a full
-end-to-end implementation of the \texttt{paravirt\_ops} interface and
-makes Linux self-virtualizing without any hardware assistance.
+\section {Background}
+The x86 platform today is evolving to better support
+virtualization. Extensions present in both AMD and Intel's latest
+generation of processors include support for simplifying CPU virtualization.
+Both companies plan on providing future extensions to improve MMU and hardware
+virtualization also.
+
+Linux has also recently gained a set of x86 virtualization enhancements. For
+the 2.6.20 kernel release, the \texttt{paravirt\_ops} interface and
+KVM driver were added. \texttt{paravirt\_ops} provides a common
+infrastructure for hooking portions of the Linux kernel that traditionally
+would prevent virtualization. The KVM driver adds the ability for Linux to
+run unmodified guests provided the underlying processor supports either AMD or
+Intel's CPU virtualization extensions.
+
+Currently, there are three consumers of the \texttt{paravirt\_ops} interface.
+Lguest\footnote{1}, a ``toy'' hypervisor designed to provide an example
+implementation, VMI\footnote{2}, which provides support for guests running
+under VMware, and XenoLinux\footnote{3}, which provides support for guests
+running under the Xen hypervisor.
\subsection {Linux as a Hypervisor}
-As of \texttt{2.6.21}, Linux will have the ability to virtualize
+As of \texttt{2.6.20}, Linux will have the ability to virtualize
itself using either hardware assistance (on newer processors), or
-paravirtualization (on existing and older processors). (Another option
-is a hybrid approach, which uses both paravirtualization and hardware
-assistance.)
+paravirtualization (on existing and older processors).
It is now interesting to compare Linux to existing hypervisors such as
VMware\footnote{\url{http://en.wikipedia.org/wiki/VMware}} and
@@ -38,7 +32,7 @@
questions include:
\begin{itemize}
-\item What level security and isolation does Linux provide among
+\item What level of security and isolation does Linux provide among
virtual guests?
\item What are the practical advantages and disadvantages of using
Linux as a hypervisor?
@@ -48,36 +42,20 @@
To begin answering these questions and others, we use Linux's
virtualization capabilities to get a Xen Linux kernel running as a
-guest within Linux itself. Or, we will run a Xen guest without Xen.
+guest within Linux itself.
The Xen hypervisor is now in several Linux distributions and forms the
-basis of two commercial hypervisors. Therefore the paravirtual kernel
+basis of two commercial hypervisors. Therefore, the paravirtual kernel
interface that Xen supports is a good proof point of completeness and
performance. If Linux can well support guests using a proven interface
such as Xen's, then Linux can be a practical hypervisor.
-To achieve this capability, we will a combination of Linux's
-current virtualization support and device emulation from
-QEMU\footnote{\url{http://fabrice.bellard.free.fr/qemu/}}:
-
-\begin{itemize}
-\item \texttt{lguest} as the guest/host context transition mechanism.
-\item \texttt{KVM} as the virtual machine monitor.
-\item QEMU as the userspace component to manage guests.
-\end{itemize}
-
-Along the way we will illustrate the techniques that \texttt{KVM} and
-\texttt{lguest} use to make Linux self-virtualizing. Finally, we will
-discuss what is missing today (both in our implementation and in
-Linux), and suggest some additional work.
-
\section{Virtualization and the x86 Platform}
Starting in late 2005 the historical shortcomings of the x86 platform
-with regard to virtualization are being remedied by Intel and AMD, but
-only for newer hardware. It will take another several years before
-most x86 platforms in the field have hardware virtualization
-support. There are two classes of problems:
+with regard to virtualization were remedied by Intel and AMD.
+t will take another several years before most x86 platforms in the field have
+hardware virtualization support. There are two classes of problems:
\begin{enumerate}
@@ -87,18 +65,15 @@
Pentium's Ability to Support a Secure Virtual Machine Monitor}. Proceedings of the 9th USENIX
Security Symposium, Denver, CO, August 2000.}
\item Performance issues that arise when multiple kernels are
-running on the platform, such as frequent flushing of Translation
-Lookaside Buffers (TLBs).
+running on the platform.
\end{enumerate}
Most of the work done by VMware and Xen, as well as the code in
Linux--\texttt{paravirt\_ops} and \texttt{lguest}-- is focused on overcoming
-these x86 shortcomings. Alternatively, KVM uses hardware support to
-overcome the need to trap privileged instructions. (More on that
-shortly.)
+these x86 shortcomings.
Performance issues caused by virtualization including TLB flushing,
-cache trashing, and the need for additional layers of memory
+cache thrashing, and the need for additional layers of memory
management are being addressed in current and future versions Intel
and AMD processors.
@@ -226,11 +201,11 @@
TLB hit rate is reduced significantly when x86 platforms are
virtualized.
-This problem can't be solved by simply increasing the size of the
+This problem cannot be solved by simply increasing the size of the
TLBs. Certain instructions force the TLBs to be flushed, including
-changing the address of the global page table by writing to control
-register 3. A hypervisor would prefer to change the global page table
-address every time it switches from guest to host mode, becuase doing
+changing the address of the page table by writing to control
+register 3. A hypervisor would prefer to change the page table
+address every time it switches from guest to host mode, because doing
so simplifies the transition code.
@@ -249,8 +224,8 @@
\textit{memory hole} immediately above the Linux kernel and resides in
that hole. To prevent the Linux kernel from having access to the
memory where the hypervisor is resident Xen uses segment limits on
-x86\_32 hardware. Hence the hypervisor is resident in mapped memory,
-but the Linux kernel can't gain access to hypervisor memory because it
+x86\_32 hardware. The hypervisor is resident in mapped memory,
+but the Linux kernel cannot gain access to hypervisor memory because it
is beyond the limit of the segment selectors used by the kernel. A
general representation of this layout is shown in Figure \ref{memoryhole}.
@@ -269,17 +244,13 @@
differently. \texttt{x86\_64}. Transitions from kernel to hypervisor
occur via the \texttt{syscall} instruction, which is available in
64-bit mode. \texttt{syscall} forces a change to segment selectors
-dropping the privilege level from 1 to 0, but leaves the global page
-directory at the same address. This allows the TLB to remain full most
-of the time.
+dropping the privilege level from 1 to 0.
There is no memory hole per se in 64-bit mode, because segment limits
are not universally enforced. An unfortunate consequence is that a
guest's userspace must have a different page table from the guests
-kernel. Therefore TLBs are flushed on a context switch from user to
-kernel mode, but not from guest (kernel) to host (hypervisor) mode. As
-a consequence, segment limits will likely be enforced on
-\texttt{x86\_64} processors in the future.
+kernel. Therefore the TLB is flushed on a context switch from user to
+kernel mode, but not from guest (kernel) to host (hypervisor) mode.
\subsection{Hypercalls}
@@ -296,9 +267,7 @@
Xen Hypercalls are similar to software interrupts. They pass
parameters in registers. 32-bit unprivileged guests in Xen, hypercalls
are executed using an \texttt{int} instruction. In 64-bit guests, they
-are executed using a \texttt{syscall} instruction. Figure
-\ref{back:hypercall} shows how to switch stacks by making a Xen
-hypercall.
+are executed using a \texttt{syscall} instruction.
\begin{figure*}
@@ -336,11 +305,6 @@
introspection that must occur. By working carefully with page tables
and processor caches hypercalls can be much faster than traps.
-In theory, once the guest-to-host transition structure is in place,
-Linux only needs to handle Xen hypercalls to run a Xen guest. In our
-implementation we use KVM as a scaffold upon which to hang Linux
-routines to handle Xen hypercalls.
-
\subsection{The \texttt{lguest} Monitor}
\texttt{lguest} implements a virtual machine monitor for Linux that
@@ -352,33 +316,24 @@
\texttt{lguest} uses the
\texttt{paravirt\_ops} interface to install trap handlers for the guest
-kernel that reflect back into \texttt{lguest} switching code. This is
-shown in Figure \ref{lguest}. To
+kernel that reflect back into \texttt{lguest} switching code. To
handle traps,
\texttt{lguest} switches to the host Linux kernel, which contains a
\texttt{paravirt\_ops} implementation to handle guest
-hypercalls. Switching to the Linux guest takes approximately 20
-instructions. We use the \texttt{lguest} switching code to
-transfer control from our Xen guest to the host Linux kernel.
-
-\begin{figure}[t]
-\input{lguest.epic}
-\caption{\texttt{lgeust} maps virtual devices and the monitor code
-above the kernel's memory. Traps are handled by the lguest utility,
-which can switch from the guest kernel to the host kernel in
-approximately 20 instructions.\label{lguest}}
-\end{figure}
+hypercalls.
\subsection{KVM}
-The AMD-V and Intel-VT instructions availible in newer processors provide a
-general structure for handling host faults. Upon a fault, the guest
-executes instructions that transfers control back to the host (this
-psuedo instruction is typically called a \texttt{vmexit}). Information
-about the guest and the fault, as well as the processor's guest-mode
-context, is avaible to the host. The host then switches on the reason
-for the \texttt{vmexit}. This structure is clearly visible in KVM's
-\texttt{vmexit} handler.
-
-We use KVM's \texttt{vmexit} handler as a scaffold on which to hang
-our Xen hypercall service routines.
+The AMD-V and Intel-VT instructions available in newer processors provides a
+mechanism to force the processor to trap on certain sensitive instructions even
+if the processor is running in privileged mode. The processor uses a special
+data area known as the VMCB or VMCS on AMD and Intel respectively, to determine
+which instructions to trap and how the trap should be delivered. When a VMCB
+or VMCS is being used, the processor is considered to be in guest mode. KVM
+programs the VMCB or VMCS to deliver sensitive instruction traps back into host
+mode. KVM uses information provided in the VMCB and VMCS to determine why the
+guest trapped and emulates the instruction appropriately.
+
+Since this technique does not require any modifications to the guest
+operating system, it can be used to run any x86 operating that runs on a normal
+processor.