From: "Andreas Färber" <afaerber@suse.de>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
Anthony Liguori <aliguori@us.ibm.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] Morph cpu_reset -> device_reset
Date: Mon, 15 Jul 2013 14:22:17 +0200 [thread overview]
Message-ID: <51E3E979.2040607@suse.de> (raw)
In-Reply-To: <CAEgOgz6V08XezGxnj2uZP-JRQk2YmHaskhUiZe19o983PZJVOA@mail.gmail.com>
Am 15.07.2013 12:45, schrieb Peter Crosthwaite:
> Hi Andreas,
>
> On Mon, Jul 15, 2013 at 7:55 PM, Andreas Färber <afaerber@suse.de> wrote:
>> Hi Peter,
>>
>> Am 15.07.2013 06:02, schrieb Peter Crosthwaite:
>>> A while ago, TYPE_CPU was refactored to by a child of TYPE_DEVICE. As
>>> something of a hangover though, CPU has a separate reset fn to device.
>>> This means
>>>
>>> device_reset(DEVICE(my_cpu));
>>>
>>> doesn't actually work as a reset. Should we fix this by getting rif of
>>> cpu_reset and just using the device reset API for cpu reset?
>>
>> This question has come up a number of times, cf. the archives. For one,
>> CPU reset is a mess with most CPUs not registering reset handlers of
>> their own like devices do but having machines do that and piggy-back
>> some machine-specific initialization, possibly even relying on execution
>> order of reset handlers.
>
> So some architectures are going to be a lot easier than others and if
> this is considered the right thing to do, we can convert some of easy
> ones and scratch our heads later re the machine quirks. I can speak
> for Microblaze as being as easy one. ARM doesn't look that scary
> either - and thats the one I want to convert for my application.
See hw/arm/boot.c for where such piggy-backing happens in ARM.
>> For another, some forms of Soft Reset (e.g.,
>> kdump on s390x) will require to reset devices only but not CPUs -
>> currently qdev_devices_reset() calls all reset handlers, not just
>> devices as the name might imply.
>>
>> For now you can reset a CPU via
>>
>> cpu_reset(CPU(my_cpu));
>>
>
> So my application is clock controllers, which have a uniform reset
> mechanism. I want to avoid having to give my clock controller CPU
> awareness for the sake of being able to do a reset. Infact, I dont
> event want my controller know what its resetting, all it gets is a
> link to a TYPE_DEVICE which it can then reset. Not possible with CPUs
> unless you:
>
> if (object_dynamic_cast(my_dev, TYPE_CPU))
> cpu_reset(...);
> else
> device_reset(...);
Sounds what you are looking for is rather a qemu_irq pin, which Anthony
has been promoting for soft resets, too.
Note that if we made device_reset() work on a CPU then we would need to
place that type check elsewhere still.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
prev parent reply other threads:[~2013-07-15 12:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-15 4:02 [Qemu-devel] Morph cpu_reset -> device_reset Peter Crosthwaite
2013-07-15 9:55 ` Andreas Färber
2013-07-15 10:45 ` Peter Crosthwaite
2013-07-15 12:22 ` Andreas Färber [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51E3E979.2040607@suse.de \
--to=afaerber@suse.de \
--cc=aliguori@us.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=peter.crosthwaite@xilinx.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.