Peter Maydell writes:
> On Tue, 30 Jul 2019 at 14:56, Cornelia Huck <coh...@redhat.com> wrote: >> >> On Tue, 30 Jul 2019 14:44:21 +0100 >> Peter Maydell <peter.mayd...@linaro.org> wrote: >> >> > On Tue, 30 Jul 2019 at 14:42, Cornelia Huck <coh...@redhat.com> 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. > > thanks > -- PMM -- Cheers, Christophe de Dinechin (IRC c3d)
