qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH v3 01/33] Create Resettable QOM interface


From: David Gibson
Subject: Re: [Qemu-arm] [PATCH v3 01/33] Create Resettable QOM interface
Date: Wed, 31 Jul 2019 15:46:12 +1000
User-agent: Mutt/1.12.0 (2019-05-25)

On Tue, Jul 30, 2019 at 04:08:59PM +0200, Damien Hedde wrote:
> 
> On 7/30/19 3:59 PM, Peter Maydell wrote:
> > On Tue, 30 Jul 2019 at 14:56, Cornelia Huck <address@hidden> wrote:
> >>
> >> On Tue, 30 Jul 2019 14:44:21 +0100
> >> Peter Maydell <address@hidden> wrote:
> >>
> >>> On Tue, 30 Jul 2019 at 14:42, Cornelia Huck <address@hidden> wrote:
> >>>> I'm having a hard time figuring out what a 'cold' or a 'warm' reset is
> >>>> supposed to be... can you add a definition/guideline somewhere?
> >>>
> >>> Generally "cold" reset is "power on" and "warm" is "we were already
> >>> powered-on, but somebody flipped a reset line somewhere".
> >>
> >> Ok, that makes sense... my main concern is to distinguish that in a
> >> generic way, as it is a generic interface. What about adding something
> >> like:
> >>
> >> "A 'cold' reset means that the object to be reset is initially reset; a 
> >> 'warm'
> >> reset means that the object to be reset has already been initialized."
> >>
> >> Or is that again too generic?
> > 
> > I think it doesn't quite capture the idea -- an object can have already
> > been reset and then get a 'cold' reset: this is like having a powered-on
> > machine and then power-cycling it.
> > 
> > The 'warm' reset is the vaguer one, because the specific behaviour
> > is somewhat device-dependent (many devices might not have any
> > difference from 'cold' reset, for those that do the exact detail
> > of what doesn't get reset on warm-reset will vary). But every
> > device should have some kind of "as if you power-cycled it" (or
> > for QEMU, "go back to the same state as if you just started QEMU on the
> > command line"). Our current "reset" method is really cold-reset.
> > 
> 
> Exactly. In the following patches, I've tried to replace existing reset
> calls by cold or warm reset depending on whether:
> + it is called through the main system reset -> cold
> + it is called during normal life-time       -> warm
> 
> But I definitely can add some docs/comments to better explain that.

Hrm, that helps, but it still seems pretty vague to me.

It's not really my call, but building the concept of warm versus cold
resets into such a generic interface seems pretty dubios to me.  While
it's moderately common for things to have a notion of warm versus cold
reset it's certainly not universal.  There are many devices where
there's no meaningful difference between the two.  There are some
devices where there are > 2 different types of reset suitable for
various different situations.

Is there any way this could work with it usually just presenting the
cold reset (which is the closest to a universal concept), and any warm
or additional resets are handled buy a different instance of the
Resettable interface?

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]