Added support in Makefile to immediately build guestos image and build_vm on make
Included simple guest iso and guest xml config
The result of this is that Palacios, compiled out of box and linked
with Kitten compiled OOB (+virtualization turned on) will correctly
work and boot a simple guest iso. So now, it basically boils down to:
- download palacios
- download kitten
- make config palacios to get defaults
- make in palacios (libv3vee.a, guest_os.img, build_vm get created)
- make config kitten to get defaults, turn on virtualization
- make isoimage
Now you have a ready to go kitten+palacios+linux guest
config SOCKET
bool "Include Network Socket Support"
- default y
+ default n
help
Enable networking support in Palacios
config TELEMETRY
bool "Enable VMM telemetry support"
- default n
+ default y
help
Enable the telemetry framework in Palacios
-----
config PASSTHROUGH_VIDEO
bool "Enable Passthrough Video"
- default y
+ default n
help
Configures Palacios to map a guest's framebuffer directly
- to the hardware framebuffer
+ to the hardware framebuffer (no longer needed)
config INSTRUMENT_VMM
bool "Enable VMM instrumentation"
config BUILT_IN_STDLIB
bool "Enable Built in versions of stdlib functions"
- default n
+ default y
help
Not all host OSes provide link targets for stdlib functions
Palacios provides internal implementations of these functions, that you can select from this list
config BUILT_IN_STRCASECMP
bool "strcasecmp()"
- default n
+ default y
depends on BUILT_IN_STDLIB
help
This enables Palacios' internal implementation of strcasecmp
config BUILT_IN_ATOI
bool "atoi()"
- default n
+ default y
depends on BUILT_IN_STDLIB
help
This enables Palacios' internal implementation of atoi
endef
+#all
+all: libv3vee.a build_vm guest_os.img
# palacios image - including updated kernel symbols
libv3vee.a: $(palacios)
palacios.asm: palacios
$(OBJDUMP) --disassemble $< > $@
+# guest builder
+build_vm : utils/guest_creator/*.c utils/guest_creator/*.h
+ (cd utils/guest_creator; make)
+ cp utils/guest_creator/build_vm .
+
+guest_os.img: guest_os.iso guest_os.xml build_vm
+ ./build_vm guest_os.xml -o guest_os.img
+
+
# The actual objects are generated when descending,
# make sure no implicit rule kicks in
$(sort $(palacios)) : $(palacios-dirs) ;
--- /dev/null
+
+<!-- This defines a PC VM. The class defines the initial cpu/memory state of the VM. This drives the initialization of CPU registers, as well as BIOS memory mappings.-->
+<vm class="PC">
+
+ <!-- Memory in MB -->
+ <memory>1024</memory>
+
+ <!-- Basic VMM system flags -->
+ <telemetry>enable</telemetry>
+ <paging>nested</paging>
+ <schedule_hz>100</schedule_hz>
+
+
+ <!-- Memory redirections -->
+ <!-- Redirects a guest's memory region to a host physical address -->
+ <memmap>
+ <!-- This region maps the VGA framebuffer to the host's framebuffer -->
+ <region>
+ <start>0xa0000</start>
+ <end>0xc0000</end>
+ <host_addr>0xa0000</host_addr>
+ </region>
+ </memmap>
+
+
+ <!-- List of binary files to include with configuration -->
+ <!-- This is where you add disk images -->
+ <files>
+ <!-- The file 'id' is used as a reference for other configuration components -->
+ <file id="boot-cd" filename="guest_os.iso" />
+ <!--<file id="harddisk" filename="firefox.img" />-->
+ </files>
+
+
+ <!-- List of devices attached to guest -->
+ <!-- The device 'ID' is the device name in the global device registry -->
+ <!-- The device 'name' is the reference to the device instance associated with a VM -->
+ <!-- The name can be used as a reference by other devices -->
+ <devices>
+ <device id="8259A" name="PIC"/>
+ <device id="KEYBOARD" name="keyboard"/>
+ <device id="8254_PIT" name="PIC" />
+ <device id="BOCHS_DEBUG" name="bochs debug"/>
+ <device id="OS_DEBUG" name="os debug" />
+ <device id="LAPIC" name="apic"/>
+ <device id="IOAPIC" name="ioapic">
+ <irq_bus>apic</irq_bus>
+ </device>
+
+ <device id="PCI" name="pci0" />
+
+ <device id="i440FX" name="northbridge">
+ <bus>pci0</bus>
+ </device>
+
+ <device id="PIIX3" name="southbridge">
+ <bus>pci0</bus>
+ </device>
+
+ <device id="IDE" name="ide">
+ <bus>pci0</bus>
+ <controller>southbridge</controller>
+ </device>
+
+
+ <!-- This is a Storage Backend that connects to a frontend -->
+ <!-- The frontend section is passed to the frontend when the backend connects -->
+ <!-- The file tag refers to an 'id' already listed in the file list section above -->
+ <device id="RAMDISK" name="CD0">
+ <file>boot-cd</file>
+ <frontend tag="ide">
+ <model>V3Vee CDROM</model>
+ <type>CDROM</type>
+ <bus_num>0</bus_num>
+ <drive_num>0</drive_num>
+ </frontend>
+ </device>
+
+ <device id="NVRAM" name="nvram">
+ <storage>ide</storage>
+ </device>
+
+ <device id="GENERIC" name="generic">
+ <ports>
+ <start>0x00</start>
+ <end>0x07</end>
+ <mode>PRINT_AND_IGNORE</mode>
+ </ports>
+ <ports>
+ <start>0xc0</start>
+ <end>0xc7</end>
+ <mode>PRINT_AND_IGNORE</mode>
+ </ports>
+ <ports>
+ <!-- DMA 1 page registers -->
+ <start>0x81</start>
+ <end>0x87</end>
+ <mode>PRINT_AND_IGNORE</mode>
+ </ports>
+ <ports>
+ <!-- DMA 2 page registers -->
+ <start>0x88</start>
+ <end>0x8f</end>
+ <mode>PRINT_AND_IGNORE</mode>
+ </ports>
+ <ports>
+ <!-- DMA 1 Misc Registers -->
+ <start>0x08</start>
+ <end>0x0f</end>
+ <mode>PRINT_AND_IGNORE</mode>
+ </ports>
+ <ports>
+ <!-- DMA 2 Misc Registers -->
+ <start>0xd0</start>
+ <end>0xde</end>
+ <mode>PRINT_AND_IGNORE</mode>
+ </ports>
+ <ports>
+ <!-- Serial COM 1 -->
+ <start>0x3f8</start>
+ <end>0x3ff</end>
+ <mode>PRINT_AND_IGNORE</mode>
+ </ports>
+ <ports>
+ <!-- Serial COM 2 -->
+ <start>0x2f8</start>
+ <end>0x2ff</end>
+ <mode>PRINT_AND_IGNORE</mode>
+ </ports>
+ <ports>
+ <!-- Serial COM 3 -->
+ <start>0x3e8</start>
+ <end>0x3ef</end>
+ <mode>PRINT_AND_IGNORE</mode>
+ </ports>
+ <ports>
+ <!-- Serial COM 4 -->
+ <start>0x2e8</start>
+ <end>0x2ef</end>
+ <mode>PRINT_AND_IGNORE</mode>
+ </ports>
+ <ports>
+ <!-- Parallel Port -->
+ <start>0x378</start>
+ <end>0x37f</end>
+ <mode>PRINT_AND_IGNORE</mode>
+ </ports>
+ <ports>
+ <!-- Graphics Card modeerations -->
+ <start>0x3b0</start>
+ <end>0x3bb</end>
+ <mode>PRINT_AND_PASSTHROUGH</mode>
+ </ports>
+ <ports>
+ <!-- Graphics Card modeerations -->
+ <start>0x3c0</start>
+ <end>0x3df</end>
+ <mode>PRINT_AND_PASSTHROUGH</mode>
+ </ports>
+ <ports>
+ <!-- ISA PNP -->
+ <start>0x274</start>
+ <end>0x277</end>
+ <mode>PRINT_AND_IGNORE</mode>
+ </ports>
+ <ports>
+ <!-- ISA PNP -->
+ <start>0x279</start>
+ <end>0x279</end>
+ <mode>PRINT_AND_IGNORE</mode>
+ </ports>
+ <ports>
+ <!-- ISA PNP -->
+ <start>0xa79</start>
+ <end>0xa79</end>
+ <mode>PRINT_AND_IGNORE</mode>
+ </ports>
+ </device>
+ </devices>
+
+
+</vm>
+
+
\includegraphics[height=1.5in]{v3vee.pdf}
\includegraphics[height=1.5in]{logo6.png} \\
\vspace{0.5in}
-Palacios Internal Developer Manual
+Palacios Internal and External 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}. You will also
-want to read the document {\em Building a bootable guest image for
-Palacios and Kitten} in order to understand how to build an extremely
-lightweight guest environment, suitable for testing.
+This manual is written for internal and external 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 the technical report {\em An Introduction to the Palacios Virtual
+Machine Monitor -- Release 1.0}\footnote{It's important to note that
+there have been substantial changes in the build process from 1.0 to
+1.2 and beyond. Hence, the technical report is primarily useful as an
+explanation of the theory of operation of Palacios. This document is
+the one to consult for the build process.} and also has a slight
+working knowledge of {\em git}. You will also want to read the
+document {\em Building a bootable guest image for Palacios and Kitten}
+in order to understand how to build an extremely lightweight guest
+environment, suitable for testing. If you want to configure network
+booting for testing on real hardware, you'll want to read the document
+{\em Booting Palacios/Kitten Over the Network Using PXE}.
Please note that Palacios and Kitten are under rapid development,
hence this manual may very well be out of date!
use the following command instead. The {\em newskysaw} home
directories are NFS-mounted on /home-remote.
-
\begin{verbatim}
git clone /home-remote/palacios/palacios
\end{verbatim}
(e.g., devel) of the internal repository with a 30 minute delay. The
access information is available on the web site (http://v3vee.org).
The web site also includes a publically accessible gitweb interface to
-allow browsing of the public repository.
+allow browsing of the public repository. The clone command looks like
+
+\begin{verbatim}
+git clone http://v3vee.org/palacios/palacios.web/palacios.git
+\end{verbatim}
-This creates a local copy of the repository at {\em ./palacios/}.
+No matter how you clone, the clone command creates a local copy of the
+repository at {\em ./palacios/}.
Note that both {\em newskysaw} and {\em newbehemoth} have all the
tools installed that are needed to build and test Palacios and Kitten.
we are targeting with Palacios. Loosely speaking, core Palacios
developers are internal Kitten developers, and internal Palacios
developers are external Kitten developers. The public repository for
-Kitten is at {\em http://code.google.com/p/kitten}. To simplify things,
-we are maintaining a local mirror copy in {\em /home/palacios/kitten}
-that tracks the public repository.
+Kitten is at {\em http://code.google.com/p/kitten}. To simplify
+things, we are maintaining a local mirror copy on newskysaw in {\em
+/home/palacios/kitten} that tracks the public repository.
-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.
+Kitten uses Mercurial for source management, so you will have to make
+sure the local Mercurial version is configured correctly.
+Specifically you will probably need to add something like the
+following Python path to your shell environment.
\begin{verbatim}
export PYTHONPATH=/usr/local/lib64/python2.4/site-packages/
\begin{verbatim}
hg clone ssh://you@newskysaw.cs.northwestern.edu//home/palacios/kitten
\end{verbatim}
-
+External developers, run
+\begin{verbatim}
+hg clone https://kitten.googlecode.com/hg/ kitten
+\end{verbatim}
Both the Kitten and Palacios clone commands should be run from the
same directory. This means that both repositories should be located at
config LINUX_VIRTIO_BALLOON
bool "Linux Virtio Balloon Device"
- default y
+ default n
depends on PCI
help
Includes the Linux virtio balloon device
config LINUX_VIRTIO_BLOCK
bool "Linux Virtio Block Device"
- default y
+ default n
depends on PCI
help
Includes the Linux virtio block device
config LINUX_VIRTIO_SYM
bool "Linux Virtio Symbiotic Device"
- default y
+ default n
depends on PCI && SYMBIOTIC
help
Includes the Linux virtio symbiotic device
config SYM_SWAP
bool "Symbiotic Swap disk"
- default y
+ default n
depends on SYMBIOTIC_SWAP && (LINUX_VIRTIO_BLOCK || IDE)
help
Includes the symbiotic ram based swap disk
config SYM_SWAP2
bool "Symbiotic Swap disk v2"
- default y
+ default n
depends on SYMBIOTIC_SWAP && (LINUX_VIRTIO_BLOCK || IDE)
help
Includes the symbiotic ram based swap disk
config DISK_MODEL
bool "Disk Performance Model"
- default y
+ default n
depends on LINUX_VIRTIO_BLOCK || IDE
help
Includes Performance model filter for disk operations
