--- our_work.tex.orig 2007-04-07 21:22:53.000000000 -0500
+++ our_work.tex 2007-04-07 21:25:07.000000000 -0500
@@ -2,11 +2,11 @@
Running a Xen guest on Linux without the Xen hypervisor present requires a
couple of basic capabilities. First, we need to be able to load a Xen guest
-into memory. Second, we have to initialize Xen compatible start-of-day
-environment. Last, Linux needs to be able to switch between running the guest
-as well as support handling the guests page tables. For the purposes of this
+into memory. Second, we have to initialize of Xen compatible start-of-day
+environment. Lastly, Linux needs to be able to switch between running the guest
+as well as to support handling the guests page tables. For the purposes of this
paper we are not addressing virtual IO, nor SMP, however we do implement a
-simple console device. We discuss these features Section X (future work). We
+simple console device. We discuss these features in Section X (future work). We
expand on our choice of using QEMU as our mechanism to load and initialize the
guest for running XenoLinux in Section X.2. Using Lguest as switching mechanism
and tracking guest state is explained in Section X.3. Section X.4 describes
@@ -14,7 +14,7 @@
VM's page tables. The virtual console mechanism is explained in Section X.5.
Finally we describe the limitations of our implementation in Section X.6
-\subsection {QEMU and Machine types}
+\subsection {QEMU and Machine Types}
\begin{figure}[t]
\input{kvm_xen.epic}
@@ -29,13 +29,13 @@
architecture and emulates a floppy controller, RTC, PIT, IOAPIC, PCI bus, VGA,
serial, parallel, network, USB, and IDE disk devices.
-A paravirtualized Xen kernel can be treated as new QEMU machine type.
+A paravirtualized Xen guest can be treated as new QEMU machine type.
Specifically it is a 32-bit cpu which only executes code at ring 1 and contains
no devices. In addition to being able to define which devices are to be
emulated on a QEMU machine type we can also control the initial machine
state. This is quite useful as Xen's start-of-day assumptions are not the
same as a traditional 32-bit x86 platform. In the end, the QEMU Xen machine
-type can be characterized as an eccentric x86 platform doesn't run code in
+type can be characterized as an eccentric x86 platform that does not run code in
ring 0 nor has any hardware besides the cpu.
Paravirtualized kernels, like XenoLinux, are built specifically to be
@@ -46,7 +46,7 @@
control between the host and the guest. Lguest provides a simple mechanism for
such transitions as we explain below.
-\subsection {Lguest monitor and hypercalls}
+\subsection {Lguest Monitor and Hypercalls}
Lguest is a simple x86 paravirtual hypervisor designed to exercise the
\texttt{paravirt\_ops} interface in Linux \texttt{2.6.20}. No hypercalls are
@@ -113,19 +113,19 @@
\subsection {Virtual Console}
-The virtual console as expected buy a XenoLinux guest is a simple ring queue.
+The virtual console as expected by a XenoLinux guest is a simple ring queue.
Xen guests expect a reference to a page of memory shared between the guest and
-the host and an Xen event channel number. The QEMU Xen machine type allocates a
+the host and a Xen event channel number. The QEMU Xen machine type allocates a
page of the guests memory, selects an event channel and initialize the XenoLinux
start-of-date with these values.
During the guest booting process it will start writing console output to the
shared page and issue a hypercall to notify the host of a pending event.
-After control is transferred from the guest QEMU Xen machine examines which
-event was triggered. For console events, QEMU Xen machine reads data from the
+After control is transferred from the guest, the QEMU Xen machine examines which
+event was triggered. For console events, the QEMU Xen machine reads data from the
ring queue on the shared page, increments the read index pointer and notifies the
guest that it received the message via the event channel bitmap which generates
-and interrupt in the guest upon returning from the host. The data read from and
+an interrupt in the guest upon returning from the host. The data read from and
written to the shared console page is connected to a QEMU character device.
QEMU exposes the character devices to users in many different ways including
telnet, unix socket, pty, tcp socket. In a similar manner, any writes to QEMU
@@ -134,11 +134,11 @@
\subsection {Current restriction}
-The current implementation for running Xen guests ontop of Linux via KVM
-supports 32-bit UP guests. We've not attempted to implement any of the
+The current implementation for running Xen guests on top of Linux via KVM
+supports 32-bit UP guests. We have not attempted to implement any of the
infrastructure required for virtual IO beyond simple console support.
Additionally, while using Lguest's hypervisor simplified our initial work, we do
-inheirit the requirement that the top 4 megabytes of virtual address space be
+inherit the requirement that the top 4 megabytes of virtual address space be
available on the host. We discuss virtual IO and SMP issues as future work in
Section X.