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

[Peter Crosthwaite]

Hi Peter,

On Wed, Feb 20, 2013 at 8:50 AM, Peter Maydell <address@hidden> wrote:
> 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...)
>

Could we be more general and implement this on the TYPE_DEVICE level
(rather than X86_CPU)? I want this GPIO-as-reset feature for all Zynq
devices cpus and preihperals alike. The Zynq power controller has
software controllable individual reset for every device in the system
and my plan-A was to do it as GPIOs. To implement the reset gpio-ins
however I was thinking do it in one swift stroke by adding the single
GPIO on the TYPE_DEVICE layer that backs onto DeviceClass-.>reset.
With recent QOM efforts (making CPUs DEVICEs) this catchall will also
implment the feature for all CPUs. Power controllers define gpio_outs
and then machine model just play connect the dots.

RFC! I was planning at some stage to formally RFC this but yet to get
around to it. I bring it up because the topic is hot here.

>>> 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)
>
The TYPE_DEVICE level implementation would give a reset pin to every
device that implements DeviceClass->reset which should minimise the
pain here. The hard part is devices that dont implement reset at all
which are a lost cause WRT this discussion.

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

Yes my idea requires this so would have to bite the bullet and get
this one through.

Regards,
Peter

> -- PMM
>