qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] q35 and sysbus devices


From: Peter Maydell
Subject: Re: [Qemu-devel] q35 and sysbus devices
Date: Fri, 24 Mar 2017 18:10:59 +0000

On 24 March 2017 at 17:59, Markus Armbruster <address@hidden> wrote:
> Peter Maydell <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]