From: Anthony Liguori <anthony@codemonkey.ws>
To: Alexander Graf <agraf@suse.de>,
"qemu-ppc@nongnu.org list:PowerPC" <qemu-ppc@nongnu.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
qemu-devel Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 0/9] Add platform bus
Date: Mon, 22 Jul 2013 14:38:24 -0500 [thread overview]
Message-ID: <87vc42jsgf.fsf@codemonkey.ws> (raw)
In-Reply-To: <1374515411-43818-1-git-send-email-agraf@suse.de>
Alexander Graf <agraf@suse.de> writes:
> Platforms without ISA and/or PCI have had a seriously hard time in the dynamic
> device creation world of QEMU. Devices on these were modeled as SysBus devices
> which can only be instantiated in machine files, not through -device.
>
> Why is that so?
>
> Well, SysBus is trying to be incredibly generic. It allows you to plug any
> interrupt sender into any other interrupt receiver. It allows you to map
> a device's memory regions into any other random memory region. All of that
> only works from C code.
>
> But do we need that level of complexity for normal devices usually? In a
> normal platform world (SoCs, PV machines) we have a flat memory layout we
> can plug our device memory into. We also have a flat IRQ model where we
> can plug our device IRQs into.
>
> This platform bus creates a simple bus that models the easy world. It allows
> for dynamic device creation through -device. A device may or may not explictly
> request to be mapped at a specific IRQ and/or memory address. If no explicit
> mapping is requested, platform devices just get mapped at convenient places.
>
> This goes hand in hand with automatic device tree generation. When QEMU
> places devices somewhere and also generates a device tree to tell the guest
> where exactly those devices are, we close the cycle and everyone knows
> everything and lives happily ever after.
>
> The actual pressing issue this solves is that today it's impossible to spawn
> serial ports from the command line. With this patch set, it's possible to
> do so. But it lays the groundwork for much more...
tl;dr, this is a PV bus for the e500 described as something more
generic. I don't buy it. I don't think there are many platforms or
devices out there where you can arbitrarily hook up devices at random
offsets/IRQs and expect things to work in any meaningful way.
So I'll suggest one of three things:
1) Just use PCI and call it a day
2) Rename this to E500PlatformBus and call it a day
3) If you really want to solve the general problem of platform devices,
I think the approach needs to involve:
a) Forget about any bus at all, just inherit from a common base class
b) Use the common base class to expose interfaces to enumerate IRQs
and MemoryRegions
c) Have machine-specific logic (in the post init hook) that looks for
any device of the type defined in (a) and connects their
IRQs/MemoryRegions as appropriate.
I can believe that this approach could be reasonably generic. It's
not abnormal for a hardware vendor to produce a single chip with all
of the possible silicon on it and disable bits and pieces in order to
offer a wider range of products.
In this case, I could believe that a single SoC family could have up
to four network adapters but I would also expect these adapters to
live in four well known places. With a machine specific hook, you
can look at the specific device type and make these types of
decisions appropriately.
Regards,
Anthony Liguori
>
> Alex
>
> Alexander Graf (9):
> PlatBus: Add Platform Bus
> PlatBus: Add abstract Platform Device
> PlatBus: Add Sysbus/Platform bridge device
> PlatBus: Hook up into Makefile system
> PPC: Add platform bus to the default compile set
> PlatBus: Add serial-platbus device
> PPC: Add PlatBus Serial to default configs
> PPC: E500: Spawn PlatBus bridge for ppce500 machine
> PPC: E500: Add PlatBus device tree walker
>
> default-configs/ppc-softmmu.mak | 2 +
> default-configs/ppc64-softmmu.mak | 2 +
> default-configs/ppcemb-softmmu.mak | 2 +
> hw/Makefile.objs | 1 +
> hw/char/Makefile.objs | 1 +
> hw/char/serial-platbus.c | 100 +++++++++++++++++++++++
> hw/platbus/Makefile.objs | 1 +
> hw/platbus/bridge.c | 64 +++++++++++++++
> hw/platbus/device.c | 162 +++++++++++++++++++++++++++++++++++++
> hw/platbus/platbus.c | 107 ++++++++++++++++++++++++
> hw/ppc/e500.c | 75 ++++++++++++++++-
> hw/ppc/e500.h | 1 +
> hw/ppc/e500plat.c | 1 +
> include/hw/char/serial-platbus.h | 56 +++++++++++++
> include/hw/platbus/bridge.h | 32 ++++++++
> include/hw/platbus/device.h | 102 +++++++++++++++++++++++
> include/hw/platbus/platbus.h | 86 ++++++++++++++++++++
> 17 files changed, 791 insertions(+), 4 deletions(-)
> create mode 100644 hw/char/serial-platbus.c
> create mode 100644 hw/platbus/Makefile.objs
> create mode 100644 hw/platbus/bridge.c
> create mode 100644 hw/platbus/device.c
> create mode 100644 hw/platbus/platbus.c
> create mode 100644 include/hw/char/serial-platbus.h
> create mode 100644 include/hw/platbus/bridge.h
> create mode 100644 include/hw/platbus/device.h
> create mode 100644 include/hw/platbus/platbus.h
>
> --
> 1.8.1.4
next prev parent reply other threads:[~2013-07-22 19:38 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-22 17:50 [Qemu-devel] [PATCH 0/9] Add platform bus Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 1/9] PlatBus: Add Platform Bus Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 2/9] PlatBus: Add abstract Platform Device Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 3/9] PlatBus: Add Sysbus/Platform bridge device Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 4/9] PlatBus: Hook up into Makefile system Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 5/9] PPC: Add platform bus to the default compile set Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 6/9] PlatBus: Add serial-platbus device Alexander Graf
2013-07-22 18:26 ` Peter Maydell
2013-07-22 18:56 ` Alexander Graf
2013-07-24 20:16 ` Scott Wood
2013-07-24 20:25 ` Peter Maydell
2013-07-22 17:50 ` [Qemu-devel] [PATCH 7/9] PPC: Add PlatBus Serial to default configs Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 8/9] PPC: E500: Spawn PlatBus bridge for ppce500 machine Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 9/9] PPC: E500: Add PlatBus device tree walker Alexander Graf
2013-07-22 18:21 ` [Qemu-devel] [PATCH 0/9] Add platform bus Peter Maydell
2013-07-22 18:55 ` Alexander Graf
2013-07-23 12:19 ` Paolo Bonzini
2013-07-23 12:22 ` Peter Maydell
2013-07-23 12:34 ` Paolo Bonzini
2013-07-23 12:40 ` Peter Maydell
2013-07-23 13:06 ` Paolo Bonzini
2013-07-23 14:26 ` Anthony Liguori
2013-07-23 14:28 ` Peter Maydell
2013-07-23 12:29 ` François Revol
2013-07-22 19:38 ` Anthony Liguori [this message]
2013-07-22 19:44 ` Alexander Graf
2013-07-22 19:52 ` Anthony Liguori
2013-07-22 21:50 ` Peter Maydell
2013-07-22 22:05 ` Anthony Liguori
2013-07-22 22:34 ` Peter Maydell
2013-07-22 23:03 ` 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=87vc42jsgf.fsf@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=agraf@suse.de \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@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).