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.

• make xconfig
• make config
• make menuconfig

Of course, there are a range of configuration options. In the following, we note only the most important. The indicated values are defaults for the simplest interaction between Kitten and Palacios.

• Target Configuration
  • System Architecture -- you probably want to set this to PC-Compatible, unless you are working on Red Storm.
  • Processor Family -- you want to set this to either AMD-Opteron/Athlon64 or Intel-64/Core2, depending on whether you have a 64 bit AMD or 64 bit Intel processor.
• Virtualization
  • Include Palacios VMM -- this will link against the Palacios library (on)
  • Path to pre-built Palacios tree -- directory where libv3vee.a can be found.
  • Path to guest image -- location of the test guest OS image that will be embedded. We will say more about this later. Essentially, however, a guest image consists of a blob that begins with an XML description of the desired guest environment and the contents of the remainder of the blob. The remainder of the blob usually contains disk or cd images. The default path is ../palacios/guest_os.img, where it will find the simple guest created during the Palacios build process.
• Networking
  • Enable LWIP TCP/IP stack. This activates a simple TCP/IP stack that things like NETDISK can use. (off)
• Device Drivers
  • VGA Console -- driver for basic video. (on)
  • Serial Console -- driver for serial port console. (on)
  • VM Console -- driver for Kitten console on top of Palacios. If Kitten is run as a guest, and it has VM Console on, then it can output cleanly via the Palacios OS Console device (on).
  • NE2K Device Driver -- driver for NE2K and RTL8139 network cards (off)
  • VM Network Driver -- driver for Kitten network output using Palacios. If Kitten is run as a guest, and it has VM Network Driver, then it can send and receive packets using the Palacios Linux virtio network device. (off)
• ISOIMAGE configuration: Kitten kernel arguments. Note that this is NOT for the guest image, but rather for the Kitten image. You can leave this alone. For Palacios operation, it's important that the option console=serial appears. If the NE2K/RTL8139 driver should be used net=rtl8139 should appear.
• Kernel Hacking
  • Kernel Debugging -- here you can turn on various Kitten Linux-like debugging features. Only a few are noted below:
    • Compile the kernel with debug info -- if this is on, you will have debugging information compiled in (-g)
    • KGDB -- if you have this enabled, you will be able to attach to the running kernel from the GDB debugger. This means you can also attach to Palacios, which is embedded. If you want to debug Palacios using KGDB, be sure to turn on debugging in Palacios as well.
• Include Linux compatability layer -- if this is on, you can selectively add Linux system calls and other functionality to Kitten. Kitten is able to run Linux ELF executables as user processes with this layer. (off)

The guest OS that is to be booted as a VM is included as a blob pointed to by ``Path to guest image''. The blob starts with an XML description of the guest, followed by other chunks of data used, for example, as the content of virtual hard drives or CD ROMs. Please see Section 6 for basic information on how to use the guest builder to assemble a guest OS blob.

By default, the init task that is executed after Kitten boots (located in user/hello_world) does a number of Kitten tests. One of these is a test of the VMM API, which is implemented using Palacios. When this test is done, a VM is created, configured according to the XML, and the guest OS blob is launched in it.