Re: [Qemu-ppc] [PATCH 6/8] spapr: move interrupt allocator to xics

[Alexey Kardashevskiy]

On 04/11/2014 07:24 PM, Alexander Graf wrote:
> 
> On 10.04.14 16:43, Alexey Kardashevskiy wrote:
>> On 04/10/2014 11:26 PM, Alexander Graf wrote:
>>> On 10.04.14 15:24, Alexey Kardashevskiy wrote:
>>>> On 04/10/2014 10:51 PM, Alexander Graf wrote:
>>>>> On 14.03.14 05:18, Alexey Kardashevskiy wrote:
>>>>>> The current allocator returns IRQ numbers from a pool and does not
>>>>>> support IRQs reuse in any form as it did not keep track of what it
>>>>>> previously returned, it only had the last returned IRQ.
>>>>>> However migration may change interrupts for devices depending on
>>>>>> their order in the command line.
>>>>> Wtf? Nonono, this sounds very bogus and wrong. Migration shouldn't change
>>>>> anything.
>>>> I put wrong commit message. By change I meant that the default state
>>>> before
>>>> the destination guest started accepting migration is different from what
>>>> the destination guest became after migration finished. And migration
>>>> cannot
>>>> avoid changing this default state.
>>> Ok, why is the IRQ configuration different?
>> Because QEMU creates devices in the order as in the command line, and
>> libvirt changes this order - the XML used to create the guest and the XML
>> which is sends during migration are different. libvirt thinks it is ok
>> while it keeps @reg property for (for example) spapr-vscsi devices but it
>> is not because since the order is different, devices call IRQ allocator in
>> different order and get different IRQs.
> 
> So your patch migrates the current IRQ configuration, but once you restart
> the virtual machine on the destination host it will have different IRQ
> numbering again, right?

No, why? IRQs are assigned at init time from realize() callbacks (and
survive reset) or as a part of ibm,change-msi rtas call which happens in
the same order as it only depends on pci addresses and we do not change
this either.


> I'm not sure that's a good solution to the problem. I guess we should
> rather aim to make sure that we can make IRQ allocation explicit.
> Fundamentally the problem sounds very similar to the PCI slot allocation
> which eventually got solved by libvirt specifying the slots manually.

We can do that too. Who decides? :)



-- 
Alexey