All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.