+++ /dev/null
-This is a set of guidelines for how to understand and write code for
-the V3 Hypervisor.
-================================
-
-"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."
-Translation: Use the f@$#ing spacebar.
-
-Fail Stop:
-Because booting a basic linux kernel results in over 1 million VM exits
-it is 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.
-
-
-Function names:
-To ease porting externally visible function names should be used
-rarely and have unique names. Currently we have several techniques for
-achieving this:
-
-1. #ifdefs in the header file
-When the V3 Hypervisor is compiled it defines the symbol
-__V3VEE__. Any function that is not needed outside the Hypervisor
-context should be inside an #ifdef __V3VEE__ block, this will make it
-invisible to the host environment.
-
-2. static functions
-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.
-
-3. "v3_" prefix
-Major interface functions should be named with the prefix "v3_". This
-allows 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.
-
-
-
-
-Debugging Output:
-Debugging output is sent through the host os via functions in the
-os_hooks structure. These functions have various wrappers of the form
-Print*, with printf style semantics.
-
-Two functions of note are PrintDebug and PrintError.
-
-PrintDebug:
-Should be used for debugging output that will often be
-turned off selectively by the VMM configuration.
-
-PrintError:
-Should be used when an error occurs, this will never be optimized out
-and will always print.
-
+++ /dev/null
-Once you have built a vmm.img file (see SETUP.LINUX for how to set up
-and test the development environment needed to do this), you can do
-the following:
-
-- dd vmm.img to a floppy and boot from it
-- network boot from vmm.img using PXE
-- use mkisofs to build a bootable cdrom from vmm.img
-- boot from vmm.img using qemu or other emulator
-
-All but the last option (qemu) are very site-dependent.
-
-To boot from vmm.img using qemu, do the following:
-
-Make sure qemu is installed. You will need at least version 0.9.1 for
-the necessary support of AMD SVM virtualization extensions.
-
-If you would like to install qemu, a copy is in the repository:
-
-export DEVROOT=/path/to/your/vmm-tools
-
-untar $DEVROOT/utils/qemu-0.9.1.tar.gz and follow instructions for
-building and installing it. Notice that you can use the --prefix
-configure option to choose where to put it.
-
-Assuming it's installed:
-
-export QEMUROOT=/path/to/your/qemu-install
-
-You can then run your vmm.img thus:
-
-$QEMUROOT/bin/qemu-system-x86_64 -m 1024 -serial file:serial.out -fda vmm.img
-
-On running this, you should see the vmm boot in a window, accompanied
-by lots of debugging output being spit into the file serial.out.
-
-You can add other options to, for example, provide a boot cd, network
-cards, etc.
-
-
-
-
+++ /dev/null
-Once you have built a vmm.img file (see SETUP.WINDOWS for how to set
-up and test the development environment needed to do this), you can do
-the following:
-
-- dd vmm.img to a floppy and boot from it (linux)
-- network boot from vmm.img using PXE (linux)
-- use mkisofs to build a bootable cdrom from vmm.img (linux)
-- boot from vmm.img using qemu or other emulator
-
-All but the last option (qemu) are very site-dependent.
-
-To boot from vmm.img using qemu, do the following:
-
-Make sure qemu is installed. You will need at least version 0.9.1 for
-the necessary support of AMD SVM virtualization extensions.
-
-If you would like to install qemu, a copy is in the repository.
-Here is how to install it.
-
-export DEVROOT=/path/to/your/vmm-tools
-cd $DEVROOT/devtools
-unzip $DEVROOT/utils/Qemu-0.9.1-windows.zip
-export QEMU=$DEVROOT/devtools/Qemu-0.9.1-windows
-
-A subtle thing in using this windows port of qemu from a cygwin
-environment is that it uses the *windows* paths, not the cygwin paths.
-Sort of. This is a bit fuzzy.
-
-A simple trick is to copy your vmm.img and whatever else *to* $QEMU
-and then run a modified qemu.bat file from there. Note that it is important
-that the batch file run $QEMU/bin/qemu-system-x86_64. See below
-for a more complete example.
-
-You can also run qemu and generate the path in a somewhat convulted
-way. For example, if I develop in $DEVROOT/vmm-hack1/build, and
-$QEMU is as above, then, I can run as follows:
-
-$QEMU/bin/qemu-system-x86_64.exe -L ../../devtools/Qemu-0.9.1-windows/Bios -m 1024 -serial file:serial.out -fda vmm.img
-
-On running this, you should see the vmm boot in a window, accompanied
-by lots of debugging output being spit into the file serial.out.
-
-You can add other options to, for example, provide a boot cd, network
-cards, etc.
-
-
-
-
+++ /dev/null
-You can set up the development tools on Linux by running ./SETUP_DEV_ENV.pl.
-
-If you do not already have bcc and related tools installed, you
-need to uncomment the parts of ./SETUP_DEV_ENV.pl that will build them.
-
-Now test:
-
-export DEVROOT=/path/to/your/vmm-dev
-export LOCATION=$DEVROOT/devtools
-
-cd $DEVROOT/build
-
-export PATH=$PATH:$LOCATION/bin
-
-make world
-
-This will build a vmm.img floppy image in geekos/build. You can also build a boot ISO image by running:
-
-> make geekos-iso
-
-Which will generate a test.iso image in $DEVROOT/build
+++ /dev/null
-Although our development environment is primarily geared to Linux, it
-is possible to develop and test on Windows, using Cygwin. To do so,
-do the following, adapting it to your local environment.
-
-To develop on windows, you will install:
-
-- a specific version of binutils (targetting i386-elf)
-- a specific version of gcc (targetting i386-elf)
-- a specific version of nasm, patched for VT and SVM instructions
-- the as86, bcc, and ld86 tools from Dev86 (these are needed to build
-the bioses and other vm boot package components)
-
-
-To start, install cygwin (see cygwin.org). We have done a complete
-installation ("all" -> "install") in our environment, and would
-recommend it.
-
-Run a bash shell.
-
-Check out vmm-dev from CVS, or unpack a copy from a tarball.
-In the following, we assume /home/pdinda/Codes/vmm-dev
-is the checked-out directory
-
-export DEVROOT=/home/pdinda/Codes/vmm-dev
-mkdir $DEVROOT/devtools
-export LOCATION=$DEVROOT/devtools
-
-Now build and install binutils into $LOCATION:
-
-cd $DEVROOT/utils
-tar xfz binutils-2.16.91.0.7.tar.gz
-cd binutils-2.16.91.0.7
-./configure --prefix=$LOCATION/i386 --target=i386-elf --disable-nls
-make -j 4 all
-make install
-
-Now build and install gcc:
-
-cd $DEVROOT/utils
-tar xfz gcc-3.4.6.tar.gz
-export PATH=$LOCATION/i386/bin:$PATH
-cd gcc-3.4.6
-./configure --prefix=$LOCATION/i386 --target=i386-elf --disable-nls --enable-languages=c,c++ --without-headers
-make -j 4 all-gcc
-make install-gcc
-
-Now build and install the patched nasm:
-
-cd $DEVROOT/utils
-tar xfz nasm-0.98.39.tar.gz
-cd nasm-0.98.39
-patch < ../vmx.patch
-patch < ../nasm-install.patch
-./configure --prefix=$LOCATION
-make
-make install
-
-install bcc and other components of dev86:
-
-cd $DEVROOT/utils
-tar xvf Dev86src-0.16.17.tar.gz
-cd dev86-0.16.17
-make as86 ld86 bcc86
-make -C cpp
-cp as/as86.exe bcc/bcc.exe bcc/bcc-cc1.exe cpp/bcc-cpp.exe ld/ld86.exe $LOCATION/bin
-
-Now test:
-
-cd $DEVROOT/vmm-hack1/build
-export PATH=$PATH:$LOCATION/bin
-
-make world
-
-This should succeed, leaving you with a vmm.img file.
