[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 17:15:30 +0200 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Thu, Jun 15, 2017 at 04:04:56PM +0100, Peter Maydell wrote:
> On 15 June 2017 at 15:57, Edgar E. Iglesias <address@hidden> wrote:
> > On Thu, Jun 15, 2017 at 03:40:40PM +0100, Peter Maydell wrote:
> >> 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?
>
> Interrupts/gpios (qemu_irqs) don't have any internal state,
> so all that is needed is for both devices to correctly migrate
> their idea of their internal state, and it doesn't matter which
> order that happens in. (Typically in QEMU devices track the state
> of their inbound interrupt lines even if in real hardware there's
> no flop doing that.)
>
> The difference here is that the clock objects themselves have
> internal state. That's not necessarily a bad idea, but it does
> mean that something's got to migrate that state or otherwise
> regenerate it. (Anthony once proposed that we should change qemu_irq
> objects to have internal state, because that's effectively what real
> hardware is and it would save the need for each device to track its
> input line state and be notified if the line didn't actually change
> state. It would just have been an enormous upheaval and migration
> compat break...)
Thanks. I didn't realize that the internal clock state would be used in a
way that is not deriveable from other device state & input clocks.
I'm not sure this is a use-case we need to support, thoughts?
Maybe there's some value in keeping interrupt and clock handling alike,
e.g removing the internal state from clocks.
I need to have another look at the series before I comment too much
since I don't remember the details...
Best regards,
Edgar
- 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, 2017/06/15
- 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 <=
- 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