Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API.

[Peter Maydell <peter.maydell@linaro.org>]

On 15 June 2017 at 15:57, Edgar E. Iglesias <edgar.iglesias@gmail.com> wrote:
> On Thu, Jun 15, 2017 at 03:40:40PM +0100, Peter Maydell wrote:
>> Unfortunately we make no guarantees at all about migration order
>> for devices as far as I'm aware, so devices have to cope regardless.
>
>
> How does this work for interrupts/gpios?

Interrupts/gpios (qemu_irqs) don't have any internal state,
so all that is needed is for both devices to correctly migrate
their idea of their internal state, and it doesn't matter which
order that happens in. (Typically in QEMU devices track the state
of their inbound interrupt lines even if in real hardware there's
no flop doing that.)

The difference here is that the clock objects themselves have
internal state. That's not necessarily a bad idea, but it does
mean that something's got to migrate that state or otherwise
regenerate it. (Anthony once proposed that we should change qemu_irq
objects to have internal state, because that's effectively what real
hardware is and it would save the need for each device to track its
input line state and be notified if the line didn't actually change
state. It would just have been an enormous upheaval and migration
compat break...)

thanks
-- PMM