Xen Share

I find Xen's inter-domain communication too baroque for my tastes, so I have a prototype of a "xen share" infrastructure, based on earlier work I did on the IBM Research Hypervisor.

You can grab the README, and you can find the series of quilt patches or simply grab the whole mercurial bundle .

Examples

There are several examples of how to use the share transport. None of them are in their final, polished state, hence the very manual setup instructions.

Share Network Driver

The Xen Share infrastructure is used to implement a simple multi-way LAN driver called "xensnet". This is currently activated using the simple "vdevice --create" command as follows:

dom0# vdevice --create net 0 1

This creates a network device, grants access to domains 0 and 1 (which must be already running). You then "modprobe xensnet" in each of those domains, and they will find that network:

dom0# modprobe xensnet
...
dom3# modprobe xensnet
...
dom4# modprobe xensnet

You can use "vdevice --add " to add an additional domain, or "vdevice --remove " to remove one.

Share Block Driver

The Xen Share infrastructure is used to implement a simple block driver. The back end is a userspace program called "xensblk" which uses the /dev/xenshare device to serve requests. It is used to provide a block device to a currently running domain, and is started by the dom0 hotplug scripts.

#dom0: vdevice --create block /test-filesystem 0 1

This creates a block device backed by the file "/test-filesystem" and waits for domain 0 to start running the server (xensblk) to start, tells domain 1 about the device.

Inside domain 1, insert the xensblk module if not done already

modprobe xensblk
mknod /dev/xb b 254 0
mount /dev/xb /mnt

/dev/xenshare device

To expose the xenshare functionality to userspace portably, share_io.c implements /dev/xenshare which allows userspace programs to do scatter-gather operations, map shared pages, etc.

vdevice page

Many problems which make the existing Xen drivers complicated can be traced back to the use of the Xen Store for driver configuration and synchronization (via a mechanism called the "xen bus"). Using a simpler inter-domain transport makes simpler configuration of devices possible, so we're experimenting with a simple device bus called "vdevice".

vdevice simply consists of a page of "type, subtype, numpages, share_ref" entries:

type: defines this device type 1 = network, 2 = disk, etc.
subtype: defines type-specific compatibility (feature) bits. A driver specifies the type of device it drives, and the features it needs. This allows various levels of backwards compatibility.
numpages: indicates how many shared pages the share_ref refers to.
share_ref: indicates the shared pages. The contents of the page(s) is device-dependent.

The plan is that this page will be set up by dom0 tools during boot and restore, and the rest of the time will be changed serially: the domain will acknowledge each addition or remove before the next one is performed. The "vdevice" tool currently manipulates this page.