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

[Peter Maydell <peter.maydell@linaro.org>]

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.

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

thanks
-- PMM