On 05/05/2014 07:52 AM, Paolo Bonzini wrote: > Il 04/05/2014 15:56, Alexey Kardashevskiy ha scritto: >> On 03/14/2014 03:18 PM, Alexey Kardashevskiy wrote: >>> 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? :) >> >> >> I understand that the first and last patches of the series are wrong but I >> would still like others to get in upstream. How to proceed now? Repost them >> all again? Thanks. > > You are working around a libvirt problem caused by a missing QEMU feature.
Not anymore, I am solving a different issue now - I want to return IRQs back to pool after PCI hot unplug. > At least patch 4 is probably unnecessary too. 2/3/5/6/7 (aka what's left) > seem sane and likely to remain useful in order to implement the QEMU > feature correctly. Yep, patch#4 has to go too. I'll repost then. Thanks! -- Alexey
