Comment 26 for bug 1894772

Thanks for uncovering just another bug on the case (it is four now, so we can already see that it is complex and comes back in different aspects).

From looking at the debdiffs a few formalities:
- origin, please point to some place you go this from "based on a patch by Len <email address hidden>" is nothing you can find, the comment might be useful but should be accompanied by an URL

In general it seems this shall become a patch we forever apply on top (not upstream, needs to go to all releases now and in future), that kind of change almost always is wrong.

If that would be the right solution then upstream would apply it. We have seen too many cases where such a kind of forever-carry-on-delta just makes us worse and worse. Now it might be bad in Xenial, but due to that we can "infect" more and more with a bad behavior. E.g. when an upstream change makes this subtly fail even worse and we only realize later one.

Since the root cause seems to be like "... virtqueue got into an inconsistent state in 2.5.0 and it carried over ..." (from https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg02830.html) I wonder if we have to make a hard cut at some point instead of "carry delta forever". More like "fix it in the old release and require a guest restart before migration".

If you think applying that change to all releases is indeed the right solution drive the upstream discussion and once applied there we can backport SRU it to the existing releases. That also will provide a good "origin" tag then as we can point at the commit in qemu git and drop it once we merge a version with it.