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. Such as the PAM registers on the i440FX, which *don't* reset themselves to the poweron state during a reset. And when I posted the naïve patch to 'fix' that, it was pointed out to me that some resets *shouldn't* do that. > 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. Yeah, when it's truly device-local that's different and fairly trivial to handle. > 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. Maybe, although often these reset lines *are* system-wide. The 'soft' vs. 'hard' distinction isn't something that the core code actually cares about; its precise definition is a matter to be agreed between the platform and the device drivers which run on that platform. It would be trivial to extend the enum to handle additional values if a given platform actually needed to. > 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. No, but (as discussed above) I don't think we *need* to have such a universal definition, either. But I'm not particularly wedded to this approach; we can do it with a hack directly in piix_pci.c too. To a certain extent, this is just a straw man, to show that the local hack isn't such a bad thing after all :) -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
