From Samuel Thibault:
Domain 0 running a lot of components like physical device drivers, the domain builder, ioemu device models, PyGRUB, etc. has been worrisome from a security point of view, particularly since most of them run as root, and thus breaches there would potentially be disastrous. It also poses scalability issues since the hypervisor can not itself schedule them appropriately. The goal of domain 0 disaggregation is thus to move these components to separate domains: driver domain, builder domain, device model domains, etc.
Mini-OS used to be just a small PV kernel serving as a sample of how a PV guest works. In Xen 3.3, it has been extended up to being able to run the newlib C library and the lwIP stack, thus providing a basic POSIX environment, including TCP/IP networking. This permits to quite easily embed an application in a dedicated Xen domain by just recompiling it against that environment.
Everything gets linked together as a kernel which can then just be started like any PV guest kernel. In Xen 3.3, it is thus now possible to have the device model and grub running in their own domains, as described in further blog posts.
On the technical side, the additional features of Mini-OS include:
– Disk frontend
– FrameBuffer frontend
– FileSystem frontend (to access part of the dom0 filesystem)
– Improved Memory management: read-only memory and Copy on Write for zeroed pages
– Bug fixes!
But the simplicity (and thus the efficiency) of Mini-OS is still kept:
– Single address space (in particular, no kernel/user separation, completely
eliminating system call costs)
– Single CPU
– Threads without preemption for Mini-OS internal use, not exposed at the POSIX layer.
Both C and Caml “hello world” samples are provided to get started with developing a stub domain.
See Summit slides:
http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf
Xen 3.3 Feature: Stub Domains
