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

[Peter Maydell]

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. 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.

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. 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.

>> 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.

And often they are not, which is my point. The only way
to actually model this stuff correctly is to model it
correctly. Mostly we get away with not doing so, because not
a lot of things truly care about the difference between a
programmed reset and powercycling the hardware.

> 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.

This assumes that the devices are only ever used in a single
platform with a single way of doing reset, which is also not
always true.

>> 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.

Your patch is effectively trying to introduce one (without
actually calling it one), which is why I'm arguing against it...

> 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 :)

It certainly sounds like it's closer to the right approach...

-- PMM