Xen 3.3 Feature: HVM Device Model Domain

From Samuel Thibault:
To provide HVM domains with virtual hardware, Xen uses a modified version of qemu, ioemu.  It used to run in dom0 as a root process, since it needs to directly access disks and tap network.  That poses both a problem of security, as the qemu code base was not particularly meant to be safe, and a problem of efficiency, as when an HVM guest performs an I/O operation, the hypervisor gives hand to dom0, which then may not schedule the ioemu process immediately, leading to uneven performances.
In Xen 3.3, ioemu can be run in a Stub Domain (see previous article on Stub Domains).  That means that for each HVM domain there is a dedicated Device Model Domain that processes the I/O requests of the HVM guest.  The Device Model Domain then uses the regular PV interface to actually perform disk and network I/O.  That permits to restrict any harm that ioemu could do to what the regular PV interface enforces.  On the performance point of view, the benefit is twofold: since ioemu runs directly in the same addressing space as Mini-OS, it runs more efficiently: the cost of e.g. select(), clock_gettime(), etc. is reduced a lot; since it runs as a domain, the hypervisor can directly schedule it, which permits to limit the latency of I/O operations at a minimum.  The result is that disk performance gets even closer to native, while network bandwidth gets doubled!
See Summit slides:
http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf