Driver Domain
A driver domain is unprivileged Xen domain that has been given responsibility for a particular piece of hardware. It runs a minimal kernel with only that hardware driver and the backend driver for that device class. Thus, if the hardware driver fails, the other domains (including Dom0) will survive and, when the driver domain is restarted, will be able to use the hardware again.
As disk driver domains are not currently supported, this page will describe the setup for network driver domains.
Benefits
- Performance
This will eliminate dom0 as a bottleneck. All device backend in dom0 will result dom0 to have bad response latency.
- Enhanced reliability
Hardware drivers are the most failure-prone part of an operating system. It would be good for safety if you could isolate a driver from the rest of the system so that, when it failed, it could just be restarted without affecting the rest of the machine.
- Enhanced security
Because of the nature of network protocols and routing, there is a higher risk of an exploitable bug existing somewhere in the network path (host driver, bridging, filtering, &c). Putting this in a separate, unprivileged domain limits the value of attacking the network stack: even if they succeed, they have no more access than a normal unprivileged VM.
Requirements
Having a system with a modern IOMMU (either AMD or VT-d version 2) is highly recommended. Without IOMMU support, there's nothing to stop the driver domain from using the network card's DMA engine to read and write any system memory. Furthermore, without IOMMU support, you cannot pass through a device to an HVM guest, only PV guests.
If you don't have IOMMU support, you can still use PV domains to get the performance benefit, but you won't get any security or stability benefits.
Setup
Setting up the driver domain is fairly straightforward, and can be broken down into the following steps:
Set up a VM with the appropriate drivers
These drivers include the hardware driver for the NIC, as well as drivers to access xenbus, xenstore, and netback. Any Linux distro with dom0 Xen support should do. The author recommends xen-tools.
You should also give the VM a descriptive name; "domnet" would be a sensible default.
These are scripts that listen for vif creation events on xenstore, and respond by doing the necessary setup with netback.
The easiest way to do this is by installing the full set of xen tools in the VM -- either by installing the xen-utils package, or running "make install-tools" inside the VM.
Use PCI passthrough to give the VM access to the hardware NIC
This has a lot of steps, but is fairly straightforward. Details for doing so can be found here: Xen PCI Passthrough
Set up network topology in the VM
This is identical to the setup you would do in domain 0. Normally this would be bridging, but NAT or openvswitch are other possibilities. See more information at Host_Configuration/Networking.
Configure guests
You now have a fully-configured driver domain. To use it, simply add "backend=[domain-name]" to the vifspec of your guest vif; for example:
vif = [ 'bridge=xenbr0, mac=00:16:3E:0d:13:00, model=e1000, backend=domnet' ]
