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

[Paolo Bonzini <pbonzini@redhat.com>]

On 13/06/2017 12:33, Peter Maydell wrote:
>> For the migration maybe we can refresh the whole clock tree at the end
>> of the migration. Is that a good idea?
> That seems kind of awkward -- where would this code that did a
> clock tree refresh be? Also you're then reliant on all the
> callback functions registered to not actually do anything that
> affects device state when the refresh happens. It would be
> cleaner if the qemu-clk objects managed their own internal
> state migration (but can we do this without having to make
> them be Device objects rather than just objects ?).
> 
> Cc'd Paolo who might have an opinion on these -- my opinion currently
> is mostly "this doesn't really look right" rather than knowing what
> the right approach is.

Same here. :)

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)

Paolo