Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types

[Peter Maydell]

On 19 February 2013 11:40, David Woodhouse <address@hidden> wrote:
> To do it properly, we need to distinguish between a 'hard' reset
> triggered by the PIIX3 RCR register, which resets the PAM configuration,
> and a 'soft' reset triggered for example by the keyboard controller,
> which doesn't.
>
> This patch attempts to introduce a ResetType into the code logic. Rather
> than propagating that ResetType through the entire stack of device reset
> functions, I've added a 'qemu_last_reset_get()' function so that the
> devices which *do* care can look for it.
>
> Comments? There are a whole bunch more qemu_system_reset_request() calls
> which will need a ResetType added, if I do it this way...

I'm dubious about this. At the moment we have one set of reset
semantics, which is "this works as if you yanked the power to
the machine and plugged it back in again". We also have a number
of cases of device-local "software reset" where the device
internally resets just some of its state when the guest prods
an appropriate register.

If you want any other kind of reset, we have to start actually
really modelling the hardware with all the various reset lines
and so on. So a keyboard controller triggered reset should work
by asserting a gpio line which probably goes to some kind of power
controller which in turn causes various other devices to act in
whatever way the hardware acts for soft reset.

Basically, I don't think you can come up with a definition of
"soft reset" that makes sense across the range of architectures
and boards that we model in QEMU.

-- PMM