This initial problem came form libvirt - it does not preserve the device order when running QEMU. So it is easy to get source QEMU with: -device spapr-vscsi,id=scsi1,reg=0x2000 -device spapr-vscsi,id=scsi0,reg=0x3000 and destination QEMU with: -device spapr-vscsi,id=scsi0,reg=0x3000 -device spapr-vscsi,id=scsi1,reg=0x2000
Since SPAPR IOMMU device does not have a bus, it is identified in the migration stream as "spapr-iommu" and @instance_id which is assigned as IOMMUs are created. This results in broken migration as @reg does not match. The first patch fixes this issue by adding a bus device and a bridge. However just 1/8 does not fix the migration as device creation order also affects IRQs assigned to the devices, for both PCI and VIO. 2/7..8/8 fix that by moving XICS IRQ management from SPAPR to XICS and implementing migration support for the entire XICS IRQ map. As we are here, the patchset also prepares XICS to support multiple ICS (interrupt servers). This is a bugfix patchset but it feels too big to go to 2.0, right? :) Alexey Kardashevskiy (8): spapr-iommu: add a bus for spapr-iommu devices xics: add flags for interrupts xics: add find_server xics: add pre_load() hook to ICSStateClass xics: disable flags reset on xics reset spapr: move interrupt allocator to xics spapr: remove @next_irq xics: enable interrupt configuration reset on migration hw/intc/xics.c | 158 +++++++++++++++++++++++++++++++++++++++++++++---- hw/intc/xics_kvm.c | 9 +-- hw/ppc/spapr.c | 73 +---------------------- hw/ppc/spapr_events.c | 2 +- hw/ppc/spapr_iommu.c | 59 +++++++++++++++++- hw/ppc/spapr_pci.c | 8 +-- hw/ppc/spapr_vio.c | 4 +- include/hw/ppc/spapr.h | 18 +++--- include/hw/ppc/xics.h | 8 ++- trace-events | 4 ++ 10 files changed, 238 insertions(+), 105 deletions(-) -- 1.8.4.rc4
