On 31 May 2018 at 12:50, Paolo Bonzini <pbonz...@redhat.com> 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. thanks -- PMM
