1 files changed, 146 insertions, 0 deletions
diff --git a/results/classifier/118/review/1536487 b/results/classifier/118/review/1536487
new file mode 100644
index 000000000..b9b0c3940
--- /dev/null
+++ b/results/classifier/118/review/1536487
@@ -0,0 +1,146 @@
+mistranslation: 0.924
+device: 0.905
+risc-v: 0.888
+virtual: 0.884
+register: 0.857
+user-level: 0.848
+VMM: 0.833
+PID: 0.829
+KVM: 0.826
+arm: 0.818
+semantic: 0.812
+peripherals: 0.801
+graphic: 0.780
+ppc: 0.776
+assembly: 0.769
+performance: 0.758
+permissions: 0.739
+x86: 0.704
+hypervisor: 0.682
+architecture: 0.680
+boot: 0.679
+socket: 0.665
+debug: 0.664
+kernel: 0.663
+files: 0.650
+network: 0.629
+vnc: 0.621
+TCG: 0.615
+i386: 0.366
+--------------------
+x86: 0.917
+KVM: 0.826
+virtual: 0.697
+hypervisor: 0.604
+files: 0.034
+TCG: 0.024
+debug: 0.023
+device: 0.021
+user-level: 0.017
+PID: 0.015
+register: 0.010
+kernel: 0.008
+socket: 0.005
+architecture: 0.003
+semantic: 0.003
+ppc: 0.003
+VMM: 0.003
+vnc: 0.002
+assembly: 0.002
+i386: 0.002
+risc-v: 0.002
+network: 0.002
+performance: 0.002
+boot: 0.001
+peripherals: 0.001
+graphic: 0.001
+permissions: 0.001
+arm: 0.000
+mistranslation: 0.000
+
+Unable to migrate pc-i440fx-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1
+
+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.0 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.
+
+Hi,
+Proxmox users have reported same bug (qemu 2.5 with pc-i440fc-2.4 not migrating to qemu 2.4.1)
+
+https://forum.proxmox.com/threads/cant-live-migrate-after-dist-upgrade.26097/
+
+I don't have verified yet, but it seem to be related.
+
+
+http://thread.gmane.org/gmane.comp.emulators.qemu/390272/focus=391042
+
+sent a patch: http://thread.gmane.org/gmane.comp.emulators.qemu/395014
+
+Fix committed in e6915b5f3a874a467a9a65f7ec1d6ef8d251a51a.
+
+Note: Also affects Migration Xenial->Trusty (tested and ran into the same issue, that was how I found the bug) and very likely also Yakkety->Trusty.
+
+ qemu | 2.0.0+dfsg-2ubuntu1.27   | trusty-security           | source
+ qemu | 1:2.5+dfsg-5ubuntu10.4   | xenial-updates            | source
+
+Subscribing server Team to look at this in the scope of the qemu packaging SRU work for Xenial.
+
+Migrating a VM from xenial -> trusty (or anything moving backward) is
+not supported.
+
+
+Hi Serge I agree to "created on xenial -> migrating to trusty" not being supported.
+I already tended to even say "created on xenial with the Trusty machine type -> migrating to trusty" is not supported as well (at least it is failing for all combos I tried.
+
+But I wonder how far "anything moving backward" should go.
+
+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.
+I'd have thought that this would be supported. What is you opinion on this more specific case?
+
+You might ask on #virt for the opinion there, but I don't believe
+migrating backward is supported in any case.  t->x->t doesn't change
+the fact that there is x->t.
+
+
+> 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.
+
+Serge, Paulo - thank you both!
+
+I already had the patch but I think it was good to discuss and list the expected behavior not only for me, but for whoever else that comes by this or a similar case.
+
+I backported this and tried my tests again, but this alone isn't sufficient to get the T->X->T working (which is effectively 2.0->2.5->2.0).
+Wily (2.4) is already out of service, so setting this to won't fix.
+
+Thanks for your guidance, but that now properly known I'll set the Xenial task to won't fix for now.
+