Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

CC'ing Linux x86 maintainers

On Wed, 9 May 2018, Olaf Hering wrote:
> Am Wed, 9 May 2018 14:08:14 -0700 (PDT)
> schrieb Stefano Stabellini <sstabellini@xxxxxxxxxx>:
> 
> > I cannot find 512b109ec962 or "xen: unplug the emulated devices at
> > resume time" anywhere, neither in qemu.org/master nor in the qemu-xen
> > trees. What am I missing?
> 
> It is a 7 years old kernel patch.

I see, the email subject misled me. I found the commit now.


> Jochen pointed me to commit 512b109ec962 ("xen: unplug the emulated
> devices at resume time"), which I think is wrong. The kernel will most
> likely not be able to switch from a PV backed device to an emulated
> device. Not sure what issue could have been addressed by that commit.
> What should have been done instead is to transfer the unplug state
> from one qemu to the other. Please advice how to do that. Right now,
> with xen-4.10, all xenlinux based HVM domUs can not be migrated
> anymore. With the upcoming xen-4.11 the migrated domU will need to be
> killed.

I don't recall why 512b109ec962 was needed exactly. I suspect that the
sudden appearance of the emulated devices was actually causing some
problems.  Did you try to revert it? I would imagine you'll probably see
some interesting output from the kernel at resume time.

Yes, transferring the unplug state from one QEMU to the other is a good
idea, but Linux should be able to migrate correctly regardless of the
QEMU/Xen version. Xen support in Linux doesn't depend on any specifc Xen
version, so this is probably why the bug was fixed/worked-around on the
Linux side.

512b109ec962 is a very old commit: why is it causing problems to Xen
4.10 and Xen 4.11 HVM migration? What is the error exactly? Sorry, I
might be missing some context.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel