Device Model Stub Domains

What Are Device Model Stub Domains?

A stub domain is a specialized system domain running on a Xen host used in order to disaggregate the control domain ("domain 0"). Many stub domains are based on the Mini-OS tiny OS (see extras/mini-os in the Xen source code). Some work has been done on Linux stub domains.

In the specific case of a device model stub domain this system domain is used to run the Qemu device model associated with an HVM domain. Often the Qemu device model would be a normal process running in the domain 0 environment.

Device model stub domains were first implemented by Samuel Thibault in Xen 3.3 in 2008.

Why Device Model Stub Domains?

There are several advantages to running a device model in a stub domain instead of as a process in domain 0.

• Security

A device model stub domain is automatically deprivileged (using XEN_DOMCTL_set_target) such that it only has privilege over the specific HVM domain that it is related to.

While a process in domain 0 can be constrained, for example by using SELinux or chroot techniques these are more complex to deploy.

• Scalability

A device model stub domain is not constrained by the resources allocated to the control domain and nor does it contend with other uses of those resources. Instead has its own resources allocated to it.

• Isolation

A stub domain does not contending with other processes in domain 0 (including other device models, control tools, regular user processes) etc. This improves the isolation within the system and ensures e.g. that guest performance is not impacted by load in the control domain.

• Performance

When a device model runs as a process in the control domain it not only has to contend with other processes but is actually subject to double scheduling. That is when it is time for the device model to do some work it has to first wait for the control domain to be scheduled by the hypervisor and then wait for the control domain scheduler to schedule the specific process. Since a stub domain runs only a single process this second schedule is avoided.

Running workloads which make extensive use of emulated devices show significant benefits when using a device model stub domain.

Even workloads which do not use emulated devices may show benefits e.g. in boot time before switching to non-emulated I/O paths.

For more information, background and performance numbers on device model stub domains please see Samuel Thibalt's original XenSummit presentation and the associated blog post.

Building The Device Model Stub Domain Binary

The device model stub domain is built by default and is normally installed as /usr/lib/xen/boot/ioemu-stubdom.gz.

If you want to build just the stub domains without building the hypervisor and tools etc then you can use the install-stubdom Makefile target:

   $ make install-stubdom

Enabling Device Model Stub Domain For A Guest

Using the current xl toolstack the a device model stub domain can be enabled for a guest by using the device_model_stubdomain_override option in your guest configuration file:

   device_model_stubdomain_override = 1

In older toolstacks (xm/xend as well as xl in Xen 4.1) you can enable a device model stub domain for a guest by specifying the magic string stubdom-dm as your device model:

   device_model = "stubdom-dm"

If you wish you may freely mix the use of stub domain device model and dom0 process device model on a per domain basis within a single system.

Note that the frontend drivers in minios are not hardened against malicious backends; so if you are using both device model stub domains and driver domains, the guests with device model stub domains are vulnerable to a malicious driver domain. Of course without a driver domain, the backend runs in dom0 with complete privilege, so driver domains are still a robustness improvement.