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>
Subject: Re: [Qemu-devel] Morph cpu_reset -> device_reset
Date: Mon, 15 Jul 2013 11:55:07 +0200 [thread overview]
Message-ID: <51E3C6FB.8070302@suse.de> (raw)
In-Reply-To: <CAEgOgz5hz=pV+ctrsCBsaiLunzBmrEiGO9a35Xius5_ECf+3Ag@mail.gmail.com>
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. 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));
and if you have a good suggestion to clean this up, that will be
appreciated. So far, a CPUClass method (1:1) and Notifiers (1:n) were
the ideas that I brought up.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2013-07-15 9:55 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 [this message]
2013-07-15 10:45 ` Peter Crosthwaite
2013-07-15 12:22 ` Andreas Färber
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=51E3C6FB.8070302@suse.de \
--to=afaerber@suse.de \
--cc=aliguori@us.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=peter.crosthwaite@xilinx.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).