[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 23/27] hw/core/or-irq: Support more than 16 inpu

From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 23/27] hw/core/or-irq: Support more than 16 inputs to an OR gate
Date: Thu, 31 May 2018 12:59:33 +0100

On 31 May 2018 at 12:50, Paolo Bonzini <address@hidden> wrote:
> On 31/05/2018 12:50, Peter Maydell wrote:
>> 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

If there are then they are broken, because that's not how
qemu_irqs work... (Similarly, you can't assert an irq
in a reset method, because of ordering problems.)

>, and an interesting case (for the sake of
> this thread) is the IOMMU, which prompted the introduction of
> MigrationPriority.  Thanks for the lesson! :)

This sounds like a workaround for a bug in the device implementation.
Devices shouldn't care about which order they're restored in.

-- PMM

reply via email to

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