Hi Peter, On Wed, Feb 20, 2013 at 8:50 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 19 February 2013 22:17, Anthony Liguori <anth...@codemonkey.ws> wrote: >> David Woodhouse <dw...@infradead.org> 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 >
