Re: [Qemu-devel] [PATCH 23/27] hw/core/or-irq: Support more than 16 inputs to an OR gate

[Paolo Bonzini <pbonzini@redhat.com>]

On 31/05/2018 12:50, Peter Maydell wrote:
> On 31 May 2018 at 11:21, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> On 30/05/2018 19:35, Peter Maydell wrote:
>>> On 30 May 2018 at 17:59, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>> On 21/05/2018 17:02, Peter Maydell wrote:
>>>>> On 21 May 2018 at 15:34, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>>>> Why do the levels have to be migrated at all?  It should be enough if
>>>>>> the IRQ level is either migrated manually, or restored (e.g. in
>>>>>> post_save callbacks) through other data that is migrated.
>>>>> This is standard behaviour for devices: they track their
>>>>> inbound irq/gpio lines, and then that becomes internal state for
>>>>> them that must be migrated.
>>>>
>>>> But or_irq's input are another device's outbound lines, so tracking them
>>>> should not be necessary.  The other device would do it for or_irq.
>>>
>>> There's no mechanism in qemu_irq for the destination end to ask
>>> the source end about its current value. The information flow
>>> is strictly one-way.
>>
>> On postload, the source must call qemu_set_irq and that will cause an
>> update of the or_irq, won't it?
> 
> No, calling qemu_set_irq in postload is a bug. (You don't know
> which order the state of the source and destination devices is
> restored, so asserting a signal in postload would have different
> effects depending on whether the destination had already had
> its state restored or not.)

Hmm, I suppose the x86 world is a bit more "hierarchical" and you cannot
create a qemu_irq loop - and creating the sink always before the source
ensures that migration works fine with post_load.  I'm pretty sure that
there are devices that do that, and an interesting case (for the sake of
this thread) is the IOMMU, which prompted the introduction of
MigrationPriority.  Thanks for the lesson! :)

Maybe we should add your text to docs/devel/migration.rst, under "Device
ordering", because it explicitly mentions interrupt controllers.

Paolo