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

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

On Thu, Jun 15, 2017 at 03:40:40PM +0100, Peter Maydell wrote:
> On 14 June 2017 at 12:54, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > I think the various bindings and rates could be refreshed as devices are
> > migrated.  This assumes that the device migration order is okay
> > according to the clock tree, that is if you have three devices X/Y/Z and
> > five clocks a/b/c/d/e/f:
> >
> >   fixed-clock
> >     |     |
> >    X:a   X:b
> >     |     |    \
> >    Y:c   Y:d      Z:e
> >           |
> >          Z:f
> >
> > you could do this:
> >
> > - migrate X
> >   - retrieve the PLL ratios for a and b's bound clocks (if the ratio
> >     is variable, otherwise no need for this)
> >   - in the post_load callback, bind a and b to the fixed-clock
> >     (if the binding is variable, otherwise no need for this)
> > - migrate Y
> >   - retrieve the PLL ratio for d's bound clocks (if the ratio
> >     is variable, otherwise no need for this)
> >   - in the post_load callback, bind c and d to a and b respectively
> >     (if the binding is variable, otherwise no need for this)
> > - migrate Z
> >   - in the post_load callback, bind e and f to b and d respectively
> >     (if the binding is variable, otherwise no need for this)
> 
> 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?

Perhaps we would need a way to force all clock sources that don't
depend on input clocks to re-notify their clocks after migration
is complete but before we run the new guest?

That would propagate updates throughout the chain...

Cheers,
Edgar

> 
> (There's also the possibility of an oddball bit of hardware which
> has a clocktree with loops in it.)