> The advisory for the flaw also offers the following contentious text:
> “We will encourage the community to have a conversation, when this advisory is
> released, about the continuing security support status of qemu-xen-traditional in
> non-stub-dm configurations.”
I can see how this text could be seen as contentious, but it is everything but. Xen ships with two versions of QEMU (see https://blog.xenproject.org/2013/09/20/qemu-vs-qemu-traditional-update/). So what this statement really means, is that the Xen Project should have a discussion to deprecate the qemu-xen-traditional fork in favour of QEMU upstream. This would mean that security fixes do not have to be backported from QEMU upstream to qemu-xen-traditional.
> With another two similar flaws now revealed, little wonder the Xen community is
> pondering its future relationship with QEMU.
Although split-ups do make a nice story, the opposite is actually the case. The Xen Project is working closer than ever with the QEMU folks and deprecation of our old qemu-xen-traditional fork is a sign of that growing closeness. In addition, we are working more closely on the security front too: the fact that Xen is handling more QEMU issues jointly with the QEMU security team is also a reflection of that. We also have some joint activities planned at LinuxCon.
Granted that the recent number of QEMU issues has been painful, but after Venom, it was to be expected that this would happen. And many of these issues also affect other consumers of QEMU (e.g. KVM). To mitigate such issues in the future, work is underway to sandbox QEMU within Xen (google for "xsrestrict QEMU", http://lists.xen.org/archives/html/xen-devel/2015-07/msg04501.html, ... ) such that the impact of future issues with QEMU can be contained.