From: Peter Maydell <peter.maydell@linaro.org>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: "Peter Crosthwaite" <peter.crosthwaite@xilinx.com>,
"Alexander Graf" <agraf@suse.de>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
"Jens Freimann" <jfrei@linux.vnet.ibm.com>,
"Xu Wang" <gesaint@linux.vnet.ibm.com>,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH for-2.4 1/2] core: reset handler for bus-less devices
Date: Mon, 13 Jul 2015 16:56:33 +0100 [thread overview]
Message-ID: <CAFEAcA8YwQRFyPuoGT_dJQpNNOGOG+orY=jJg+Os9XEkqu7BNQ@mail.gmail.com> (raw)
In-Reply-To: <20150713173858.1930cd71.cornelia.huck@de.ibm.com>
On 13 July 2015 at 16:38, Cornelia Huck <cornelia.huck@de.ibm.com> wrote:
> So why does a pure Device have a reset callback then that is not called
> by default?
This is (as I understand it) basically historical legacy from
qdev. The qdev model puts every device on a bus of some kind,
and then says that it's the bus that has responsibility for
resetting the devices on it. We've now generalised that to
allowing devices that don't really sit on buses, but because
we still have a lot of code in the system that assumes the
reset-is-by-the-bus model (and for cases like PCI depends on
that ordering) we can't shift to "just reset every Device object
in the system". So the current setup is that every Device needs
to either (a) live on a bus that handles reset for it or
(b) arrange to call reset itself or (c) require the code which
creates it to arrange for reset to be called (which is what CPU
objects do, for instance -- the board code has to register a
reset handler which calls cpu_reset()).
> Really, I think we're moving in circles here. First, the device should
> not live on the sysbus as it does not fit the perceived sysbus
> semantics. As there is no natural bus for it to live on, it becomes a
> pure device. Which is not reset, because somehow a generic callback is
> not called generically.
I agree it's confusing, but I think adding a generic call to reset
at this point in the release cycle is really dangerous. For
better or worse, a lot of devices in the system expect to be
reset in the way they are currently. There's definitely
scope for improving/fixing the current code, but I think it's
more upheaval than we can do for this release.
thanks
-- PMM
next prev parent reply other threads:[~2015-07-13 15:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-09 16:51 [Qemu-devel] [PATCH for-2.4 0/2] reset for bus-less devices Cornelia Huck
2015-07-09 16:51 ` [Qemu-devel] [PATCH for-2.4 1/2] core: reset handler " Cornelia Huck
2015-07-09 16:59 ` Andreas Färber
2015-07-09 18:53 ` Peter Crosthwaite
2015-07-13 14:28 ` Paolo Bonzini
2015-07-13 12:22 ` Christian Borntraeger
2015-07-13 14:11 ` Cornelia Huck
2015-07-13 14:20 ` Andreas Färber
2015-07-13 14:30 ` Christian Borntraeger
2015-07-13 15:05 ` Andreas Färber
2015-07-13 15:38 ` Cornelia Huck
2015-07-13 15:49 ` Andreas Färber
2015-07-13 15:56 ` Peter Maydell [this message]
2015-07-13 14:37 ` Cornelia Huck
2015-07-13 16:06 ` Andreas Färber
2015-07-14 7:41 ` Cornelia Huck
2015-07-09 16:51 ` [Qemu-devel] [PATCH for-2.4 2/2] watchdog/diag288: handle subsystem resets correctly Cornelia Huck
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='CAFEAcA8YwQRFyPuoGT_dJQpNNOGOG+orY=jJg+Os9XEkqu7BNQ@mail.gmail.com' \
--to=peter.maydell@linaro.org \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=gesaint@linux.vnet.ibm.com \
--cc=jfrei@linux.vnet.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).