ia64/xen-unstable

changeset 2857:ab134f4d418d

bitkeeper revision 1.1159.1.355 (418920ffn3zTKtkKJJOohQgRtQD2KQ)

Merge ssh://srg//auto/groups/xeno/BK/xeno.bk
into equilibrium.research:/export/scratch/xeno-docs.bk
author mwilli2@equilibrium.research
date Wed Nov 03 18:18:39 2004 +0000 (2004-11-03)
parents 1cacaf908d8b 82a6612c741f
children fb24f726e556
files docs/src/user.tex
line diff
     1.1 --- a/docs/src/user.tex	Wed Nov 03 17:16:34 2004 +0000
     1.2 +++ b/docs/src/user.tex	Wed Nov 03 18:18:39 2004 +0000
     1.3 @@ -56,13 +56,13 @@ Contributions of material, suggestions a
     1.4  \renewcommand{\floatpagefraction}{.8}
     1.5  \setstretch{1.1}
     1.6  
     1.7 -\newcommand{\path}[1]{{\tt #1}}
     1.8 +\newcommand{\path}[1]{{\small {\tt #1}}}
     1.9  
    1.10  
    1.11  \part{Introduction and Tutorial}
    1.12  \chapter{Introduction}
    1.13  
    1.14 -Xen is a { \em paravirtualising } virtual machine monitor (VMM), or
    1.15 +Xen is a {\em paravirtualising} virtual machine monitor (VMM), or
    1.16  `hypervisor', for the x86 processor architecture.  Xen can securely
    1.17  execute multiple virtual machines on a single physical system with
    1.18  close-to-native performance.  The virtual machine technology
    1.19 @@ -171,7 +171,7 @@ multiple independent clients to run thei
    1.20  applications in an environment providing protection, resource
    1.21  isolation and accounting.  The project web page contains further
    1.22  information along with pointers to papers and technical reports:
    1.23 -{\tt http://www.cl.cam.ac.uk/xeno}
    1.24 +{\small {\tt http://www.cl.cam.ac.uk/xeno}}
    1.25  
    1.26  Xen has since grown into a fully-fledgd project in its own right,
    1.27  enabling us to investigate interesting research issues regarding the
    1.28 @@ -291,52 +291,61 @@ following:
    1.29        unprivileged virtual machines.
    1.30  \end{itemize}
    1.31  
    1.32 -Inspect the Makefile if you want to see what goes on during a build.
    1.33 -Building Xen and the tools is straightforward, but XenLinux is more
    1.34 -complicated.  The makefile needs a `pristine' Linux kernel tree to which
    1.35 -it will then add the Xen architecture files.  You can tell the
    1.36 -makefile the location of the appropriate Linux compressed tar file by
    1.37 -setting the LINUX\_SRC environment variable, e.g. \\
    1.38 -\verb!# LINUX_SRC=/tmp/linux-2.6.9.tar.bz2 make world! \\ or by
    1.39 -placing the tar file somewhere in the search path of {\tt
    1.40 -LINUX\_SRC\_PATH} which defaults to `{\tt .:..}'.  If the makefile
    1.41 -can't find a suitable kernel tar file it attempts to download it from
    1.42 -kernel.org (this won't work if you're behind a firewall).
    1.43 +%% Inspect the Makefile if you want to see what goes on during a build.
    1.44 +%% Building Xen and the tools is straightforward, but XenLinux is more
    1.45 +%% complicated.  The makefile needs a `pristine' Linux kernel tree to which
    1.46 +%% it will then add the Xen architecture files.  You can tell the
    1.47 +%% makefile the location of the appropriate Linux compressed tar file by
    1.48 +%% setting the LINUX\_SRC environment variable, e.g. \\
    1.49 +%% \verb!# LINUX_SRC=/tmp/linux-2.6.9.tar.bz2 make world! \\ or by
    1.50 +%% placing the tar file somewhere in the search path of {\tt
    1.51 +%% LINUX\_SRC\_PATH} which defaults to `{\tt .:..}'.  If the makefile
    1.52 +%% can't find a suitable kernel tar file it attempts to download it from
    1.53 +%% kernel.org (this won't work if you're behind a firewall).
    1.54  
    1.55 -After untaring the pristine kernel tree, the makefile uses the {\tt
    1.56 -mkbuildtree} script to add the Xen patches to the kernel.  It then
    1.57 -builds two different XenLinux images, one with a `-xen0' extension
    1.58 +%% After untaring the pristine kernel tree, the makefile uses the {\tt
    1.59 +%% mkbuildtree} script to add the Xen patches to the kernel. 
    1.60 +
    1.61 +After the build has completed you should have a top-level 
    1.62 +directory called {\tt dist/} in which all resulting targets 
    1.63 +will be placed; of particular interest are the two kernels 
    1.64 +XenLinux kernel images, one with a `-xen0' extension
    1.65  which contains hardware device drivers and drivers for Xen's virtual
    1.66  devices, and one with a `-xenU' extension that just contains the
    1.67 -virtual ones.
    1.68 +virtual ones. These are found in \path{dist/install/boot/} along
    1.69 +with the image for Xen itself and the configuration files used
    1.70 +during the build. 
    1.71  
    1.72 -The procedure is similar to build the Linux 2.4 port: \\
    1.73 -\verb!# LINUX_SRC=/path/to/linux2.4/source make linux24!
    1.74 +%% The procedure is similar to build the Linux 2.4 port: \\
    1.75 +%% \verb!# LINUX_SRC=/path/to/linux2.4/source make linux24!
    1.76  
    1.77 -The NetBSD port can be built using: \\ \verb!# make netbsd! \\ The
    1.78 +The NetBSD port can be built using: \\ \verb!# make netbsd20! \\ The
    1.79  NetBSD port is built using a snapshot of the netbsd-2-0 cvs branch.
    1.80  The snapshot is downloaded as part of the build process, if it is not
    1.81  yet present in the {\tt NETBSD\_SRC\_PATH} search path.  The build
    1.82  process also downloads a toolchain which includes all the tools
    1.83  necessary to build the NetBSD kernel under Linux.
    1.84  
    1.85 -If you have an SMP machine you may wish to give the {\tt '-j4'}
    1.86 -argument to make to get a parallel build.
    1.87 +% If you have an SMP machine you may wish to give the {\tt '-j4'}
    1.88 +% argument to make to get a parallel build.
    1.89 +
    1.90  
    1.91  If you have an existing Linux kernel configuration that you would like
    1.92  to use for domain 0, you should copy it to
    1.93 -install/boot/config-2.6.9-xen0.  During the first build, you may be
    1.94 -asked about some Xen-specific options.  We advise accepting the
    1.95 -defaults for these options.
    1.96 +\path{dist/install/boot/config-2.6.9-xen0}; for example, certain
    1.97 +distributions require a kernel with either {\tt udev} or {\tt devfs}
    1.98 +support at boot time.  During the first build, you may be prompted with
    1.99 +some Xen-specific options.  We advise accepting the defaults for
   1.100 +these options.
   1.101  
   1.102 -\framebox{\parbox{5in}{
   1.103 -{\bf Distro specific:} \\
   1.104 -{\it Gentoo} --- if not using udev (most installations, currently), you'll need
   1.105 -to enable devfs and devfs mount at boot time in the xen0 config.
   1.106 -}}
   1.107 +%% \framebox{\parbox{5in}{
   1.108 +%% {\bf Distro specific:} \\
   1.109 +%% {\it Gentoo} --- if not using udev (most installations, currently), you'll need
   1.110 +%% to enable devfs and devfs mount at boot time in the xen0 config.
   1.111 +%% }}
   1.112  
   1.113  The files produced by the build process are stored under the
   1.114 -\path{install/} directory.  To install them in their default
   1.115 +\path{dist/install/} directory.  To install them in their default
   1.116  locations, do: \\
   1.117  \verb_# make install_
   1.118  
   1.119 @@ -344,12 +353,12 @@ Alternatively, users with special instal
   1.120  to install them manually by copying the files to their appropriate
   1.121  destinations.
   1.122  
   1.123 -Files in \path{install/boot/} include:
   1.124 -\begin{itemize}
   1.125 -\item \path{install/boot/xen.gz} The Xen 'kernel'
   1.126 -\item \path{install/boot/vmlinuz-2.6.9-xen0}  Domain 0 XenLinux kernel
   1.127 -\item \path{install/boot/vmlinuz-2.6.9-xenU}  Unprivileged XenLinux kernel
   1.128 -\end{itemize}
   1.129 +%% Files in \path{install/boot/} include:
   1.130 +%% \begin{itemize}
   1.131 +%% \item \path{install/boot/xen.gz} The Xen 'kernel'
   1.132 +%% \item \path{install/boot/vmlinuz-2.6.9-xen0}  Domain 0 XenLinux kernel
   1.133 +%% \item \path{install/boot/vmlinuz-2.6.9-xenU}  Unprivileged XenLinux kernel
   1.134 +%% \end{itemize}
   1.135  
   1.136  The difference between the two Linux kernels that are built is due to
   1.137  the configuration file used for each.  The "U" suffixed unprivileged
   1.138 @@ -359,7 +368,7 @@ non-privileged domains.  The `0' suffixe
   1.139  used to boot the system, as well as in driver domains and unprivileged
   1.140  domains.
   1.141  
   1.142 -The \path{install/boot} directory will also contain the config files
   1.143 +The \path{dist/install/boot} directory will also contain the config files
   1.144  used for building the XenLinux kernels, and also versions of Xen and
   1.145  XenLinux kernels that contain debug symbols (\path{xen-syms} and
   1.146  \path{vmlinux-syms-2.6.9-xen0}) which are essential for interpreting crash
   1.147 @@ -368,6 +377,9 @@ you post on the mailing list.
   1.148  
   1.149  \section{Configuration}
   1.150  
   1.151 +Once you have built and installed the Xen distribution, it is 
   1.152 +simple to prepare the machine for booting and running Xen. 
   1.153 +
   1.154  \subsection{GRUB Configuration}
   1.155  
   1.156  An entry should be added to \path{grub.conf} (often found under
   1.157 @@ -375,62 +387,97 @@ An entry should be added to \path{grub.c
   1.158  This file is sometimes called \path{menu.lst}, depending on your
   1.159  distribution.  The entry should look something like the following:
   1.160  
   1.161 +{\small
   1.162  \begin{verbatim}
   1.163  title Xen 2.0 / XenLinux 2.6.9
   1.164 -  kernel /boot/xen.gz dom0_mem=131072 com1=115200,8n1
   1.165 -  module /boot/vmlinuz-2.6.9-xen0 root=/dev/sda4 ro console=tty0 console=ttyS0
   1.166 +  kernel /boot/xen.gz dom0_mem=131072
   1.167 +  module /boot/vmlinuz-2.6.9-xen0 root=/dev/sda4 ro console=tty0
   1.168  \end{verbatim}
   1.169 +}
   1.170  
   1.171 -The first line of the configuration (kernel...) tells GRUB where to
   1.172 -find Xen itself and what boot parameters should be passed to it (in
   1.173 -this case, setting domain 0's memory allocation and the settings for
   1.174 -the serial port).
   1.175 +The kernel line tells GRUB where to find Xen itself and what boot
   1.176 +parameters should be passed to it (in this case, setting domain 0's
   1.177 +memory allocation and the settings for the serial port). For more
   1.178 +details on the various Xen boot parameters see Section~\ref{s:xboot}. 
   1.179  
   1.180 -The second line of the configuration describes the location of the
   1.181 +The module line of the configuration describes the location of the
   1.182  XenLinux kernel that Xen should start and the parameters that should
   1.183  be passed to it (these are standard Linux parameters, identifying the
   1.184  root device and specifying it be initially mounted read only and
   1.185  instructing that console output be sent both to the screen and to the
   1.186 -serial port).
   1.187 +serial port). Some distributions such as SUSE do not require the 
   1.188 +{\small {\tt ro}} parameter. 
   1.189  
   1.190 -If you want to use an initrd, just add another {\tt module} line to
   1.191 +%% \framebox{\parbox{5in}{
   1.192 +%% {\bf Distro specific:} \\
   1.193 +%% {\it SuSE} --- Omit the {\tt ro} option from the XenLinux kernel
   1.194 +%% command line, since the partition won't be remounted rw during boot.
   1.195 +%% }}
   1.196 +
   1.197 +
   1.198 +If you want to use an initrd, just add another {\small {\tt module}} line to
   1.199  the configuration, as usual:
   1.200 +{\small
   1.201  \begin{verbatim}
   1.202    module /boot/my_initrd.gz
   1.203  \end{verbatim}
   1.204 +}
   1.205  
   1.206  As always when installing a new kernel, it is recommended that you do
   1.207 -not remove the original contents of \path{menu.lst} --- you may want
   1.208 -to boot up with your old Linux kernel in future, particularly if you
   1.209 +not delete existing menu options from \path{menu.lst} --- you may want
   1.210 +to boot your old Linux kernel in future, particularly if you
   1.211  have problems.
   1.212  
   1.213 -\framebox{\parbox{5in}{
   1.214 -{\bf Distro specific:} \\
   1.215 -{\it SuSE} --- Omit the {\tt ro} option from the XenLinux kernel
   1.216 -command line, since the partition won't be remounted rw during boot.
   1.217 -}}
   1.218 +
   1.219 +\subsection{Serial Console (optional)}
   1.220 +
   1.221 +%%   kernel /boot/xen.gz dom0_mem=131072 com1=115200,8n1
   1.222 +%%   module /boot/vmlinuz-2.6.9-xen0 root=/dev/sda4 ro 
   1.223 +
   1.224 +
   1.225 +In order to configure Xen serial console output, it is necessary to add 
   1.226 +an boot option to your GRUB config; e.g. replace the above kernel line 
   1.227 +with: 
   1.228 +\begin{quote}
   1.229 +{\small
   1.230 +\begin{verbatim}
   1.231 +   kernel /boot/xen.gz dom0_mem=131072 com1=115200,8n1
   1.232 +\end{verbatim}}
   1.233 +\end{quote} 
   1.234  
   1.235 -\subsection{Serial Console}
   1.236 +This configures Xen to output on COM1 at 115,200 baud, 8 data bits, 
   1.237 +1 stop bit and no parity. Modify these parameters for your set up. 
   1.238 +
   1.239 +One can also configure XenLinux to share the serial console; to 
   1.240 +achieve this append ``\path{console=ttyS0}'' to your 
   1.241 +module line. 
   1.242 +
   1.243  
   1.244 -In order to configure serial console output, it is necessary to add a
   1.245 -line into \path{/etc/inittab}.  The XenLinux console driver is
   1.246 -designed to make this procedure the same as configuring a normal
   1.247 -serial console.  Add the line:
   1.248 +If you wish to be able to log in over the XenLinux serial console it
   1.249 +is necessary to add a line into \path{/etc/inittab}, just as per 
   1.250 +regular Linux. Simply add the line:
   1.251 +\begin{quote}
   1.252 +{\small 
   1.253 +{\tt c:2345:respawn:/sbin/mingetty ttyS0}
   1.254 +}
   1.255 +\end{quote} 
   1.256  
   1.257 -{\tt c:2345:respawn:/sbin/mingetty ttyS0}
   1.258 +and you should be able to log in. Note that to successfully log in 
   1.259 +as root over the serial will require adding \path{ttyS0} to
   1.260 +\path{/etc/securetty} in most modern distributions. 
   1.261  
   1.262  \subsection{TLS Libraries}
   1.263  
   1.264  Users of the XenLinux 2.6 kernel should disable Thread Local Storage
   1.265 -(e.g. by doing a {\tt mv /lib/tls /lib/tls.disabled}) before
   1.266 +(e.g. by doing a {\small {\tt mv /lib/tls /lib/tls.disabled}}) before
   1.267  attempting to run with a XenLinux kernel.  You can always reenable it
   1.268 -by restoring the directory to its original location (i.e. {\tt mv
   1.269 -  /lib/tls.disabled /lib/tls}).
   1.270 +by restoring the directory to its original location (i.e. {\small 
   1.271 +{\tt mv /lib/tls.disabled /lib/tls}}).
   1.272  
   1.273 -The TLS implementation uses segmentation in a way that is not
   1.274 -permissable under Xen.  If TLS is not disabled, an emulation mode is
   1.275 -used within Xen which reduces performance substantially and is not
   1.276 -guaranteed to work perfectly.
   1.277 +The reason for this is that the current TLS implementation uses
   1.278 +segmentation in a way that is not permissable under Xen.  If TLS is
   1.279 +not disabled, an emulation mode is used within Xen which reduces
   1.280 +performance substantially and is not guaranteed to work perfectly.
   1.281  
   1.282  \section{Test the new install}
   1.283  
   1.284 @@ -513,7 +560,7 @@ variables in \path{/etc/xen/xmdefconfig}
   1.285                with Xen. [e.g. {\tt kernel =
   1.286                '/root/xen-2.0.bk/install/boot/vmlinuz-2.4.27-xenU'}]
   1.287  \item[memory] Set this to the size of the domain's memory in
   1.288 -megabytes. [e.g. {\tt memory = 64 } ]
   1.289 +megabytes. [e.g. {\tt memory = 64} ]
   1.290  \item[disk] Set the first entry in this list to calculate the offset
   1.291  of the domain's root partition, based on the domain ID.  Set the
   1.292  second to the location of \path{/usr} (if you are sharing it between
   1.293 @@ -712,7 +759,7 @@ To perform a live migration, both hosts 
   1.294  the destination host must have sufficient resources (e.g. memory
   1.295  capacity) to accommodate the domain after the move.
   1.296  
   1.297 -A domain may be migrated using the {\tt xm migrate } command.  To
   1.298 +A domain may be migrated using the {\tt xm migrate} command.  To
   1.299  migrate the example ttylinux domain to another machine, we would use
   1.300  the command:
   1.301  
   1.302 @@ -888,6 +935,10 @@ docs to do advanced stuff.
   1.303  
   1.304  \chapter{Control Software} 
   1.305  
   1.306 +The Xen control software includes the \xend node control daemon (which 
   1.307 +must be running), the xm command line tools, and the prototype 
   1.308 +xensv web interface. 
   1.309 +
   1.310  \section{\Xend (Node control daemon)}
   1.311  \label{s:xend}
   1.312  
   1.313 @@ -904,7 +955,7 @@ management functions.  A small set of co
   1.314  \verb!# xend start! & start \xend, if not already running \\
   1.315  \verb!# xend stop!  & stop \xend if already running       \\
   1.316  \verb!# xend restart! & restart \xend if running, otherwise start it \\
   1.317 -\verb!# xend trace_start! & start \xend, with very detailed debug logging \\
   1.318 +% \verb!# xend trace_start! & start \xend, with very detailed debug logging \\
   1.319  \verb!# xend status! & indicates \xend status by its return code
   1.320  \end{tabular}
   1.321  
   1.322 @@ -927,7 +978,7 @@ The general format of an xm command line
   1.323  # xm command [switches] [arguments] [variables]
   1.324  \end{verbatim}
   1.325  
   1.326 -The available {\em switches } and {\em arguments} are dependent on the
   1.327 +The available {\em switches} and {\em arguments} are dependent on the
   1.328  {\em command} chosen.  The {\em variables} may be set using
   1.329  declarations of the form {\tt variable=value} and command line
   1.330  declarations override any of the values in the configuration file
   1.331 @@ -962,10 +1013,11 @@ The available commands are as follows:
   1.332  
   1.333  For a detailed overview of switches, arguments and variables to each command
   1.334  try
   1.335 +\begin{quote}
   1.336  \begin{verbatim}
   1.337  # xm help command
   1.338  \end{verbatim}
   1.339 -
   1.340 +\end{quote}
   1.341  
   1.342  \section{Xensv (Web control interface)}
   1.343  \label{s:xensv}
   1.344 @@ -991,24 +1043,27 @@ manage running domains.
   1.345  \chapter{Domain Configuration}
   1.346  \label{cha:config}
   1.347  
   1.348 +The following contains the syntax of the domain configuration 
   1.349 +files and description of how to further specify networking, 
   1.350 +driver domain and general scheduling behaviour. 
   1.351  
   1.352  \section{Configuration Files}
   1.353  \label{s:cfiles}
   1.354  
   1.355  Xen configuration files contain the following standard variables.
   1.356  Unless otherwise stated, configuration items should be enclosed in
   1.357 -quotes (i.e. {\tt '...'} or {\tt ``....''})):
   1.358 +quotes: see \path{/etc/xen/xmexample1} for an example. 
   1.359  
   1.360  \begin{description}
   1.361 -\item[kernel] Path to the kernel image (on the server).
   1.362 +\item[kernel] Path to the kernel image 
   1.363  \item[ramdisk] Path to a ramdisk image (optional).
   1.364  % \item[builder] The name of the domain build function (e.g. {\tt'linux'} or {\tt'netbsd'}.
   1.365  \item[memory] Memory size in megabytes.
   1.366 -\item[cpu] CPU to assign this domain to.
   1.367 +\item[cpu] CPU to run this domain on, or {\tt -1} for
   1.368 +  auto-allocation. 
   1.369  \item[nics] Number of virtual network interfaces.
   1.370  \item[vif] List of MAC addresses (random addresses are assigned if not
   1.371 -  given) and / or bridges to use for the domains network
   1.372 -  interfaces. e.g.
   1.373 +  given) and bridges to use for the domain's network interfaces, e.g.
   1.374  \begin{verbatim}
   1.375  vif = [ 'mac=aa:00:00:00:00:11, bridge=xen-br0',
   1.376          'bridge=xen-br1' ]
   1.377 @@ -1016,29 +1071,27 @@ vif = [ 'mac=aa:00:00:00:00:11, bridge=x
   1.378    to assign a MAC address and bridge to the first interface and assign
   1.379    a different bridge to the second interface, leaving \xend to choose
   1.380    the MAC address.
   1.381 -\item[disk] List of block devices to export to the domain.  e.g. \\
   1.382 +\item[disk] List of block devices to export to the domain,  e.g. \\
   1.383    \verb_disk = [ 'phy:hda1,sda1,r' ]_ \\
   1.384 -  exports device \path{/dev/hda1} to the domain, as \path{/dev/sda1} with
   1.385 -  readonly access being allowed. \\
   1.386 -  \verb_disk = [ 'phy:hda7,sda2,w', 'phy:hdb2,sda,w!' ]_ \\
   1.387 -  exports device \path{/dev/hda7} to the domain as \path{/dev/sda2} with
   1.388 -  write access enabled and \path{/dev/hdb2} as \path{/dev/sda} with write access
   1.389 -  force enabled (bypassing safety checks, as indicated by the {\tt !}).
   1.390 -\item[dhcp] Set to {\tt 'dhcp'} if you want to DHCP allocate the IP
   1.391 -address.
   1.392 -\item[netmask] IP netmask.
   1.393 -\item[gateway] IP address for the gateway (if any).
   1.394 +  exports physical device \path{/dev/hda1} to the domain 
   1.395 +  as \path{/dev/sda1} with read-only access. 
   1.396 +\item[dhcp] Set to {\tt 'dhcp'} if you want to use DHCP to configure
   1.397 +  networking. 
   1.398 +\item[netmask] Manually configured IP netmask.
   1.399 +\item[gateway] Manually configured IP gateway. 
   1.400  \item[hostname] Set the hostname for the virtual machine.
   1.401 -\item[root] Set the root device.
   1.402 -\item[nfs\_server] IP address for the NFS server.
   1.403 -\item[nfs\_root] Path of the root filesystem on the NFS server.
   1.404 -\item[extra] Extra string to append to the kernel command line.
   1.405 +\item[root] Specify the root device parameter on the kernel command
   1.406 +  line. 
   1.407 +\item[nfs\_server] IP address for the NFS server (if any). 
   1.408 +\item[nfs\_root] Path of the root filesystem on the NFS server (if any).
   1.409 +\item[extra] Extra string to append to the kernel command line (if
   1.410 +  any) 
   1.411  \item[restart] Three possible options:
   1.412    \begin{description}
   1.413    \item[always] Always restart the domain, no matter what
   1.414                  its exit code is.
   1.415    \item[never]  Never restart the domain.
   1.416 -  \item[onreboot] (restart the domain if it requests reboot).
   1.417 +  \item[onreboot] Restart the domain iff it requests reboot.
   1.418    \end{description}
   1.419  \end{description}
   1.420  
   1.421 @@ -1051,162 +1104,48 @@ scripting commands in configuration file
   1.422  
   1.423  \section{Network Configuration}
   1.424  
   1.425 -For simple systems with a single ethernet interface with a simple
   1.426 -configuration, the default installation should work `out of the
   1.427 -box'.  More complicated network setups, for instance with multiple
   1.428 -ethernet interfaces and / or existing bridging setups will require
   1.429 -some special configuration.
   1.430 +For many users, the default installation should work `out of the box'.
   1.431 +More complicated network setups, for instance with multiple ethernet
   1.432 +interfaces and/or existing bridging setups will require some
   1.433 +special configuration.
   1.434  
   1.435 -The purpose of this chapter is to describe the mechanisms provided by
   1.436 +The purpose of this section is to describe the mechanisms provided by
   1.437  \xend to allow a flexible configuration for Xen's virtual networking.
   1.438  
   1.439  \subsection{Xen networking scripts}
   1.440  
   1.441 -Xen's virtual networking is configured by 3 shell scripts.  These are
   1.442 -called automatically by \xend when certain events occur, with arguments
   1.443 -to the scripts providing further contextual information.  These
   1.444 -scripts are found by default in \path{/etc/xen}.  The names and
   1.445 -locations of the scripts can be configured in \path{xend-config.sxp}.
   1.446 -
   1.447 -\subsubsection{\path{network}}
   1.448 -
   1.449 -This script is called once when \xend is started and once when \xend is
   1.450 -stopped.  Its job is to do any advance preparation required for the
   1.451 -Xen virtual network when \xend starts and to do any corresponding
   1.452 -cleanup when \xend exits.
   1.453 -
   1.454 -In the default configuration, this script creates the bridge
   1.455 -`xen-br0' and moves eth0 onto that bridge, modifying the routing
   1.456 -accordingly.
   1.457 -
   1.458 -In configurations where the bridge already exists, this script could
   1.459 -be replaced with a link to \path{/bin/true} (for instance).
   1.460 -
   1.461 -When \xend exits, this script is called with the {\tt stop} argument,
   1.462 -which causes it to delete the Xen bridge and remove {\tt eth0} from
   1.463 -it, restoring the normal IP and routing configuration.
   1.464 -
   1.465 -\subsubsection{\path{vif-bridge}}
   1.466 -
   1.467 -This script is called for every domain virtual interface.  This should
   1.468 -do things like configuring firewalling rules for that interface and
   1.469 -adding it to the appropriate bridge.
   1.470 -
   1.471 -By default, this adds and removes VIFs on the default Xen bridge.
   1.472 -This script can be customized to properly deal with more complicated
   1.473 -bridging setups.
   1.474 +Xen's virtual networking is configured by two shell scripts (by
   1.475 +default \path{network} and \path{vif-bridge}).  These are
   1.476 +called automatically by \xend when certain events occur, with
   1.477 +arguments to the scripts providing further contextual information.
   1.478 +These scripts are found by default in \path{/etc/xen/scripts}.  The
   1.479 +names and locations of the scripts can be configured in
   1.480 +\path{/etc/xen/xend-config.sxp}.
   1.481  
   1.482 -\section{Scheduler Configuration}
   1.483 -
   1.484 -\subsection{Scheduler selection}
   1.485 -
   1.486 -Xen offers a boot time choice between multiple schedulers.  To select
   1.487 -a scheduler, pass the boot parameter { \tt sched=sched\_name } to Xen,
   1.488 -substituting the appropriate scheduler name.  Details of the schedulers
   1.489 -and their parameters are included below; future versions of the tools
   1.490 -will provide a higher-level interface to these tools.
   1.491 -
   1.492 -It is expected that system administrators configure their system to
   1.493 -use the scheduler most appropriate to their needs.  Currently, the BVT
   1.494 -scheduler is the recommended choice, since the Atropos scheduler is
   1.495 -not finished.
   1.496 -
   1.497 -\subsection{Borrowed Virtual Time}
   1.498 -
   1.499 -{\tt sched=bvt } (the default) \\ 
   1.500 -
   1.501 -BVT provides proportional fair shares of the CPU time.  It has been
   1.502 -observed to penalise domains that block frequently (e.g. IO intensive
   1.503 -domains), but this can be compensated by using warping. 
   1.504 -
   1.505 -\subsubsection{Global Parameters}
   1.506 -
   1.507 -\begin{description}
   1.508 -\item[ctx\_allow]
   1.509 -  the context switch allowance is similar to the "quantum"
   1.510 -  in traditional schedulers.  It is the minimum time that
   1.511 -  a scheduled domain will be allowed to run before being
   1.512 -  pre-empted.  This prevents thrashing of the CPU.
   1.513 -\end{description}
   1.514 -
   1.515 -\subsubsection{Per-domain parameters}
   1.516 +\begin{description} 
   1.517  
   1.518 -\begin{description}
   1.519 -\item[mcuadv]
   1.520 -  the MCU (Minimum Charging Unit) advance determines the
   1.521 -  proportional share of the CPU that a domain receives.  It
   1.522 -  is set inversely proportionally to a domain's sharing weight.
   1.523 -\item[warp]
   1.524 -  the amount of "virtual time" the domain is allowed to warp
   1.525 -  backwards
   1.526 -\item[warpl]
   1.527 -  the warp limit is the maximum time a domain can run warped for
   1.528 -\item[warpu]
   1.529 -  the unwarp requirement is the minimum time a domain must
   1.530 -  run unwarped for before it can warp again
   1.531 -\end{description}
   1.532 -
   1.533 -\subsection{Atropos}
   1.534 -
   1.535 -{\tt sched=atropos } \\
   1.536 -
   1.537 -Atropos is a Soft Real Time scheduler.  It provides guarantees about
   1.538 -absolute shares of the CPU (with a method for optionally sharing out
   1.539 -slack CPU time on a best-effort basis) and can provide timeliness
   1.540 -guarantees for latency-sensitive domains.
   1.541 -
   1.542 -Every domain has an associated period and slice.  The domain should
   1.543 -receive 'slice' nanoseconds every 'period' nanoseconds.  This allows
   1.544 -the administrator to configure both the absolute share of the CPU a
   1.545 -domain receives and the frequency with which it is scheduled.  When
   1.546 -domains unblock, their period is reduced to the value of the latency
   1.547 -hint (the slice is scaled accordingly so that they still get the same
   1.548 -proportion of the CPU).  For each subsequent period, the slice and
   1.549 -period times are doubled until they reach their original values.
   1.550 +\item[network:] This script is called whenever \xend is started or
   1.551 +stopped to respectively initialize or tear down the Xen virtual
   1.552 +network. In the default configuration initialization creates the
   1.553 +bridge `xen-br0' and moves eth0 onto that bridge, modifying the
   1.554 +routing accordingly. When \xend exits, it deletes the Xen bridge and
   1.555 +removes eth0, restoring the normal IP and routing configuration.
   1.556  
   1.557 -Note: don't overcommit the CPU when using Atropos (i.e. don't reserve
   1.558 -more CPU than is available - the utilisation should be kept to
   1.559 -slightly less than 100% in order to ensure predictable behaviour).
   1.560 -
   1.561 -\subsubsection{Per-domain parameters}
   1.562 +%% In configurations where the bridge already exists, this script could
   1.563 +%% be replaced with a link to \path{/bin/true} (for instance).
   1.564  
   1.565 -\begin{description}
   1.566 -\item[slice]
   1.567 -  The length of time per period that a domain is guaranteed.
   1.568 -\item[period]
   1.569 -  The period over which a domain is guaranteed to receive
   1.570 -  its slice of CPU time.
   1.571 -\item[latency]
   1.572 -  The latency hint is used to control how soon after
   1.573 -  waking up a domain should be scheduled.
   1.574 -\item[xtratime]
   1.575 -  This is a true (1) / false (0) flag that specifies whether
   1.576 -  a domain should be allowed a share of the system slack time.
   1.577 -\end{description}
   1.578 -
   1.579 -\section{Round Robin}
   1.580 +\item[vif-bridge:] This script is called for every domain virtual
   1.581 +interface and can configure firewalling rules and add the vif 
   1.582 +to the appropriate bridge. By default, this adds and removes 
   1.583 +VIFs on the default Xen bridge.
   1.584  
   1.585 -{\tt sched=rrobin } \\
   1.586 -
   1.587 -The Round Robin scheduler is included as a simple demonstration of
   1.588 -Xen's internal scheduler API.  It is not intended for production use
   1.589 ---- the other schedulers included are all more general and should give
   1.590 -higher throughput.
   1.591 +\end{description} 
   1.592  
   1.593 -\subsection{Global parameters}
   1.594 -
   1.595 -\begin{description}
   1.596 -\item[rr\_slice]
   1.597 -  The maximum time each domain runs before the next
   1.598 -  scheduling decision is made.
   1.599 -\end{description}
   1.600 -
   1.601 -\chapter{Privileged domains}
   1.602  
   1.603  %% There are two possible types of privileges:  IO privileges and
   1.604  %% administration privileges.
   1.605  
   1.606 -\section{Driver domains (I/O Privileges)}
   1.607 +\section{Driver Domain Configuration} 
   1.608  
   1.609  I/O privileges can be assigned to allow a domain to directly access
   1.610  PCI devices itself.  This is used to support driver domains.
   1.611 @@ -1217,37 +1156,33 @@ somewhere within the {\tt vm} element of
   1.612  be a {\tt backend} element of the form {\tt (backend ({\em type}))}
   1.613  where {\tt \em type} may be either {\tt netif} or {\tt blkif},
   1.614  according to the type of virtual device this domain will service.
   1.615 -After this domain has been built, \xend will connect all new and
   1.616 -existing {\em virtual} devices (of the appropriate type) to that
   1.617 -backend.
   1.618 +%% After this domain has been built, \xend will connect all new and
   1.619 +%% existing {\em virtual} devices (of the appropriate type) to that
   1.620 +%% backend.
   1.621  
   1.622 -Note that:
   1.623 -\begin{itemize}
   1.624 -\item a block backend cannot import virtual block devices from other
   1.625 -domains
   1.626 -\item a network backend cannot import virtual network devices from
   1.627 -other domains
   1.628 -\end{itemize}
   1.629 +Note that a block backend cannot import virtual block devices from
   1.630 +other domains, and a network backend cannot import virtual network
   1.631 +devices from other domains.  Thus (particularly in the case of block
   1.632 +backends, which cannot import a virtual block device as their root
   1.633 +filesystem), you may need to boot a backend domain from a ramdisk or a
   1.634 +network device.
   1.635  
   1.636 -Thus (particularly in the case of block backends, which cannot import
   1.637 -a virtual block device as their root filesystem), you may need to boot
   1.638 -a backend domain from a ramdisk or a network device.
   1.639 -
   1.640 -The privilege to drive PCI devices may also be specified on a
   1.641 -per-device basis.  Xen will assign the minimal set of hardware
   1.642 -privileges to a domain that are required to control its devices.  This
   1.643 -can be configured in either format of configuration file:
   1.644 +Access to PCI devices may be configured on a per-device basis.  Xen
   1.645 +will assign the minimal set of hardware privileges to a domain that
   1.646 +are required to control its devices.  This can be configured in either
   1.647 +format of configuration file:
   1.648  
   1.649  \begin{itemize}
   1.650 -\item SXP Format:
   1.651 -  Include {\tt device} elements
   1.652 -  {\tt (device (pci (bus {\em x}) (dev {\em y}) (func {\em z}))) } \\
   1.653 +\item SXP Format: Include device elements of the form: \\
   1.654 +\centerline{  {\tt (device (pci (bus {\em x}) (dev {\em y}) (func {\em z})))}} \\
   1.655    inside the top-level {\tt vm} element.  Each one specifies the address
   1.656 -  of a device this domain is allowed to drive ---
   1.657 +  of a device this domain is allowed to access ---
   1.658    the numbers {\em x},{\em y} and {\em z} may be in either decimal or
   1.659    hexadecimal format.
   1.660  \item Flat Format: Include a list of PCI device addresses of the
   1.661 -  format: \\ {\tt pci = ['x,y,z', ...] } \\ where each element in the
   1.662 +  format: \\ 
   1.663 +\centerline{{\tt pci = ['x,y,z', ...]}} \\ 
   1.664 +where each element in the
   1.665    list is a string specifying the components of the PCI device
   1.666    address, separated by commas.  The components ({\tt \em x}, {\tt \em
   1.667    y} and {\tt \em z}) of the list may be formatted as either decimal
   1.668 @@ -1264,113 +1199,202 @@ can be configured in either format of co
   1.669  % Support for other administrative domains is not yet available...  perhaps
   1.670  % we should plumb it in some time
   1.671  
   1.672 -\chapter{Debugging}
   1.673 +
   1.674 +
   1.675 +
   1.676 +
   1.677 +\section{Scheduler Configuration}
   1.678 +\label{s:sched} 
   1.679 +
   1.680 +
   1.681 +Xen offers a boot time choice between multiple schedulers.  To select
   1.682 +a scheduler, pass the boot parameter {\em sched=sched\_name} to Xen,
   1.683 +substituting the appropriate scheduler name.  Details of the schedulers
   1.684 +and their parameters are included below; future versions of the tools
   1.685 +will provide a higher-level interface to these tools.
   1.686  
   1.687 -Xen has a set of debugging features that can be useful to try and
   1.688 -figure out what's going on. Hit 'h' on the serial line (if you
   1.689 -specified a baud rate on the Xen command line) or ScrollLock-h on the
   1.690 -keyboard to get a list of supported commands.
   1.691 +It is expected that system administrators configure their system to
   1.692 +use the scheduler most appropriate to their needs.  Currently, the BVT
   1.693 +scheduler is the recommended choice. 
   1.694 +
   1.695 +\subsection{Borrowed Virtual Time}
   1.696  
   1.697 -If you have a crash you'll likely get a crash dump containing an EIP
   1.698 -(PC) which, along with an 'objdump -d image', can be useful in
   1.699 -figuring out what's happened.  Debug a Xenlinux image just as you
   1.700 -would any other Linux kernel.
   1.701 +{\tt sched=bvt} (the default) \\ 
   1.702 +
   1.703 +BVT provides proportional fair shares of the CPU time.  It has been
   1.704 +observed to penalise domains that block frequently (e.g. I/O intensive
   1.705 +domains), but this can be compensated for by using warping. 
   1.706 +
   1.707 +\subsubsection{Global Parameters}
   1.708  
   1.709 -We supply a handy debug terminal program which you can find in
   1.710 -\path{/usr/local/src/xen-2.0.bk/tools/misc/miniterm/}
   1.711 -This should be built and executed on another machine that is connected
   1.712 -via a null modem cable. Documentation is included.
   1.713 -Alternatively, if the Xen machine is connected to a serial-port server
   1.714 -then we supply a dumb TCP terminal client, {\tt xencons}.
   1.715 +\begin{description}
   1.716 +\item[ctx\_allow]
   1.717 +  the context switch allowance is similar to the "quantum"
   1.718 +  in traditional schedulers.  It is the minimum time that
   1.719 +  a scheduled domain will be allowed to run before being
   1.720 +  pre-empted. 
   1.721 +\end{description}
   1.722 +
   1.723 +\subsubsection{Per-domain parameters}
   1.724  
   1.725 -\chapter{Xen build options}
   1.726 +\begin{description}
   1.727 +\item[mcuadv]
   1.728 +  the MCU (Minimum Charging Unit) advance determines the
   1.729 +  proportional share of the CPU that a domain receives.  It
   1.730 +  is set inversely proportionally to a domain's sharing weight.
   1.731 +\item[warp]
   1.732 +  the amount of ``virtual time'' the domain is allowed to warp
   1.733 +  backwards
   1.734 +\item[warpl]
   1.735 +  the warp limit is the maximum time a domain can run warped for
   1.736 +\item[warpu]
   1.737 +  the unwarp requirement is the minimum time a domain must
   1.738 +  run unwarped for before it can warp again
   1.739 +\end{description}
   1.740  
   1.741 -For most users, the default build of Xen will be adequate.  For some
   1.742 -advanced uses, Xen provides a number of build-time options:
   1.743 +\subsection{Atropos}
   1.744 +
   1.745 +{\tt sched=atropos} \\
   1.746 +
   1.747 +Atropos is a soft real time scheduler.  It provides guarantees about
   1.748 +absolute shares of the CPU, with a facility for sharing
   1.749 +slack CPU time on a best-effort basis. It can provide timeliness
   1.750 +guarantees for latency-sensitive domains.
   1.751 +
   1.752 +Every domain has an associated period and slice.  The domain should
   1.753 +receive `slice' nanoseconds every `period' nanoseconds.  This allows
   1.754 +the administrator to configure both the absolute share of the CPU a
   1.755 +domain receives and the frequency with which it is scheduled. 
   1.756  
   1.757 -At build time, these options should be set as environment variables or
   1.758 -passed on make's command-line.  For example:
   1.759 +%%  When
   1.760 +%% domains unblock, their period is reduced to the value of the latency
   1.761 +%% hint (the slice is scaled accordingly so that they still get the same
   1.762 +%% proportion of the CPU).  For each subsequent period, the slice and
   1.763 +%% period times are doubled until they reach their original values.
   1.764 +
   1.765 +Note: don't overcommit the CPU when using Atropos (i.e. don't reserve
   1.766 +more CPU than is available --- the utilisation should be kept to
   1.767 +slightly less than 100\% in order to ensure predictable behaviour).
   1.768 +
   1.769 +\subsubsection{Per-domain parameters}
   1.770  
   1.771 -\begin{verbatim}
   1.772 -export option=y; make
   1.773 -option=y make
   1.774 -make option1=y option2=y
   1.775 -\end{verbatim}
   1.776 +\begin{description}
   1.777 +\item[period] The regular time interval during which a domain is
   1.778 +  guaranteed to receive its allocation of CPU time.
   1.779 +\item[slice]
   1.780 +  The length of time per period that a domain is guaranteed to run
   1.781 +  for (in the absence of voluntary yielding of the CPU). 
   1.782 +\item[latency]
   1.783 +  The latency hint is used to control how soon after
   1.784 +  waking up a domain it should be scheduled.
   1.785 +\item[xtratime] This is a boolean flag that specifies whether a domain
   1.786 +  should be allowed a share of the system slack time.
   1.787 +\end{description}
   1.788  
   1.789 -\section{List of options}
   1.790 +\section{Round Robin}
   1.791 +
   1.792 +{\tt sched=rrobin} \\
   1.793 +
   1.794 +The round robin scheduler is included as a simple demonstration of
   1.795 +Xen's internal scheduler API.  It is not intended for production use. 
   1.796 +
   1.797 +\subsection{Global parameters}
   1.798  
   1.799 -{\bf verbose=y }\\
   1.800 -Enable debugging messages when Xen detects an unexpected condition.
   1.801 -Also enables console output from all domains. \\
   1.802 -{\bf debug=y }\\
   1.803 -Enable debug assertions.  Implies {\bf verbose=y }.
   1.804 -(Primarily useful for tracing bugs in Xen).        \\
   1.805 -{\bf debugger=y }\\
   1.806 -Enable the in-Xen pervasive debugger (PDB).
   1.807 -This can be used to debug Xen, guest OSes, and
   1.808 -applications. For more information see the 
   1.809 -XenDebugger-HOWTO.                                 \\
   1.810 -{\bf perfc=y }\\
   1.811 -Enable performance-counters for significant events
   1.812 +\begin{description}
   1.813 +\item[rr\_slice]
   1.814 +  The maximum time each domain runs before the next
   1.815 +  scheduling decision is made.
   1.816 +\end{description}
   1.817 +
   1.818 +
   1.819 +
   1.820 +
   1.821 +
   1.822 +
   1.823 +
   1.824 +
   1.825 +
   1.826 +
   1.827 +
   1.828 +
   1.829 +\chapter{Build, Boot and Debug options} 
   1.830 +
   1.831 +This chapter describes the build- and boot-time options 
   1.832 +which may be used to tailor your Xen system. 
   1.833 +
   1.834 +\section{Xen build options}
   1.835 +
   1.836 +Xen provides a number of build-time options which should be 
   1.837 +set as environment variables or passed on make's command-line.  
   1.838 +
   1.839 +\begin{description} 
   1.840 +\item[verbose=y] Enable debugging messages when Xen detects an unexpected condition.
   1.841 +Also enables console output from all domains.
   1.842 +\item[debug=y] 
   1.843 +Enable debug assertions.  Implies {\bf verbose=y}.
   1.844 +(Primarily useful for tracing bugs in Xen).       
   1.845 +\item[debugger=y] 
   1.846 +Enable the in-Xen debugger. This can be used to debug 
   1.847 +Xen, guest OSes, and applications.
   1.848 +\item[perfc=y] 
   1.849 +Enable performance counters for significant events
   1.850  within Xen. The counts can be reset or displayed
   1.851 -on Xen's console via console control keys.          \\
   1.852 -{\bf trace=y }\\
   1.853 +on Xen's console via console control keys.
   1.854 +\item[trace=y] 
   1.855  Enable per-cpu trace buffers which log a range of
   1.856  events within Xen for collection by control
   1.857 -software.  For more information see the chapter on debugging,
   1.858 -in the Xen Interface Manual.
   1.859 -
   1.860 -\chapter{Boot options}
   1.861 +software. 
   1.862 +\end{description} 
   1.863  
   1.864  \section{Xen boot options}
   1.865 +\label{s:xboot}
   1.866  
   1.867  These options are used to configure Xen's behaviour at runtime.  They
   1.868  should be appended to Xen's command line, either manually or by
   1.869  editing \path{grub.conf}.
   1.870  
   1.871 -{\bf ignorebiostables }\\
   1.872 +\begin{description}
   1.873 +\item [ignorebiostables ] 
   1.874   Disable parsing of BIOS-supplied tables. This may help with some
   1.875   chipsets that aren't fully supported by Xen. If you specify this
   1.876   option then ACPI tables are also ignored, and SMP support is
   1.877 - disabled. \\
   1.878 + disabled. 
   1.879  
   1.880 -{\bf noreboot } \\
   1.881 +\item [noreboot ] 
   1.882   Don't reboot the machine automatically on errors.  This is
   1.883   useful to catch debug output if you aren't catching console messages
   1.884 - via the serial line. \\
   1.885 + via the serial line. 
   1.886  
   1.887 -{\bf nosmp } \\
   1.888 +\item [nosmp ] 
   1.889   Disable SMP support.
   1.890 - This option is implied by 'ignorebiostables'. \\
   1.891 + This option is implied by `ignorebiostables'. 
   1.892  
   1.893 -{\bf noacpi } \\
   1.894 +\item [noacpi ] 
   1.895   Disable ACPI tables, which confuse Xen on some chipsets.
   1.896 - This option is implied by 'ignorebiostables'. \\
   1.897 + This option is implied by `ignorebiostables'. 
   1.898  
   1.899 -{\bf watchdog } \\
   1.900 - Enable NMI watchdog which can report certain failures. \\
   1.901 +\item [watchdog ] 
   1.902 + Enable NMI watchdog which can report certain failures. 
   1.903  
   1.904 -{\bf noht } \\
   1.905 - Disable Hyperthreading. \\
   1.906 +\item [noht ] 
   1.907 + Disable Hyperthreading. 
   1.908  
   1.909 -{\bf badpage=$<$page number$>$[,$<$page number$>$] } \\
   1.910 +\item [badpage=$<$page number$>$,$<$page number$>$, \ldots ] 
   1.911   Specify a list of pages not to be allocated for use 
   1.912   because they contain bad bytes. For example, if your
   1.913   memory tester says that byte 0x12345678 is bad, you would
   1.914 - place 'badpage=0x12345' on Xen's command line (i.e., the
   1.915 - last three digits of the byte address are not
   1.916 - included!). \\
   1.917 + place `badpage=0x12345' on Xen's command line. 
   1.918  
   1.919 -{\bf com1=$<$baud$>$,DPS[,$<$io\_base$>$,$<$irq$>$] \\
   1.920 - com2=$<$baud$>$,DPS[,$<$io\_base$>$,$<$irq$>$] } \\
   1.921 +\item [com1=$<$baud$>$,DPS,$<$io\_base$>$,$<$irq$>$
   1.922 + com2=$<$baud$>$,DPS,$<$io\_base$>$,$<$irq$>$ ] \mbox{}\\ 
   1.923   Xen supports up to two 16550-compatible serial ports.
   1.924   For example: 'com1=9600,8n1,0x408,5' maps COM1 to a
   1.925   9600-baud port, 8 data bits, no parity, 1 stop bit,
   1.926   I/O port base 0x408, IRQ 5.
   1.927   If the I/O base and IRQ are standard (com1:0x3f8,4;
   1.928 - com2:0x2f8,3) then they need not be specified. \\
   1.929 + com2:0x2f8,3) then they need not be specified. 
   1.930  
   1.931 -{\bf console=$<$specifier list$>$ } \\
   1.932 +\item [console=$<$specifier list$>$ ] 
   1.933   Specify the destination for Xen console I/O.
   1.934   This is a comma-separated list of, for example:
   1.935  \begin{description}
   1.936 @@ -1387,55 +1411,89 @@ editing \path{grub.conf}.
   1.937   shared by two subsystems (e.g. console and
   1.938   debugger). Sharing is controlled by MSB of each
   1.939   transmitted/received character.
   1.940 - [NB. Default for this option is 'com1,tty'] \\
   1.941 + [NB. Default for this option is `com1,vga'] 
   1.942  
   1.943 -{\bf conswitch=$<$switch-char$><$auto-switch-char$>$ } \\
   1.944 +\item [conswitch=$<$switch-char$><$auto-switch-char$>$ ] 
   1.945   Specify how to switch serial-console input between
   1.946 - Xen and DOM0. The required sequence is CTRL-<switch-char>
   1.947 - pressed three times. Specifying '`' disables switching.
   1.948 - The <auto-switch-char> specifies whether Xen should
   1.949 - auto-switch input to DOM0 when it boots -- if it is 'x'
   1.950 + Xen and DOM0. The required sequence is CTRL-$<$switch-char$>$
   1.951 + pressed three times. Specifying the backtick character 
   1.952 + disables switching.
   1.953 + The $<$auto-switch-char$>$ specifies whether Xen should
   1.954 + auto-switch input to DOM0 when it boots --- if it is `x'
   1.955   then auto-switching is disabled.  Any other value, or
   1.956   omitting the character, enables auto-switching.
   1.957 - [NB. Default for this option is 'a'] \\
   1.958 + [NB. default switch-char is `a'] 
   1.959  
   1.960 -{\bf nmi=xxx } \\
   1.961 +\item [nmi=xxx ] 
   1.962   Specify what to do with an NMI parity or I/O error. \\
   1.963 - 'nmi=fatal':  Xen prints a diagnostic and then hangs. \\
   1.964 - 'nmi=dom0':   Inform DOM0 of the NMI. \\
   1.965 - 'nmi=ignore': Ignore the NMI. \\
   1.966 + `nmi=fatal':  Xen prints a diagnostic and then hangs. \\
   1.967 + `nmi=dom0':   Inform DOM0 of the NMI. \\
   1.968 + `nmi=ignore': Ignore the NMI. 
   1.969  
   1.970 -{\bf dom0\_mem=xxx } \\
   1.971 - Set the maximum amount of memory for domain0. \\
   1.972 +\item [dom0\_mem=xxx ] 
   1.973 + Set the amount of memory (in kB) to be allocated to domain0.  
   1.974  
   1.975 -{\bf tbuf\_size=xxx } \\
   1.976 +\item [tbuf\_size=xxx ] 
   1.977   Set the size of the per-cpu trace buffers, in pages
   1.978   (default 1).  Note that the trace buffers are only
   1.979   enabled in debug builds.  Most users can ignore
   1.980 - this feature completely. \\
   1.981 + this feature completely. 
   1.982  
   1.983 -{\bf sched=xxx } \\
   1.984 +\item [sched=xxx ] 
   1.985   Select the CPU scheduler Xen should use.  The current
   1.986 - possibilities are 'bvt', 'atropos' and 'rrobin'.  The
   1.987 - default is 'bvt'.  For more information see
   1.988 - Sched-HOWTO.txt. \\
   1.989 + possibilities are `bvt' (default), `atropos' and `rrobin'. 
   1.990 + For more information see Section~\ref{s:sched}. 
   1.991  
   1.992 -{\bf pci\_dom0\_hide=(xx.xx.x)(yy.yy.y)... } \\
   1.993 +\item [pci\_dom0\_hide=(xx.xx.x)(yy.yy.y)\ldots ] 
   1.994  Hide selected PCI devices from domain 0 (for instance, to stop it
   1.995  taking ownership of them so that they can be driven by another
   1.996  domain).  Device IDs should be given in hex format.  Bridge devices do
   1.997  not need to be hidden --- they are hidden implicitly, since guest OSes
   1.998  do not need to configure them.
   1.999 +\end{description} 
  1.1000 +
  1.1001 +
  1.1002  
  1.1003  \section{XenLinux Boot Options}
  1.1004  
  1.1005 -{\bf xencons=xxx}
  1.1006 -Specify the device node to
  1.1007 -which the Xen virtual console driver is attached: \\
  1.1008 - 'xencons=off': disable virtual console \\
  1.1009 - 'xencons=tty': attach console to /dev/tty1 (tty0 at boot-time) \\
  1.1010 - 'xencons=ttyS': attach console to /dev/ttyS0\\
  1.1011 +In addition to the standard linux kernel boot options, we support: 
  1.1012 +\begin{description} 
  1.1013 +\item[xencons=xxx ] Specify the device node to which the Xen virtual
  1.1014 +console driver is attached. The following options are supported:
  1.1015 +\begin{center}
  1.1016 +\begin{tabular}{l}
  1.1017 +`xencons=off': disable virtual console \\ 
  1.1018 +`xencons=tty': attach console to /dev/tty1 (tty0 at boot-time) \\
  1.1019 +`xencons=ttyS': attach console to /dev/ttyS0
  1.1020 +\end{tabular}
  1.1021 +\end{center}
  1.1022  The default is ttyS for dom0 and tty for all other domains.
  1.1023 +\end{description} 
  1.1024 +
  1.1025 +
  1.1026 +
  1.1027 +\section{Debugging}
  1.1028 +\label{s:keys} 
  1.1029 +
  1.1030 +Xen has a set of debugging features that can be useful to try and
  1.1031 +figure out what's going on. Hit 'h' on the serial line (if you
  1.1032 +specified a baud rate on the Xen command line) or ScrollLock-h on the
  1.1033 +keyboard to get a list of supported commands.
  1.1034 +
  1.1035 +If you have a crash you'll likely get a crash dump containing an EIP
  1.1036 +(PC) which, along with an 'objdump -d image', can be useful in
  1.1037 +figuring out what's happened.  Debug a Xenlinux image just as you
  1.1038 +would any other Linux kernel.
  1.1039 +
  1.1040 +%% We supply a handy debug terminal program which you can find in
  1.1041 +%% \path{/usr/local/src/xen-2.0.bk/tools/misc/miniterm/}
  1.1042 +%% This should be built and executed on another machine that is connected
  1.1043 +%% via a null modem cable. Documentation is included.
  1.1044 +%% Alternatively, if the Xen machine is connected to a serial-port server
  1.1045 +%% then we supply a dumb TCP terminal client, {\tt xencons}.
  1.1046 +
  1.1047 +
  1.1048 +
  1.1049  
  1.1050  \chapter{Further Support}
  1.1051  
  1.1052 @@ -1455,13 +1513,13 @@ into this manual.
  1.1053  
  1.1054  \section{Online references}
  1.1055  
  1.1056 -The official Xen web site is found at: \\
  1.1057 -{\tt
  1.1058 -http://www.cl.cam.ac.uk/Research/SRG/netos/xen/] }.
  1.1059 +The official Xen web site is found at:
  1.1060 +\begin{quote}
  1.1061 +{\tt http://www.cl.cam.ac.uk/Research/SRG/netos/xen/}
  1.1062 +\end{quote}
  1.1063  
  1.1064 -Links to other
  1.1065 -documentation sources are listed at: \\ {\tt
  1.1066 -http://www.cl.cam.ac.uk/Research/SRG/netos/xen/documentation.html}.
  1.1067 +This contains links to the latest versions of all on-line 
  1.1068 +documentation. 
  1.1069  
  1.1070  \section{Mailing lists}
  1.1071  
  1.1072 @@ -1470,13 +1528,13 @@ There are currently three official Xen m
  1.1073  \begin{description}
  1.1074  \item[xen-devel@lists.sourceforge.net] Used for development
  1.1075  discussions and requests for help.  Subscribe at: \\
  1.1076 -{\tt http://lists.sourceforge.net/mailman/listinfo/xen-devel}
  1.1077 +{\small {\tt http://lists.sourceforge.net/mailman/listinfo/xen-devel}}
  1.1078  \item[xen-announce@lists.sourceforge.net] Used for announcements only.
  1.1079  Subscribe at: \\
  1.1080 -{\tt http://lists.sourceforge.net/mailman/listinfo/xen-announce}
  1.1081 +{\small {\tt http://lists.sourceforge.net/mailman/listinfo/xen-announce}}
  1.1082  \item[xen-changelog@lists.sourceforge.net]  Changelog feed
  1.1083  from the unstable and 2.0 trees - developer oriented.  Subscribe at: \\
  1.1084 -{\tt http://lists.sourceforge.net/mailman/listinfo/xen-changelog}
  1.1085 +{\small {\tt http://lists.sourceforge.net/mailman/listinfo/xen-changelog}}
  1.1086  \end{description}
  1.1087  
  1.1088  Although there is no specific user support list, the developers try to
  1.1089 @@ -1485,12 +1543,13 @@ list increases, a dedicated user support
  1.1090  
  1.1091  \appendix
  1.1092  
  1.1093 +
  1.1094  \chapter{Installing Debian}
  1.1095  
  1.1096 -The Debian project provides a tool called {\tt debootstrap} which
  1.1097 +The Debian project provides a tool called {\small {\tt debootstrap}} which
  1.1098  allows a base Debian system to be installed into a filesystem without
  1.1099  requiring the host system to have any Debian-specific software (such
  1.1100 -as {\tt apt}).
  1.1101 +as {\small {\tt apt}}).
  1.1102  
  1.1103  Here's some info how to install Debian 3.1 (Sarge) for an unprivileged
  1.1104  Xen domain:
  1.1105 @@ -1502,116 +1561,116 @@ Xen domain:
  1.1106  \item Create disk images for root-fs and swap (alternatively, you
  1.1107        might create dedicated partitions, LVM logical volumes, etc. if
  1.1108        that suits your setup).
  1.1109 -\begin{verbatim}  
  1.1110 +\begin{small}\begin{verbatim}  
  1.1111  dd if=/dev/zero of=/path/diskimage bs=1024k count=size_in_mbytes
  1.1112  dd if=/dev/zero of=/path/swapimage bs=1024k count=size_in_mbytes
  1.1113 -\end{verbatim}
  1.1114 +\end{verbatim}\end{small}
  1.1115        If you're going to use this filesystem / diskimage only as a
  1.1116        `template' for other vm diskimages, something like 300 MB should
  1.1117        be enough.. (of course it depends what kind of packages you are
  1.1118        planning to install to the template)
  1.1119  
  1.1120  \item Create the filesystem and initialise the swap image
  1.1121 -\begin{verbatim}
  1.1122 +\begin{small}\begin{verbatim}
  1.1123  mkfs.ext3 /path/diskimage
  1.1124  mkswap /path/swapimage
  1.1125 -\end{verbatim}
  1.1126 +\end{verbatim}\end{small}
  1.1127  
  1.1128  \item Mount the diskimage for installation
  1.1129 -\begin{verbatim}
  1.1130 +\begin{small}\begin{verbatim}
  1.1131  mount -o loop /path/diskimage /mnt/disk
  1.1132 -\end{verbatim}
  1.1133 +\end{verbatim}\end{small}
  1.1134  
  1.1135 -\item Install {\tt debootstrap}
  1.1136 +\item Install {\small {\tt debootstrap}}
  1.1137  
  1.1138  Make sure you have debootstrap installed on the host.  If you are
  1.1139  running Debian sarge (3.1 / testing) or unstable you can install it by
  1.1140 -running {\tt apt-get install debootstrap}.  Otherwise, it can be
  1.1141 +running {\small {\tt apt-get install debootstrap}}.  Otherwise, it can be
  1.1142  downloaded from the Debian project website.
  1.1143  
  1.1144  \item Install debian base to the diskimage:
  1.1145 -\begin{verbatim}
  1.1146 +\begin{small}\begin{verbatim}
  1.1147  debootstrap --arch i386 sarge /mnt/disk  \
  1.1148              http://ftp.<countrycode>.debian.org/debian
  1.1149 -\end{verbatim}
  1.1150 +\end{verbatim}\end{small}
  1.1151  
  1.1152  You can use any other Debian http/ftp mirror you want.
  1.1153  
  1.1154  \item When debootstrap completes successfully, modify settings:
  1.1155 -\begin{verbatim}
  1.1156 +\begin{small}\begin{verbatim}
  1.1157  chroot /mnt/disk /bin/bash
  1.1158 -\end{verbatim}
  1.1159 +\end{verbatim}\end{small}
  1.1160  
  1.1161  Edit the following files using vi or nano and make needed changes:
  1.1162 -\begin{verbatim}
  1.1163 +\begin{small}\begin{verbatim}
  1.1164  /etc/hostname
  1.1165  /etc/hosts
  1.1166  /etc/resolv.conf
  1.1167  /etc/network/interfaces
  1.1168  /etc/networks
  1.1169 -\end{verbatim}
  1.1170 +\end{verbatim}\end{small}
  1.1171  
  1.1172  Set up access to the services, edit:
  1.1173 -\begin{verbatim}
  1.1174 +\begin{small}\begin{verbatim}
  1.1175  /etc/hosts.deny
  1.1176  /etc/hosts.allow
  1.1177  /etc/inetd.conf
  1.1178 -\end{verbatim}
  1.1179 +\end{verbatim}\end{small}
  1.1180  
  1.1181  Add Debian mirror to:   
  1.1182 -\begin{verbatim}
  1.1183 +\begin{small}\begin{verbatim}
  1.1184  /etc/apt/sources.list
  1.1185 -\end{verbatim}
  1.1186 +\end{verbatim}\end{small}
  1.1187  
  1.1188  Create fstab like this:
  1.1189 -\begin{verbatim}
  1.1190 +\begin{small}\begin{verbatim}
  1.1191  /dev/sda1       /       ext3    errors=remount-ro       0       1
  1.1192  /dev/sda2       none    swap    sw                      0       0
  1.1193  proc            /proc   proc    defaults                0       0
  1.1194 -\end{verbatim}
  1.1195 +\end{verbatim}\end{small}
  1.1196  
  1.1197  Logout
  1.1198  
  1.1199  \item      Umount the diskimage
  1.1200 -\begin{verbatim}
  1.1201 +\begin{small}\begin{verbatim}
  1.1202  umount /mnt/disk
  1.1203 -\end{verbatim}
  1.1204 +\end{verbatim}\end{small}
  1.1205  
  1.1206  \item Create Xen 2.0 configuration file for the new domain. You can
  1.1207          use the example-configurations coming with xen as a template.
  1.1208  
  1.1209          Make sure you have the following set up:
  1.1210 -\begin{verbatim}
  1.1211 +\begin{small}\begin{verbatim}
  1.1212  disk = [ 'file:/path/diskimage,sda1,w', 'file:/path/swapimage,sda2,w' ]
  1.1213  root = "/dev/sda1 ro"
  1.1214 -\end{verbatim}
  1.1215 +\end{verbatim}\end{small}
  1.1216  
  1.1217  \item Start the new domain
  1.1218 -\begin{verbatim}
  1.1219 +\begin{small}\begin{verbatim}
  1.1220  xm create -f domain_config_file
  1.1221 -\end{verbatim}
  1.1222 +\end{verbatim}\end{small}
  1.1223  
  1.1224  Check that the new domain is running:
  1.1225 -\begin{verbatim}
  1.1226 +\begin{small}\begin{verbatim}
  1.1227  xm list
  1.1228 -\end{verbatim}
  1.1229 +\end{verbatim}\end{small}
  1.1230  
  1.1231  \item   Attach to the console of the new domain.
  1.1232          You should see something like this when starting the new domain:
  1.1233  
  1.1234 -\begin{verbatim}
  1.1235 +\begin{small}\begin{verbatim}
  1.1236  Started domain testdomain2, console on port 9626
  1.1237 -\end{verbatim}
  1.1238 +\end{verbatim}\end{small}
  1.1239          
  1.1240          There you can see the ID of the console: 26. You can also list
  1.1241 -        the consoles with {\tt xm consoles"}. (ID is the last two
  1.1242 +        the consoles with {\small {\tt xm consoles}} (ID is the last two
  1.1243          digits of the portnumber.)
  1.1244  
  1.1245          Attach to the console:
  1.1246  
  1.1247 -\begin{verbatim}
  1.1248 +\begin{small}\begin{verbatim}
  1.1249  xm console 26
  1.1250 -\end{verbatim}
  1.1251 +\end{verbatim}\end{small}
  1.1252  
  1.1253          or by telnetting to the port 9626 of localhost (the xm console
  1.1254          progam works better).
  1.1255 @@ -1624,21 +1683,22 @@ xm console 26
  1.1256          errors.  Check that the swap is active, and the network settings are
  1.1257          correct.
  1.1258  
  1.1259 -        Run {\tt /usr/sbin/base-config} to set up the Debian settings.
  1.1260 +        Run {\small {\tt/usr/sbin/base-config}} to set up the Debian settings.
  1.1261  
  1.1262          Set up the password for root using passwd.
  1.1263  
  1.1264 -\item     Done. You can exit the console by pressing {\tt Ctrl + ]}
  1.1265 +\item     Done. You can exit the console by pressing {\small {\tt Ctrl + ]}}
  1.1266  
  1.1267  \end{enumerate}
  1.1268  
  1.1269  If you need to create new domains, you can just copy the contents of
  1.1270  the `template'-image to the new disk images, either by mounting the
  1.1271 -template and the new image, and using {\tt cp -a} or {\tt tar} or by
  1.1272 +template and the new image, and using {\small {\tt cp -a}} or {\small
  1.1273 +    {\tt tar}} or by
  1.1274  simply copying the image file.  Once this is done, modify the
  1.1275  image-specific settings (hostname, network settings, etc).
  1.1276  
  1.1277 -\chapter{Installing Xen / XenLinux on Redhat / Fedora}
  1.1278 +\chapter{Installing Xen / XenLinux on Redhat or Fedora Core}
  1.1279  
  1.1280  When using Xen / Xenlinux on a standard Linux distribution there are
  1.1281  a couple of things to watch out for:
  1.1282 @@ -1649,53 +1709,57 @@ to update the hwclock, change the consol
  1.1283  map, start apmd (power management), or gpm (mouse cursor).  Either
  1.1284  ignore the errors (they should be harmless), or remove them from the
  1.1285  startup scripts.  Deleting the following links are a good start:
  1.1286 -\path{S24pcmcia}, \path{S09isdn}, \path{S17keytable}, \path{S26apmd},
  1.1287 -\path{S85gpm}.
  1.1288 +{\small\path{S24pcmcia}}, {\small\path{S09isdn}},
  1.1289 +{\small\path{S17keytable}}, {\small\path{S26apmd}},
  1.1290 +{\small\path{S85gpm}}.
  1.1291  
  1.1292  If you want to use a single root file system that works cleanly for
  1.1293 -domain0 and domains>0, a useful trick is to use different 'init' run
  1.1294 -levels. For example, on the Xen Demo CD we use run level 3 for domain
  1.1295 -0, and run level 4 for domains>0. This enables different startup
  1.1296 -scripts to be run in depending on the run level number passed on the
  1.1297 -kernel command line.
  1.1298 +both domain 0 and unprivileged domains, a useful trick is to use
  1.1299 +different 'init' run levels. For example, on the Xen Demo CD we use
  1.1300 +run level 3 for domain 0, and run level 4 for other domains. This
  1.1301 +enables different startup scripts to be run in depending on the run
  1.1302 +level number passed on the kernel command line.
  1.1303  
  1.1304 -If you're going to use NFS root files systems mounted either from an
  1.1305 +If using NFS root files systems mounted either from an
  1.1306  external server or from domain0 there are a couple of other gotchas.
  1.1307 -The default \path{/etc/sysconfig/iptables} rules block NFS, so part
  1.1308 +The default {\small\path{/etc/sysconfig/iptables}} rules block NFS, so part
  1.1309  way through the boot sequence things will suddenly go dead.
  1.1310  
  1.1311 -If you're planning on having a separate NFS \path{/usr} partition, the
  1.1312 +If you're planning on having a separate NFS {\small\path{/usr}} partition, the
  1.1313  RH9 boot scripts don't make life easy - they attempt to mount NFS file
  1.1314  systems way to late in the boot process. The easiest way I found to do
  1.1315 -this was to have a \path{/linuxrc} script run ahead of
  1.1316 -\path{/sbin/init} that mounts \path{/usr}:
  1.1317 +this was to have a {\small\path{/linuxrc}} script run ahead of
  1.1318 +{\small\path{/sbin/init}} that mounts {\small\path{/usr}}:
  1.1319  
  1.1320 -\begin{verbatim}
  1.1321 +\begin{quote}
  1.1322 +\begin{small}\begin{verbatim}
  1.1323   #!/bin/bash
  1.1324   /sbin/ipconfig lo 127.0.0.1
  1.1325   /sbin/portmap
  1.1326   /bin/mount /usr
  1.1327   exec /sbin/init "$@" <>/dev/console 2>&1
  1.1328 -\end{verbatim}
  1.1329 +\end{verbatim}\end{small}
  1.1330 +\end{quote}
  1.1331  
  1.1332  %$ XXX SMH: font lock fix :-)  
  1.1333  
  1.1334  The one slight complication with the above is that
  1.1335 -\path{/sbin/portmap} is dynamically linked against
  1.1336 -\path{/usr/lib/libwrap.so.0} Since this is in \path{/usr}, it won't
  1.1337 -work. This can be solved by copying the file (and link) below the /usr
  1.1338 -mount point, and just let the file be 'covered' when the mount
  1.1339 -happens.
  1.1340 +{\small\path{/sbin/portmap}} is dynamically linked against
  1.1341 +{\small\path{/usr/lib/libwrap.so.0}} Since this is in
  1.1342 +{\small\path{/usr}}, it won't work. This can be solved by copying the
  1.1343 +file (and link) below the /usr mount point, and just let the file be
  1.1344 +'covered' when the mount happens.
  1.1345  
  1.1346 -In some installations, where a shared read-only \path{/usr} is being
  1.1347 -used, it may be desirable to move other large directories over into
  1.1348 -the read-only \path{/usr}. For example, you might replace \path{/bin},
  1.1349 -\path{/lib} and \path{/sbin} with links into \path{/usr/root/bin},
  1.1350 -\path{/usr/root/lib} and \path{/usr/root/sbin} respectively. This
  1.1351 -creates other problems for running the \path{/linuxrc} script,
  1.1352 -requiring bash, portmap, mount, ifconfig, and a handful of other
  1.1353 -shared libraries to be copied below the mount point - a little
  1.1354 -statically linked C program would solve this problem.
  1.1355 +In some installations, where a shared read-only {\small\path{/usr}} is
  1.1356 +being used, it may be desirable to move other large directories over
  1.1357 +into the read-only {\small\path{/usr}}. For example, you might replace
  1.1358 +{\small\path{/bin}}, {\small\path{/lib}} and {\small\path{/sbin}} with
  1.1359 +links into {\small\path{/usr/root/bin}}, {\small\path{/usr/root/lib}}
  1.1360 +and {\small\path{/usr/root/sbin}} respectively. This creates other
  1.1361 +problems for running the {\small\path{/linuxrc}} script, requiring
  1.1362 +bash, portmap, mount, ifconfig, and a handful of other shared
  1.1363 +libraries to be copied below the mount point --- a simple
  1.1364 +statically-linked C program would solve this problem.
  1.1365  
  1.1366  
  1.1367  
  1.1368 @@ -1720,7 +1784,7 @@ statically linked C program would solve 
  1.1369                             specifically to run multiple conventional OSs.
  1.1370  
  1.1371  \item[Domain]              A domain is the execution context that
  1.1372 -                           contains a running { \bf virtual machine }.
  1.1373 +                           contains a running {\bf virtual machine}.
  1.1374                             The relationship between virtual machines
  1.1375                             and domains on Xen is similar to that between
  1.1376                             programs and processes in an operating
  1.1377 @@ -1728,13 +1792,13 @@ statically linked C program would solve 
  1.1378                             entity that resides on disk (somewhat like
  1.1379                             a program).  When it is loaded for execution,
  1.1380                             it runs in a domain.  Each domain has a
  1.1381 -                           { \bf domain ID }.
  1.1382 +                           {\bf domain ID}.
  1.1383  
  1.1384  \item[Domain 0]            The first domain to be started on a Xen
  1.1385                             machine.  Domain 0 is responsible for managing
  1.1386                             the system.
  1.1387  
  1.1388 -\item[Domain ID]           A unique identifier for a { \bf domain },
  1.1389 +\item[Domain ID]           A unique identifier for a {\bf domain},
  1.1390                             analogous to a process ID in an operating
  1.1391                             system.  Apart from domain
  1.1392  
  1.1393 @@ -1743,7 +1807,7 @@ statically linked C program would solve 
  1.1394                             operating system, providing the illusion of
  1.1395                             a complete system of real hardware devices.
  1.1396  
  1.1397 -\item[Hypervisor]          An alternative term for { \bf VMM }, used
  1.1398 +\item[Hypervisor]          An alternative term for {\bf VMM}, used
  1.1399                             because it means `beyond supervisor',
  1.1400                             since it is responsible for managing multiple
  1.1401                             `supervisor' kernels.
  1.1402 @@ -1773,7 +1837,7 @@ statically linked C program would solve 
  1.1403  
  1.1404  \item[Shadow pagetables]   A technique for hiding the layout of machine
  1.1405                             memory from a virtual machine's operating
  1.1406 -                           system.  Used in some {\bf VMM}s to provide
  1.1407 +                           system.  Used in some {\bf VMMs} to provide
  1.1408                             the illusion of contiguous physical memory,
  1.1409                             in Xen this is used during
  1.1410                             {\bf live migration}.
  1.1411 @@ -1782,8 +1846,8 @@ statically linked C program would solve 
  1.1412                             system runs, providing the abstraction of a
  1.1413                             dedicated machine.  A virtual machine may
  1.1414                             be identical to the underlying hardware (as
  1.1415 -                           in { \bf full virtualisation }, or it may
  1.1416 -                           differ, as in { \bf paravirtualisation }.
  1.1417 +                           in {\bf full virtualisation}, or it may
  1.1418 +                           differ, as in {\bf paravirtualisation}.
  1.1419  
  1.1420  \item[VMM]                 Virtual Machine Monitor - the software that
  1.1421                             allows multiple virtual machines to be