Re: [Qemu-devel] [PATCH 0/8] spapr: fix IOMMU and XICS/IRQs migration

[Alexey Kardashevskiy <aik@ozlabs.ru>]

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