On Thu, Jun 15, 2017 at 03:40:40PM +0100, Peter Maydell wrote: > 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.
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.)
