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

[Christophe de Dinechin]

> On 1 Aug 2019, at 11:19, Damien Hedde <address@hidden> wrote:
> 
> 
> On 7/31/19 12:17 PM, Christophe de Dinechin wrote:
>> 
>> Peter Maydell writes:
>> 
>>> 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.
>> 
>> Is there any concept of locality associated with warm reset?
>> For example, you'd expect a cold reset to happen on the whole system,
>> but I guess a warm reset could be restricted to a single bus.
>> 
>> The documentation should give examples of how warm reset could be
>> triggered, and what it could do differently from cold reset.
>> 
> 
> Not sure we really have some locality difference between cold/warm
> resets. I think, most generally, locality of reset is on a per-device
> scale with different grouping level (up to the whole system). But buses
> are not always the way things are grouped.
> 
> Inside a soc (and microcontrollers in general) it follows more the clock
> tree than the internal bus tree. For example on the the machine I worked
> here (xilinx-zynq-a9) and, you can control by software the reset of
> basically every single device and the bus too (but resetting the bus
> does not reset devices on it).
> 
> On the other hand, there is some buses, like pci, which explicitly
> defines some bus reset mechanism with differences between cold and warm
> (some registers keep their values). (see
> https://wiki.qemu.org/Features/ResetAPI)
> 
> Regarding cold reset, if a soc supports some power gating, you'll
> probably have non-global cold reset in the process.
> 
> Do you mean "real world" example ?

I think that a variant of what you just wrote would be fine.
I was not aware for example that you could have non-global cold reset.


Thanks
Christophe