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
Xen 3.3 Feature: HVM Device Model Domain
