On 14 June 2017 at 12:54, Paolo Bonzini <pbonz...@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
