On 19 February 2013 11:40, David Woodhouse <dw...@infradead.org> 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