On Tue, 2013-02-19 at 14:08 +0000, Peter Maydell wrote: > On 19 February 2013 13:58, David Woodhouse <dw...@infradead.org> 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
