QEMU vs. qemu-traditional update

Here is an update about feature completeness of QEMU compared to the old qemu-traditional.

But first, what is the difference between QEMU and qemu-traditional?

QEMU is the software that can be found at qemu.org, we can also call it QEMU upstream. It’s where all new features are supposed to land.
What we call “qemu-traditional” is the fork of QEMU that has been used by Xen. It became harder and harder to maintain and to upgrade with recent version QEMU, so we could not benefit from some of the new features that have been developed in QEMU, and also any bug that we would have found in the fork can be hard to fix upstream because the code would be very different.
So, we took everything that was needed from qemu-traditional to run QEMU with Xen and integrate them in a modern QEMU. Up to now, few features were missing to be able to use QEMU, but now, all the main features are in and QEMU became the default for most usage.

So what’s new in 4.3?

An important feature to be able to live-migrate a guest is a way to be able to track memory that has been modified during a live-migration. The feature first appears in Xen 4.2.2.
We also added the support to CPU hotplug for HVM as it was one of the missing features to get QEMU closer to qemu-traditional and have it as default.

Missing feature?

We are still missing a few things with QEMU upstream, so far, the limited support for VGA passthrough has not been upstream. Another missing feature would be the use of QEMU in a stub-domain instead of using qemu-traditional as it is right now. This last one is planned to be fixed in hopefully 4.4.
There is also patchs to fix the suspend resume cycle of an HVM guest that should be applied soon.
Beside those missing features, there are more works going one to enhance the support of many QEMU features that are not usable right now with the tool stack libXL, like using USB redirection or USB passthrough or even one day supporting QXL.