We now have PCI passthrough support in QEMU upstream, this was one of the missing pieces needed to have a full featured QEMU device model. But there is still more work to do on it.
Why do we use QEMU?
We use QEMU in Xen to emulate a part of the hardware, in particular a disk, a network card and the graphic output. So a guest does not need to be modified in order to run under Xen. Even with a modified guest, QEMU can be used to handle the graphic output of the guest, or as a backend for a paravirtualized disk or network card.
A blog post a year ago mentions that we had Xen support in QEMU, this was the first part needed to run a Xen guest with QEMU upstream. Now, with the PCI passthrough support upstreamed, that one large piece of code closer to a full featured QEMU upstream.
What is PCI passthrough?
Also known as device assignment, PCI passthrough is here to assign a real PCI device to a guest, like a network card or a sound card. This give full and direct access to the PCI device from a fully virtualized guest.
To use it, take a look at our wiki: PCI passthrough with Xen 4.2 as there is no change compared to the traditional qemu-dm. You can take a look here as well: Xen PCI Passthrough for more general information about PCI passthrough.
How long does it take?
Nine months ago, the first “Request For Comment†set of patches have been sent to qemu-devel and since, not less than 13 revisions were necessary to clean up the code and have a better integration with the QEMU ecosystem. It has been hard to get review of those patches, especially the patches that touch to the generic part of QEMU. But thanks to Konrad Rzeszutek Wilk, Stefano Stabellini, Michael S. Tsirkin and Jan Kiszka for their reviews, now, the code is easier to read than it was in qemu-xen-traditional fork.
What’s next?
So the version 1.2 of QEMU will be released with Xen PCI passthrough support, and Xen 4.2 will support the assignment of a PCI device with QEMU upstream. But QEMU upstream, or qemu-xen as it is called in Xen tool stack, is not yet the default device model. There is still some issue to resolved and we are working on it. One feature that does not work yet is live migration due to the lake of dirty bit logging during migration. But that is another story. Once everything works with QEMU, we intend to change the default device model. This should happen with the Xen 4.3 release.