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

[Alexander Graf <agraf@suse.de>]

On 11.04.2014, at 14:38, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:

> 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.

Ok, let me rephrase. If I shut the machine down because I'm doing on-disk hibernate and then boot it back up, will the guest find the same configuration?

> 
> 
>> 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? :)

The better solution wins :)


Alex