From: Jack Lange Date: Fri, 1 May 2009 19:33:24 +0000 (-0500) Subject: removed internal/outdated documentation X-Git-Url: http://v3vee.org/palacios/gitweb/gitweb.cgi?p=palacios.git;a=commitdiff_plain;h=421c054f9e4e08d0cf8b31ee56a396b0792588f1 removed internal/outdated documentation --- diff --git a/CODING_GUIDELINES b/CODING_GUIDELINES deleted file mode 100644 index c9e7f46..0000000 --- a/CODING_GUIDELINES +++ /dev/null @@ -1,60 +0,0 @@ -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. - diff --git a/RUNNING.LINUX b/RUNNING.LINUX deleted file mode 100644 index b65a73a..0000000 --- a/RUNNING.LINUX +++ /dev/null @@ -1,41 +0,0 @@ -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. - - - - diff --git a/RUNNING.WINDOWS b/RUNNING.WINDOWS deleted file mode 100644 index b6e5f8d..0000000 --- a/RUNNING.WINDOWS +++ /dev/null @@ -1,48 +0,0 @@ -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. - - - - diff --git a/SETUP.LINUX b/SETUP.LINUX deleted file mode 100644 index 2fc2693..0000000 --- a/SETUP.LINUX +++ /dev/null @@ -1,21 +0,0 @@ -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 diff --git a/SETUP.WINDOWS b/SETUP.WINDOWS deleted file mode 100644 index 92bfff8..0000000 --- a/SETUP.WINDOWS +++ /dev/null @@ -1,74 +0,0 @@ -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.