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

[Peter Maydell]

On 19 February 2013 22:17, Anthony Liguori <address@hidden> wrote:
> David Woodhouse <address@hidden> writes:
>> On Tue, 2013-02-19 at 14:29 -0600, Anthony Liguori wrote:
>>> So should we even be resetting anything other than the CPU during soft
>>> reset?
>>
>> I suspect not. A soft reset triggered by the RCR, keyboard controller,
>> port 92 etc. should all just reset the CPU and nothing else.
>
> I suspect what we need to do is convert qemu_system_reset_request() into
> a qemu_system_cpu_reset() that takes a callback.  Once the VCPUs have
> been reset, the callback can then be used to reset all or some of the
> device model.

If we're just solving a PC problem here and it really is just
"only reset the CPU, nothing else", why don't we give the
x86 CPU a qemu_irq input for "reset this CPU core" and wire it
up to the relevant bit of hardware on the PC board? I don't
see the need for a specific 'qemu_system_cpu_reset()' here
(and not having one avoids the swamp of trying to define its
semantics...)

>> How far down this road do we go? Do we end up wiring up the full reset
>> topology and abandoning the special-case qemu_system_reset()
>> altogether?
>
> Long term, yes.  Short term, whatever we need that's reasonable to get
> the CSM happy without making things worse.

I definitely think we should be modelling reset lines, yes.
It would be nice if we could sketch a path for how we get from
here to there. Here's a strawman proposal that's probably full
of holes:

(1) we retain the existing 'reset' Device method as meaning "full
power-cycle style reset" and qemu_system_reset_request() as
meaning "power cycle entire machine". (Eventually the latter
might go away as I doubt much real hardware has a "power
cycle the world" wiring.)

(2) we recommend that for new devices etc, where the device has
one or more physical reset pins those should be modeled as
qdev_gpio input lines, with the behaviour the hardware has
when those are asserted. [Q: what do we do about logic-low-is-assert
vs logic-high-is-assert hardware?] This reset can obviously share
code with the DeviceState::reset in many cases, but it's
conceptually separate.

(3) when we need to implement a particular effect on a particular
board (as here with the PC) we do that by:
 a. making sure all affected devices implement reset
 b. wiring up reset on the board model
 c. having the implementation of the 'reset' register or whatever
    assert the irq line

(4) as and when we have time, convert existing code (ho ho)

This obviously works best when the "not actually a full power
cycle" reset you want in (3) is a very limited focus one,
like "just reset the CPU"...

It also exposes some "not there yet" features like the fact
we can't have named gpio input lines so you have to have a
numbering convention for smooshing all your inputs into a
single array. Pins, anybody? :-)

-- PMM