qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).