[palacios.git] / manual / manual.tex

\documentclass[11pt]{article}

\usepackage{calc}
\usepackage{graphics}
%\usepackage{latex8}
\usepackage{times}
\usepackage{epsf}
\usepackage{epsfig}
\usepackage{graphicx}
\usepackage{changebar}
\usepackage{portland}
\usepackage{lscape}

\setlength{\textheight}{8.50in}
\setlength{\textwidth}{6.5in}
\setlength{\topmargin}{-0.3in}
%\setlength{\leftmargin}{2.9in}
%\setlength{\rightmargin}{-2.9in}
\setlength{\oddsidemargin}{0in}
\setlength{\parindent}{0.5in}
\setlength\parindent{0in}
\setlength\parskip{0.1in} 

\newcommand{\note}[1]{{$\rightarrow$ \bf Note: \emph{#1}}}

\begin{document}

\title{
\includegraphics[height=1.5in]{v3vee.pdf}
\includegraphics[height=1.5in]{logo6.png} \\
\vspace{0.5in} 
Palacios Internal Developer Manual
}


\maketitle


This manual is written for Internal Palacios developers. It contains
information on how to obtain the palacios code base, how to go about
the development process, and how to commit those changes to the
mainline source tree.  This assumes that the reader has read {\em An
Introduction to the Palacios Virtual Machine Monitor -- Release 1.0}
and also has a slight working knowledge of {\em git}.


\section{Overview}


Both Palacios and Kitten follow a hybrid development process that
uses both the centralized repository and distributed development
models. A central repository exists that holds the master version of
the code base. This central repository is cloned by multiple people
and in multiple places to support various development efforts. A
feature of git is that every developer actually has a fully copy of
the entire repository, and so can function independently until such
time as they need to resync with the master version. 

There are typically multiple levels of access to the central
repository, that are granted based on the type of developer being
granted access. The three basic developer types and their access
privileges are:

\begin{itemize}
\item Core Developers: These are the lead developers and are in
charge of managing the master repository. They have full read/write
access permissions to the central repository.

\item Internal Developers: Formal members of the development
team. These people are capable of pulling directly from the central
repository, but lack the ability to write directly to it. 

\item External Developers: People who are not actual members of the
development team. These people can only access the public repository
which is only updated to contain the release versions. 
\end{itemize}

Because internal and external developers cannot write directly to the
master repository, they need to first submit their changes to a core
developer before they can be added to the mainline. We will discuss
that process in Section~\ref{sec:submission}.


\section{Checking out Palacios}
The central palacios repository is located on {\em
newskysaw.cs.northwestern.edu} in {\em /home/palacios/palacios}. All
internal developers have read access to the directory. Each developer
must create their own local version of the repository, this is done
with {\em git clone}.

\begin{verbatim}
git clone /home/palacios/palacios
\end{verbatim}

This creates a local copy of the repository at {\em ./palacios/}.


All development work is done in the {\em devel} branch of the
repository. The developer can access this branch via:

\begin{verbatim}
git checkout --track -b devel origin/devel
\end{verbatim}

or 

\begin{verbatim}
/opt/vmm-tools/bin/checkout_branch devel
\end{verbatim}

{\em Important:}
Note that palacios is very actively developed so the contents of the
{\em devel} branch are frequently changing. In order to keep up to
date with the latest version, it is necessary to periodically pull the
latest changes from the master repository by running \verb.git pull..



\section{Checking out Kitten}

Kitten is available from Sandia National Labs, and is the main host OS
we are targetting with Palacios. Loosely speaking core Palacios
developers are internal Kitten developers, and internal Palacios
developers are external Kitten developers. Because we have limited
access to the Kitten repository, we are maintaining a local mirror
copy in {\em /home/palacios/kitten}. 

Kitten uses Mercurial for their source management, so you will have to
make sure the local mercurial version is configured correctly.
Specifically you should add the following python path to your shell environment.

\begin{verbatim}
export PYTHONPATH=/usr/local/lib64/python2.4/site-packages/
\end{verbatim}

You can then clone Kitten from the local mirror:
\begin{verbatim}
hg clone /home/palacios/kitten
\end{verbatim}

Both the Kitten and Palacios clone commands should be run from the
same direcotyr. This means that both repositories should be located at
the same directory level. The Kitten build process depends on this.

{\em Important:} Like Palacios, Kitten is very actively developed so
source tree is frequently changing. In order to keep up to date with
the latest version, it is necessary to periodically pull the latest
changes from the mirror repository by running \verb.hg pull. followed
by \verb.hg update..

\section{Compiling Palacios}
Palacios is capable of targeting 32 and 64 bit operating systems, and
includes a build process that supports both these
architectures. Furthermore, Palacios has multiple build locations,
with multiple makefiles: a top level build directory and a Palacios
specific build directory. The Palacios build process first generates a
static library that includes the Palacios VMM. This static library is
then linked into a host operating system. Palacios internally supports
GeekOS and can generate a complete OS image via a unified build
process. To combine Palacios with Kitten, it is necessary to first
compile Palacios and then to compile Kitten externally link it with
Palacios. The output of the compilation process is a bit more complex
and generates multiple binaries, and the specifics can be found in the
Makefiles.

The top level build directory provides a number of high level make
targets, and is located in {\em palacios/build/}. It supports building
32 and 64 bit versions of the Palacios library independently as well
as building an integrated version of GeekOS.   The basic targets are:
\begin{itemize}
\item \verb.make palacios-full32. -- Generates a 32 bit version of the Palacios static library 
\item \verb.make palacios-full64. -- Generates a 64 bit version of the
Palacios static library
\item \verb.make geekos. -- Compiles the GeekOS kernel, and link it with the
Palacios static library 
\item \verb.make geekos-iso. -- Generate an ISO boot disk image from the
GeekOS kernel that has been compiled
\end{itemize}

The second build directory is located at {\em palacios/palacios/build}
and handles only the Palacios compilation process. It supports a
differnt set of targets and arguments:
\begin{itemize}
\item \verb.make ARCH=32. -- iteratively compiles a 32 bit version of Palacios
\item \verb.make ARCH=64. -- iteratively compiles a 64 bit version of
Palacios
\item \verb.make ARCH=32 world. -- fully recompiles a 32 bit version of
Palacios
\item \verb.make ARCH=64 world. -- fully recompiles a 64 bit version of
Palacios
\end{itemize}

Both build levels support compilation directives that control the
debugging messages that are generated by Palacios. These are specified
by appending a \verb.DEBUG_<COMPONENT>=1. to the end of the
\verb.make. command. The components that are currently supported are:
\begin{itemize}
\item \verb.DEBUG_ALL=1. -- enables debugging for all the VMM components
({\em Warning:} this generates a {\em lot} of debug information.
\item \verb.DEBUG_SHADOW_PAGING=1.
\item \verb.DEBUG_CTRL_REGS=1.
\item \verb.DEBUG_INTERRUPTS=1.
\item \verb.DEBUG_IO=1.
\item \verb.DEBUG_KEYBOARD=1.
\item \verb.DEBUG_PIC=1.
\item \verb.DEBUG_PIT=1.
\item \verb.DEBUG_NVRAM=1.
\item \verb.DEBUG_GENERIC=1.
\item \verb.DEBUG_EMULATOR=1.
\item \verb.DEBUG_RAMDISK=1.
\item \verb.DEBUG_XED=1.
\item \verb.DEBUG_HALT=1.
\item \verb.DEBUG_DEV_MGR=1.
\item \verb.DEBUG_APIC=1.
\end{itemize}



\section{Compiling Kitten}
Kitten requires a 64 bit version of Palacios, so make sure that
Palacios has been correctly compiled before compiling Kitten.

\subsection{Configuration}
Kitten borrows a lot of concepts from Linux, including the Linux build
process. As such it must be configured before it is actually compiled.
The Kitten configuration process is the same as Linux, and can be
accessed via any of these make targets.
\begin{itemize}
\item \verb.make xconfig.
\item \verb.make config.
\item \verb.make menuconfig.
\end{itemize}

There are some specific configuration options that should be disabled
to work with Palacios. Because Palacios is configured by default to
provide a guest with direct access to the VGA console, the {\em VGA
console} device driver should be disbabled in the Kitten
configuration. Similarly the {\em VM console} driver should be
disabled as well.

Furthermore, because the VGA console is not being used the {\em Kernel
Command Line Arguments} must be modified to remove the {\em VGA}
device from the console list.

The guest OS that is booted as a VM is included as an ISO image in raw
binary format inside Kitten's {\em init\_task}. To change the guest
ISO, you must change the makefile for the init\_task. This is located
in {\em user/hello\_world/Makefile} and the syntax is well commented.
On {\em newskysaw} a collection of guest ISO images are located in
{\em /opt/vmm-tools/isos/}. 


\subsection{Compilation}
After Kitten has been configured the compilation can be done. The
general process is to compile a reference build of Kitten, followed by
compiling Palacios support as a kernel module, and then doing a new
full recompilation of Kitten.

The specific compilation steps are run from the top level Kitten directory:
\begin{verbatim}
make
cd palacios
make -C .. M=`pwd`
cp built-in.o ../modules/palacios-mod.o
cd ..
make
make isoimage
\end{verbatim}

\note{This should probably explain how to change the iso (helloworld,etc)}

This generates an ISO boot image containing Kitten, Palacios, and the
guest that will be run as a VM. The ISO image is located at {\em
./arch/x86\_64/boot/image.iso}.


\section{Running Palacios/Kitten}
Kitten and Palacios are capable of running under Qemu, which makes
debugging much simpler.

The basic form of the command to start the Qemu emulator is:
\begin{verbatim}
/usr/local/qemu/bin/qemu-system-x86_64 -smp 1 -m 1024 \
        -serial file:./serial.out \
        -cdrom ./arch/x86_64/boot/image.iso  \
        < /dev/null
\end{verbatim}

The command starts up a single processor emulated machine, with 1gig
of RAM and a cdrom drive loaded with the Kitten ISO image. Furthermore
all output to the serial port is written directly to a file called
{\em serial.out}. This command can be copied into a shell script for easy access.

\section{Development Guidelines}

There are standard requirements we have for code entering the mainline. 

First and foremost, Palacios is designed to be OS indenpendent and
support 32 and 64 bit architectures. This means that developers should
not include any external OS specific dependencies in any Palacios
component. Also all changes need to be tested on both 32 and 64 bit
architectures to make sure that they compile as well as run corrrectly.

\paragraph*{Coding Style}

"The use of equal negative space, as a balance to positive space, in a
composition is considered by many as good design. This basic and often
overlooked principle of design gives the eye a "place to rest,"
increasing the appeal of a composition through subtle means."
\newline\newline
Translation: Use the spacebar, newlines, and parentheses. 

Curly-brackets are not optional, even for single line conditionals. 

Tabs should be 4 characters in width.

{\em Special:} If you are using XEmacs add the following to your \verb.init\.el. file:
\begin{verbatim}
(setq c-basic-offset 4)
(c-set-offset 'case-label 4)
\end{verbatim}

{\em Bad}
\begin{verbatim}
if(a&&b==5||c!=0) return;
\end{verbatim}


{\em Good}

\begin{verbatim}
if (((a) && (b == 5)) || 
    (c != 0)) {
        return;
}
\end{verbatim}



\paragraph*{Fail Stop}
Because booting a basic linux kernel results in over 1 million VM exits
catching silent errors is next to impossible. For this reason
ANY time your code has an error it should return -1, and expect the
execution to halt. 

This includes unimplemented features and unhandled cases. These cases
should ALWAYS return -1. 


\paragraph*{Function names}
Externally visible function names should be used rarely and have
unique names. Currently we have several techniques for achieving this:

\begin{enumerate}
\item \verb.#ifdefs. in the header file
\newline
When the V3 Hypervisor is compiled it defines the symbol
\verb.__V3VEE__. Any function that is not needed outside the Hypervisor
context should be inside an \verb.#ifdef __V3VEE__. block, this will make it
invisible to the host environment.

\item Static Functions
\newline
Any utility functions that are only needed in the .c file where they
are defined should be declared as static and not included in the
header file. You should make an effort to use static functions
whenever possible. 

\item \verb.v3_. prefix
\newline
Major interface functions should be named with the prefix \verb.v3_. This
xallows easy understanding of how to interact with the subsystems. And
in the case that they need to be externally visible to the host os,
make them unlikely to collide with other functions. 
\end{enumerate}

\paragraph*{Debugging Output}
Debugging output is sent through the host os via functions in the
\verb.os_hooks. structure. These functions have various wrappers of the form
\verb.Print*., with printf style semantics. 

Two functions of note are \verb.PrintDebug. and \verb.PrintError..

\begin{itemize}

\item PrintDebug:
\newline
Should be used for debugging output that will often be turned off
selectively by the VMM configuration.

\item PrintError
\newline
Should be used when an error occurs, this will never be optimized out
and will always print. 
\end{itemize}


\section{Code Submission}
\label{sec:submission}

To commit changes to the central repository they need to be exported
as a patch set that can be applied directly to a mainline. Both Git
and Mercurial contain functionality to allow developers to maintain
changes as a patch set. There are also a few options that make dealing
with patches easier.

\subsection{Palacios}

Git includes support for directly exporting local repository commits
as a patch set. The basic operation is for a developer to commit a
change to a local repository, and then export that change as a patch
that can be applied to another git repository. While this is
functionally possible, there are a number of issues. The main problem
is that it is difficult to fully encapsulate a new feature in a single
commit, and dealing with multiple patches that often overwrite each
other is not a viable option either. Furthermore, once a patch is
applied to the mainline, it will generate a conflicting commit that
will become present when the developer next pulls from the central
repository. This can result in both repositories getting out of
sync. It is possible to deal with this by manually rebasing the local
repository, but it is difficult and error-prone. 

This approach also does not map well when patches are being revised. A
normal patch will go through multiple revisions as it is reviewed and
modified by others. This often leads to synchronization issues as well
as errors with patch revisions. Ultimately it is the responsibility of
the developer to generate a patch that will apply cleanly to the
mainline.

For this reason most internal developers should seriously consider
{\em stacked git}. Stacked git is designed to make patch development
easier and less of a headache. The basic mode of operation is for a
developer to intialize a patch for a new feature and then continuously
apply changes to the patch. Stacked Git allows a developer to layer a
series of patches on top of a local git repository, without causing
the repository to unsync due to local commits. Basically, the
developer never commits changes to the repository itself but instead
commits the changes to a specific patch. The local patches are managed
using stack operations (push/pop) which allows a developer to apply
and unapply patches as needed. Stacked git also manages new changes to
the underlying git repository as a result of a pull operation and
prevents collisions as changes are propagated upstream. For instance
if you have a local patch that is applied to the mainline as a commit,
when the commit is pulled down the patch becomes empty because it is
effectively identical to the mainline. It also makes incorporating
external revisions to a patch easier. Stacked git is installed on {\em
newskysaw} in \verb./opt/vmm-tools/bin/. 

Brief command overview:
\begin{itemize}
\item \verb.stg init. -- Initialize stacked git in a given branch
\item \verb.stg new. -- create a new patch set, an editor will open
asking for a commit message that will be used when the patch is
ultimately committed.
\item \verb.stg pop. -- pops a patch off of the source tree.
\item \verb.stg push. -- pushes a patch back on to a source tree.
\item \verb.stg export. -- exports a patch to a directory as a file
that can then be emailed.
\item \verb.stg refresh. -- commits local changes to the patch set at
the top of the applied stack.
\item \verb.stg fold. -- Apply a patch file to the current
patch. (This is how you can manage revisions that are made by other developers).
\end{itemize}

You should definately look at the online documentation to better
understand how stacked git works. It is not required of course, but if
you want your changes to be applied its up to you to generate a patch
that is acceptable to a core developer. Ultimately using Stacked git
should be easier than going it alone.


All patches should be emailed to Jack for inclusion in the
mainline. An overview of the organization is given in
Figure~\ref{fig:process}. You should assume that the first revision of
a patch will not be accepted, and that you will have to make
changes. Furthermore, the final form of the patch most likely will not
be exactly what you submitted. 

 
\begin{figure}[t]
\begin{center}
\includegraphics[height=3.5in]{dev_chart.pdf}
\end{center}
\caption{Development organization}
\label{fig:process}
\end{figure}


\subsection{Kitten}

Writing code for Kitten follows essentially the same process as
Palacios. The difference is that the patches need to be emailed to the
Kitten developers. To send in a patch, you can just email it to the
V3Vee development list.


Also, instead of Stacked git you should use Mercurial patch
queues. This feature is enabled in your .hgrc file.
\begin{verbatim}
[extensions]
hgext.mq=
\end{verbatim}

Mercurial queues use the same stack operations as stacked git, however
it does not automatically handle the synchronization with pull
operations. Before you update from the central version of Kitten you
need to pop all of the patches, and then push them once the update is
complete.

Basically:
\begin{verbatim}
hg qpop -a
hg pull
hg update
hg qpush -a
\end{verbatim}


%Also, remember that Kitten is not a Northwestern project and is being
%developed by professional developers at Sandia National Labs. So keep
%in mind that you are representing Northwestern and the rest of the
%Palacios development group. We are collaborating with them because
%Kitten and the resources they have are very important for our research
%efforts. They are collaborating with us because they believe that
%Palacios might be able to help them. Therefore it is important that we
%continue to ensure that they see value in our collaboration. In plain
%terms, we need to make sure they think we're smart and know what we're
%doing. So please keep that in mind when dealing with the Kitten group.


\section{Networking}

Both the Kitten and GeekOS substrates on which Palacios can run
currently include drivers for two simple network cards, the NE2000,
and the RTL8139.  The Kitten substrate is acquiring an ever increasing
set of drivers for specialized network systems.   A lightweight
networking stack is included so that TCP/IP networking is possible
from within the host OS kernel and in Palacios.  

When debugging Palacios on QEMU, it is very convenient to add an
RTL8139 card to your QEMU configuration, and then drive it from within
Palacios.  QEMU can be configured to provide local connectivity to the
QEMU emulated machine, including bridging the emulated machine with a
physical network.  Local connectivity can be done with redirection, or
with a TAP interface.  For global connectivity, a TAP interface must
be used; it is bridged to a physical interface.

\section{Configuring the development host's QEMU network}

To get local connectivity with redirection, no networking changes on
the host are needed.  However, people usually want to use TAP-based
networking, which does require changes.  For one thing, TAP interfaces
can be inspected with tools like wireshark, which makes for much
easier debugging of network code.

In order to get QEMU networking to function, it is necessary to create
TAP interfaces, and, optionally, to bridge them to real networks.  A
developmet machine typically will have several TAP interfaces, and
more can be created.  Generally, each developer should have a TAP
interface of his or her own.  In the following, we will use our
development machine, newskysaw, as an example.

To set up a TAP interface on newskysaw, the following comand is used:
\begin{verbatim}
/root/util/tap_create tapX
\end{verbatim}

When QEMU runs with a tap interface, it will use /etc/qemu-ifup to
bring up the interface.  On newskysaw, /etc/qemu-ifup looks like this:

\begin{verbatim}
#!/bin/bash
echo "Executing /etc/qemu-ifup - no external bridging"
echo "Bringing up $1 for bridged mode..."
NET=`echo $1 | cut -dp -f2` 
sudo /sbin/ifconfig $1 172.2${NET}.0.1 up
sleep 2
\end{verbatim}

The interface tap$N$ is brought up with the IP address 172.2$N$.0.1.
ifconfig will also create a routing rule that sends 172.2$N$.0.1/16
traffic to tap$N$.  The upshot is that if the code running in QEMU
uses an IP address in this network (for example: 172.2$N$.0.2), you
will be able to talk to it from newskysaw.  For example, from
newskysaw, if you ping 172.21.0.2, the packet (and ARP) will go out via
tap1.  The source address will appear to be 172.21.0.1.  The QEMU
machine will see these packets on its interface, and the software
controling its interface can respond to 172.21.0.1.  

This form of networking is local to the machine.  You can also bridge
a TAP interface with a physical interface.  The result of this is that
a packet sent on it will be sent on the physical interface.  To do
this requires more effort (and is not set up by default on newskysaw).
As an example, consider that on newskysaw, the physical interface eth1
is connected to a private network switch to which the lab test
computers (v-test-amd, v-test-amd2, etc.) are connected.  To bridge,
for example, tap10, to this interface, you would do the following
(with root's help):
\begin{enumerate}
\item You need to bring up eth1 (ifconfig eth1 up {\em address}
netmask {\em mask}).  It is important that the address and mask you
choose are appropriate for the network eth1 is connected to.
\item You would bring up tap10 without an address:  /sbin/ifconfig
tap10 up
\item You would bridge tap10 and eth1:  /usr/sbin/brctl addif br0
tap10; /usr/sbin/brctl addif eth1.  This assumes that br0 was
previously created. 
\end{enumerate}

Bridging tap$N$ with eth1 will only work (where ``work'' means sending
a packet on the network and making the packet visible on localhost) if
the IP address in the code running in QEMU is set correctly.  This
means that it needs to be set to correspond to the network of eth1).  
For the newskysaw configuration, this is a 10-net address.


\subsection{Configuring Kitten}

Kitten needs to be explicitly configured to use networking. Currently
only a subset of the networking configurations are supported. To
enable an ethernet network you should enable the following options:

\begin{itemize}
\item Enable TCP Support
\item Enable UDP Support
\item Enable socket API
\item Enable ARP support
\end{itemize}

The other options are not supported, and enabling them will probably
break the kernel compilation.

To allow Kitten to communicate with the Qemu network card you also
need to enable the appropriate device driver: \newline
\verb.NE2K Device Driver (rtl8139).

The driver then needs to be listed as a Kernel Command Line argument
in the {\em ISOIMAGE configuration}. To do this add
\verb.net=rtl819. to the end of the argument string.

Kitten currently does not support the dynamic assignment or IP
addresses at runtime. Because of this it is necessary to hardcode the
IP address into the device driver. For the rtl8139 network driver look
in the file {\em drivers/net/ne2k/rtl8139.c} for the function
\verb.rtl8139_init..

There shoule be a block of code that looks like the following:
\begin{verbatim}
  struct ip_addr ipaddr = { htonl(0 | 10 << 24 | 0 << 16 | 2 << 8 | 16 << 0) }; 
  struct ip_addr netmask = { htonl(0xffffff00) }; 
  struct ip_addr gw = { htonl(0 | 10 << 24 | 0 << 16 | 2 << 8 | 2 << 0) };
\end{verbatim}

This sets the ip address as 10.0.2.16, netmask 255.255.255.0 and
gateway address 10.0.2.2. Change these assignments to match your configuration.


\paragraph*{Kitten as the Guest OS}

When running Kitten as a VM, the above applies except that you will
want to enable the {\em VMNET} device driver instead of the {\em rtl8139}.


\subsection{Running with networking}

\paragraph*{TAP Interface}
Running with a TAP interface provides either local or global
connectivity (depending on how the TAP interface is configured and/or
bridged).  From the perspective of the QEMU command line, both look
the same, however.  You simply add something like this to the command
line:
\begin{verbatim}
-net tap,ifname=tap2 -net nic,model=rtl8139
\end{verbatim}
The first \verb.-net. option indicates that you want to use a tap
interface, specifically \verb.tap2..   The second \verb.-net. option
specifies that this interface will appear to code in the QEMU machine
to be a network interface card of the specific model RTL8139.  Note
that this is a model for which we have a driver.  If tap2 were
bridged, we'd get global connectivity.  If not, we would just get
local connectivity.  


\paragraph*{Redirection}
It is also possible to achieve limited local connectivity even if you
have no TAP support on your development machine.  In redirection, QEMU
essentially acts as a proxy, translating TCP or other connections and
low-level packet operations on the network interface in the QEMU
machine.  For example, the following options will redirect the host's
9555 port to the QEMU machine's 80 port:
\begin{verbatim}
-net user -net nic,model=rtl8139  -redir tcp:9555:10.10.10.33:80
\end{verbatim}
The first \verb.-net. option indicates that we are using user-level
networking (proxying).  The secod \verb.-net. option indicates that
this user-level network will appear in the QEMU machine as an RTL8139
network card.   The \verb.-redir. option indicates that connections on
localhost:9555 will be translated into equivalent packet exchanges on
the RTL8139 card in the QEMU machine.  However, we have to tell QEMU
which IP address and port to use on the QEMU machine's side.  This is
what the 10.10.10.33 address, and port 80 are.  In the example, if you
access port 9555 on localhost, say with:
\begin{verbatim}
telnet localhost 9555
\end{verbatim}
The packets that appear in the QEMU machine will be bound for
10.10.10.33, port 80.  Within the QEMU machine, your RTL8139 interface
had better then be up on that address. 

Qemu has many options to build up a virtual or real networking. See
http://www.h7.dion.ne.jp/$\sim$qemu-win/HowToNetwork-en.html for more
information.


For more questions, talk to Jack, Lei, or Peter.

\end{document}