[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API.
From: |
Edgar E. Iglesias |
Subject: |
Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API. |
Date: |
Thu, 15 Jun 2017 16:57:42 +0200 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Thu, Jun 15, 2017 at 03:40:40PM +0100, Peter Maydell wrote:
> On 14 June 2017 at 12:54, Paolo Bonzini <address@hidden> 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.)
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., Peter Maydell, 2017/06/06
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., KONRAD Frederic, 2017/06/08
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., Peter Maydell, 2017/06/13
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., Paolo Bonzini, 2017/06/14
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., KONRAD Frederic, 2017/06/14
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., Peter Maydell, 2017/06/15
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., Paolo Bonzini, 2017/06/15
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API.,
Edgar E. Iglesias <=
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., Peter Maydell, 2017/06/15
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., Edgar E. Iglesias, 2017/06/15
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., KONRAD Frederic, 2017/06/15
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., Peter Maydell, 2017/06/23
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., KONRAD Frederic, 2017/06/23
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., Peter Maydell, 2017/06/23
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., KONRAD Frederic, 2017/06/23
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., Peter Maydell, 2017/06/23
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., KONRAD Frederic, 2017/06/27
- Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API., Peter Maydell, 2017/06/27