From: Peter Maydell <peter.maydell@linaro.org>
To: Markus Armbruster <armbru@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>,
Laszlo Ersek <lersek@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] q35 and sysbus devices
Date: Fri, 24 Mar 2017 18:10:59 +0000 [thread overview]
Message-ID: <CAFEAcA94t24TATa=9GFWszD9__i=TL09E7_kGptaPEKFe_TBhw@mail.gmail.com> (raw)
In-Reply-To: <877f3emu7w.fsf@dusky.pond.sub.org>
On 24 March 2017 at 17:59, Markus Armbruster <armbru@redhat.com> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
>> This isn't really true. Sysbus devices support having MMIO regions
>> and IRQ lines and GPIO lines. If you need those you're a
>> sysbus device; otherwise you can probably just be a plain old Device.
>
> Well, "device has MMIO regions, IRQ lines and GPIO lines" is about as
> "device contains virtual silicon". What would a device without any of
> these *do*?
A PCI device doesn't have them, for instance -- it exposes only
a PCI-bus connector.
> Devices plugging into a bus have to expose their MMIO regions, IRQ
> lines, etc. in a certain way dictated by the bus. In return, you don't
> have to wire up each resource manually, you simply plug into the bus and
> are done. That's what makes a bus a bus for me.
I think of these as various kinds of connection. A connection
can be a single wire (like a GPIO line or an interrupt line),
or it can be a well-defined bundle of signals (like a PCI bus
slot's multiple connections), or (for emulation) it can be a
more abstracted connection like what we call an MMIO region
(which is an abstraction of a data bus and address bus
set of signals which we don't want to modify at that level).
A PCI device in QEMU is *not* exposing an MMIO region, because
the only correct way to access it is via the PCI bus APIs.
(We just implement our PCI bus in terms of MMIO regions.)
A "bus" is just a well defined set of signals that it's convenient
to manipulate all at once. It isn't necessarily every signal
the device has.
Not all hardware is defined like that -- quite a lot (especially
in the embedded world) is defined with much more ad-hoc
connection specifications because it's going to be "wired up"
as part of an SoC, with some verilog/RTL which says "this GPIO
line goes to here" and so on. In fact even at this level there's
usually some sort of 'bus' abstraction for some of these signals:
what we represent as an individual MMIO region is usually
a connection on an AXI or AHB bus or other architectural equivalent.
The way that we privilege some of these connections above others
(eg that PCI devices all inherit from a particular parent class)
is a bit ugly in an abstract sense (really a device should just
say "I have a PCI connection here" in the same way it can say
"I have a bare GPIO wire here", rather than PCI devices being
subclasses of a common PCI device base class), but it's a
bit simpler in practice. Similarly having a base class that's
providing some useful functionality for devices that deal
mostly in "bare wires" is convenient in practice.
thanks
-- PMM
next prev parent reply other threads:[~2017-03-24 18:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 20:31 [Qemu-devel] q35 and sysbus devices Eduardo Habkost
2017-03-22 20:46 ` Laszlo Ersek
2017-03-24 10:49 ` Marcel Apfelbaum
2017-03-24 13:48 ` Eduardo Habkost
2017-03-24 14:13 ` Peter Maydell
2017-03-24 19:04 ` Eduardo Habkost
2017-03-24 16:58 ` Markus Armbruster
2017-03-24 17:08 ` Peter Maydell
2017-03-24 17:59 ` Markus Armbruster
2017-03-24 18:10 ` Peter Maydell [this message]
2017-03-27 8:00 ` Thomas Huth
2017-03-24 19:23 ` Eduardo Habkost
2017-03-27 8:44 ` Cornelia Huck
2017-03-27 9:00 ` Peter Maydell
2017-03-27 16:11 ` Eduardo Habkost
2017-03-24 11:41 ` Thomas Huth
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='CAFEAcA94t24TATa=9GFWszD9__i=TL09E7_kGptaPEKFe_TBhw@mail.gmail.com' \
--to=peter.maydell@linaro.org \
--cc=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=lersek@redhat.com \
--cc=marcel@redhat.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).