On Thu, Jun 15, 2017 at 04:04:56PM +0100, Peter Maydell wrote: > On 15 June 2017 at 15:57, Edgar E. Iglesias <edgar.igles...@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. I didn't realize that the internal clock state would be used in a way that is not deriveable from other device state & input clocks. I'm not sure this is a use-case we need to support, thoughts? Maybe there's some value in keeping interrupt and clock handling alike, e.g removing the internal state from clocks. I need to have another look at the series before I comment too much since I don't remember the details... Best regards, Edgar