All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
To: Alexander Graf <agraf@suse.de>, Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-ppc Mailing List <qemu-ppc@nongnu.org>,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	Eric Auger <eric.auger@linaro.org>
Subject: Re: [Qemu-devel] [PATCH 0/5] Platform device support
Date: Fri, 20 Jun 2014 16:43:42 +1000	[thread overview]
Message-ID: <CAEgOgz4HjJqje4aGYORVY23R4fp=ng_i+BLLgEt1ra++LU5mBA@mail.gmail.com> (raw)
In-Reply-To: <1401884936-12907-1-git-send-email-agraf@suse.de>

On Wed, Jun 4, 2014 at 10:28 PM, Alexander Graf <agraf@suse.de> wrote:
> 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 or via really complicated command line arguments under
> discussion upstream right now.
>

What you are doing seem to me to be an extension of SysBus - you are
defining the same interfaces as sysbus but also adding some machine
specifics wiring info. I think it's a candidate for QOM inheritance to
avoid having to dup all the sysbus device models for both regular
sysbus and platform bus. I think your functionality should be added as
one of

1: and interface that can be added to sysbus devices
2: a new abstraction that inherits from SYS_BUS_DEVICE
3: just new features to the sysbus core.

Then both of us are using the same suite of device models and the
differences between our approaches are limited to machine level
instantiation method. My gut says #2 is the cleanest.

> 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.
>
> So the idea for platform devices arose. A platform device is really just a
> device that exposes its qemu_irq slots and memory regions to the world.
>
> That allows us to write machine specific code that maps a platform device
> wherever the machine thinks fits nicely. It also allows that same machine
> to generate a device tree entry for platform devices easily, as it is fully
> aware of the interrupt lines and places it was mapped to.
>
> A device (read: user) 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 can get mapped at convenient places by the machine.
>
> 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...
>
> Alexander Graf (5):
>   Platform: Add platform device class
>   Platform: Add serial device
>   PPC: e500: Only create dt entries for existing serial ports
>   PPC: e500: Support platform devices
>   PPC: e500: Add support for platform serial devices
>
>  default-configs/ppc-softmmu.mak   |   2 +
>  default-configs/ppc64-softmmu.mak |   2 +
>  hw/Makefile.objs                  |   1 +
>  hw/char/Makefile.objs             |   1 +
>  hw/char/serial-platform.c         | 103 +++++++++++++++

I think a big point of confusion here is you have picked a
not-even-qdevified device for conversion. Boards are still calling
serial_mm_init() directly due to lack of a proper device for Sysbus
serial.

Do you have another device that already QOMified (a MAC or something
perhaps?) that you can convert more minimally to demonstrate the
approach for existing sysbus devs?

Sysbusification of serial would then be a step towards platform-device serial.

Regards,
Peter

>  hw/platform/Makefile.objs         |   1 +
>  hw/platform/device.c              | 108 ++++++++++++++++
>  hw/ppc/e500.c                     | 262 +++++++++++++++++++++++++++++++++++++-
>  hw/ppc/e500.h                     |   1 +
>  hw/ppc/e500plat.c                 |   1 +
>  include/hw/char/serial-platform.h |  56 ++++++++
>  include/hw/platform/device.h      |  45 +++++++
>  12 files changed, 577 insertions(+), 6 deletions(-)
>  create mode 100644 hw/char/serial-platform.c
>  create mode 100644 hw/platform/Makefile.objs
>  create mode 100644 hw/platform/device.c
>  create mode 100644 include/hw/char/serial-platform.h
>  create mode 100644 include/hw/platform/device.h
>
> --
> 1.8.1.4
>
>

  parent reply	other threads:[~2014-06-20  6:44 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-04 12:28 [Qemu-devel] [PATCH 0/5] Platform device support Alexander Graf
2014-06-04 12:28 ` [Qemu-devel] [PATCH 1/5] Platform: Add platform device class Alexander Graf
2014-06-19 14:51   ` Eric Auger
2014-06-04 12:28 ` [Qemu-devel] [PATCH 2/5] Platform: Add serial device Alexander Graf
2014-06-04 12:28 ` [Qemu-devel] [PATCH 3/5] PPC: e500: Only create dt entries for existing serial ports Alexander Graf
2014-06-04 12:28 ` [Qemu-devel] [PATCH 4/5] PPC: e500: Support platform devices Alexander Graf
2014-06-13  8:58   ` Bharat.Bhushan
2014-06-13  9:46     ` Alexander Graf
2014-06-19 14:56   ` Eric Auger
2014-06-19 21:40     ` Alexander Graf
2014-06-27  9:29   ` Eric Auger
2014-06-27 11:30     ` Alexander Graf
2014-06-27 16:50       ` Eric Auger
2014-06-04 12:28 ` [Qemu-devel] [PATCH 5/5] PPC: e500: Add support for platform serial devices Alexander Graf
2014-06-19 20:54 ` [Qemu-devel] [PATCH 0/5] Platform device support Paolo Bonzini
2014-06-19 21:38   ` Alexander Graf
2014-06-20  6:43 ` Peter Crosthwaite [this message]
2014-06-20  7:39   ` Paolo Bonzini
2014-06-26 12:01   ` Alexander Graf
2014-06-27 10:30     ` Andreas Färber
2014-06-27 10:54       ` Peter Crosthwaite
2014-06-27 11:17         ` Andreas Färber
2014-06-27 11:24           ` Alexander Graf
2014-06-27 11:48             ` Paolo Bonzini
2014-06-27 11:52               ` Peter Maydell
2014-06-27 12:00                 ` Paolo Bonzini
2014-06-27 11:41         ` Alexander Graf
2014-06-27 11:40       ` Alexander Graf

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='CAEgOgz4HjJqje4aGYORVY23R4fp=ng_i+BLLgEt1ra++LU5mBA@mail.gmail.com' \
    --to=peter.crosthwaite@xilinx.com \
    --cc=agraf@suse.de \
    --cc=eric.auger@linaro.org \
    --cc=pbonzini@redhat.com \
    --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.