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.
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)