> Especially I found that the "created on Trusty, migrated to xenial > (works), but later migrated back to trusty (fails)" seems affected by > it as well.
The first migration of the t->x->t sequence does not really matter (if anything it could introduce _more_ bugs!), so if x->t is not supported then neither is t->x->t. The upstream QEMU project doesn't have the manpower to test and support backwards migration. We try not to break it, and in this case there was an easy fix and we suggest that Canonical backports it. However, in general it's not guaranteed to work. The fix is commit e6915b5f3a874a467a9a65f7ec1d6ef8d251a51a. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1536487 Title: Unable to migrate pc-i440fx-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1 Status in QEMU: Fix Released Status in qemu package in Ubuntu: Fix Released Status in qemu source package in Xenial: Triaged Bug description: When migrating a pc-i440fc-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1, the target QEMU errors out: qemu-system-x86_64: error while loading state for instance 0x0 of device 'fw_cfg' This appears to be related to the addition of a DMA interface to fw_cfg last October: http://lists.nongnu.org/archive/html/qemu- devel/2015-10/msg04568.html "info qtree" on the source QEMU shows that the DMA interface for fw_cfg had been enabled: bus: main-system-bus type System ... dev: fw_cfg_io, id "" iobase = 1296 (0x510) dma_iobase = 1300 (0x514) dma_enabled = true Incidentally, this guest had just undergone a migration from QEMU 2.4.1 to QEMU 2.5.0, so it looks like DMA was enabled simply through the migration. It seems to me that the DMA interface for fw_cfg should only be enabled on pc-i440fx-2.5 machines or higher. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1536487/+subscriptions
