[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [PATCH 6/8] spapr: move interrupt allocator to xics
Date: Sat, 12 Apr 2014 00:50:25 +1000
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

On 04/11/2014 11:58 PM, Alexander Graf wrote:
> On 11.04.2014, at 14:38, Alexey Kardashevskiy <address@hidden> 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 do not understand what you mean by this. Hibernation by the guest OS
itself or by QEMU? If this involves QEMU exit and QEMU start - then yes,
config may be different. If it is "migrate to file" and then "migrate from
file" (do not know what you call it when migration goes to a pipe which is
"tar") - then config will be the same.

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

We both know who decides ;) I posted series, I need heads up if it is going
the right way or not.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]