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

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