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

[Peter Maydell]

On 31 May 2018 at 11:21, Paolo Bonzini <address@hidden> wrote:
> On 30/05/2018 19:35, Peter Maydell wrote:
>> On 30 May 2018 at 17:59, Paolo Bonzini <address@hidden> wrote:
>>> On 21/05/2018 17:02, Peter Maydell wrote:
>>>> On 21 May 2018 at 15:34, Paolo Bonzini <address@hidden> 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.) The system design relies on each
device keeping track of (and migrating) the state of the input
lines it cares about.

thanks
-- PMM