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

["Edgar E. Iglesias" <edgar.iglesias@xilinx.com>]

On Thu, Jun 15, 2017 at 04:04:56PM +0100, Peter Maydell wrote:
> 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. 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