The Kernel

Site Home Page The UML Wiki UML Community Site The UML roadmap What it's good for Case Studies Kernel Capabilities Downloading it Running it Compiling Installation Skas Mode Incremental Patches Test Suite Host memory use Building filesystems Troubles User Contributions Related Links The ToDo list Projects Diary Thanks Contacts
Tutorials The HOWTO (html) The HOWTO (text) Host file access Device inputs Sharing filesystems Creating filesystems Resizing filesystems Virtual Networking Management Console Kernel Debugging UML Honeypots gprof and gcov Running X Diagnosing problems Configuration Installing Slackware Porting UML IO memory emulation UML on 2G/2G hosts Adding a UML system call Running nested UMLs
How you can help Overview Documentation Utilities Kernel bugs Kernel projects
Screenshots A virtual network An X session
Transcripts A login session A debugging session Slackware installation
Reference Kernel switches Slackware README
Papers ALS 2000 paper (html) ALS 2000 paper (TeX) ALS 2000 slides LCA 2001 slides OLS 2001 paper (html) OLS 2001 paper (TeX) ALS 2001 paper (html) ALS 2001 paper (TeX) UML security (html) LCA 2002 (html) WVU 2002 (html) Security Roundtable (html) OLS 2002 slides LWE 2005 slides
Fun and Games Kernel Hangman Disaster of the Month
| ### The Kernel UML is a fully-functional Linux kernel. It runs its own scheduler and VM system, relying on the host kernel only for the equivalent of hardware support. The virtual machine is completely configurable through the command line, allowing its memory, available devices, and their configurations to be specified. The available command line switches are described here.
Hardware support
UML hardware support comes in the form of virtual devices which use resources on the host. It supports all the usual types of devices that a physical system does: Block devices - UML block devices are normally associated with a file on the host which contains a filesystem. This file is made to look like a block device inside the virtual machine, and the filesystem on it is mounted just as a filesystem on a physical disk is mounted in a native kernel. A block device file may also contain a swap signature, in which case, UML will be willing to swap onto it. It can also be treated as a raw disk, which isn't mounted, but instead has data read from and written to it with a utility such as dd. Block devices can also be attached to anything on the host which resembles a file. Examples include CD-ROMS, floppies, physical disks and partitions, and memory devices such as /dev/mem. UML block devices can be layered, with a read-only device having a copy-on-write (COW) read-write device on top of it. This acts as a single read-write device, with the modifications to the read-only layer being recorded in the read-write COW layer. This allows multiple machines to share a filesystem, allowing a large saving in disk space on the host. If you are doing development, and plan on crashing UML frequently, then COW-ing your root filesystem allows you to avoid fscking it on each boot by deleting the COW file and reusing the clean backing file. This is described further here. Consoles and serial lines - These are almost identical, sharing most of their code, and differing only where they need to present different interfaces to the rest of the kernel. They can be attached to a number of different interfaces on the host, including file descriptors, ptys, ttys, pts devices, and xterms. More information about this is here. By default, the main console is attached to file descriptors 0 and 1 (stdin and stdout), the other consoles come up in xterms, and the serial lines attach themselves to ptys. Network devices - Similarly, the network driver can use a variety of host interfaces to exchange packets with other virtual machines, the host, and the rest of the network. To construct a completely virtual network, with no access to the host networking, UML can use a hub daemon to forward packets from one virtual machine to another or it can set up a multicast network and have the machines send packets directly to each other. To access the host and the outside network, UML can use either ethertap or slip interfaces on the host. A more complete description of this is here. SCSI devices - The SCSI subsystem compiles into UML cleanly and is available as a config option. The only low-level driver currently available for it is the scsi-debug driver, which operates in memory. It grabs 8M at boot and runs a little SCSI ramdisk in it. USB devices - James McMechan has written a UML hcd driver. I haven't played with it yet, but it apparently allows UML to control physical USB devices that the host hasn't claimed. Sound - Thanks to the warped mind of Steve Schmidtke, UML has sound support. The UML sound driver relays the UML's /dev/sound/dsp and /dev/sound/mixer out to the host's /dev/sound/dsp and /dev/sound/mixer. The UML needs appropriate permissions to access these devices on the host. PCI hardware - There are two efforts to allow UML two access physical PCI hardware, allowing it to load and run the native drivers for those devices. Jon Smirl has been working on a Virtual PCI patch, and has been having some success with getting UML to access the host's frame buffer. His latest announcement is here . Totally independently of this, Eitan Yarden posted the abstract to his thesis and the patch, which implements PCI hardware access from UML. His effort is functional enough that he was able to drive an ethernet card from the inside UML. This isn't in UML yet, but will be merged at some point.
Hot-plugging devices
The management console is a low-level interface into the kernel. Among other things, it allows UML devices to be added to and removed from a running system. Currently, the block devices and network devices can be hot-plugged. In time, this will be extended to the rest of the devices, so you will be able to construct, destroy, and rebuild essentially the entire system without having to reboot it.
Generic kernel functionality
UML runs its scheduler independently of the host scheduler - the host scheduler simply implements the decisions made by the UML scheduler. Similarly, UML runs its own VM system, allocating backing memory from a pool that it considers to be physical memory, mapping that memory as needed into its process virtual address spaces and its own virtual memory. If needed, and it has swap configured, it will swap. Basically, anything in Linux that's not hardware-specific just works. This includes kernel modules, the filesystems, software devices, and network protocols. Also, SMP and highmem are supported. They need to be configured in, and once they are, they work the same as on any other architecture that supports them.

Hosted at