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

[David Woodhouse]

On Tue, 2013-02-19 at 14:08 +0000, Peter Maydell wrote:
> On 19 February 2013 13:58, David Woodhouse <address@hidden> wrote:
> > On Tue, 2013-02-19 at 12:04 +0000, Peter Maydell wrote:
> >> 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".
> >
> > Except when it doesn't....
> 
> If they are reacting to QEMU reset by doing anything other than
> "reset to poweron state" then that reset function is broken and
> needs fixing. 

Be careful what you wish for :)

By this logic, anything that calls qemu_system_reset_request() when it
isn't asking for a full power-cycle reset is broken, and that includes
everything from triple-fault handling to keyboard controller to...
fairly much everything else.

So yes, I could do the easy thing and just go ahead and
*unconditionally* reset the PAM registers in i440fx_init().

We could stick a reset handler in place to wipe the whole of the guest's
physical memory too, just to make the point :)

> If there are other types of reset that need to
> be modelled than power on reset then you need to actually
> model the power controller, reset lines, etc, or at least a
> sufficient subset of them for your purposes.

Excellent. Well, *mine* is a full power-on reset so I'm fine, thanks :)

But we've just declared fairly much every other reset trigger to be
broken.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature