[Top][All Lists]

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH 0/5] Platform device support

From: Alexander Graf
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 0/5] Platform device support
Date: Fri, 27 Jun 2014 13:40:00 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 27.06.14 12:30, Andreas Färber wrote:
Am 26.06.2014 14:01, schrieb Alexander Graf:
On 20.06.14 08:43, Peter Crosthwaite wrote:
On Wed, Jun 4, 2014 at 10:28 PM, Alexander Graf <address@hidden> 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
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.
The more I think about it the more I believe #3 would be the cleanest.
The only thing my platform devices do in addition to sysbus devices is
that it exposes qdev properties to give mapping code hints where a
device wants to be mapped.

If we just add qdev properties for all the possible hints in generic
sysbus core code, we should be able to automatically convert all devices
into dynamically allocatable devices. Whether they actually do get
mapped and the generation of device tree chunks still stays in the the
machine file's court.
As discussed offline with Alex, one issue I see is that this would be
encouraging people to add more devices to an artificial global bus in
/machine/unassigned that we've been trying to obsolete, rather than
sitting down and please creating an e500 SoC object as a start. Maybe we
should start generating a list of shame for 2.1. ;)
Instantiating a new [Sys/AXI/AMBA/...]Bus inside that SoC object would
make me much happier than using SysBus as is.

The pure QOM approach would be link<> properties instead of a bus, but
then the machine needs to know how many "slots" there shall be in
advance. Note that the "docking procedure" is always initiated from the
realizing device, whether bus or no bus.

So my goal is to make life easy for users, not to fulfill some wet Anthony dreams :). And as a user, I want to be able to say -device foo and have that device created, like I do with PCI devices today.

There are 2 approaches to this that I can see:

1) A new special type of bus that allows for dynamic allocation and that knows a flat numbering scheme 2) Individual devices that get attached to whatever the machine file thinks makes it happy (basically emulating the above bus, but with more flexibility)

I implemented option 1 with the "Platform bus". It's basically an abstraction of the Sys/AXI/AMBA idea but only with a single bus implementation, as everything else would just be ridiculously redundant (and if necessary could be implemented as a subclass on top of the bridge device). People didn't like it.

I implemented option 2 with the Platform devices - this patch set. People didn't like it because it duplicates SysBus devices - and it does.

I'm implementing 2 as an add-on of SysBusDevice now which to me really isn't too much different from a dangling QOM device.

Linking devices by force (set IRQ0 to MPIC IRQ 32, map region0 to physical address space offset 0x12300) is a nice thing to have for people who know what they're doing. That matches probably about 0.00001% of our user base - I personally am not included there. We *have* to have a mechanism to make device creation easy for users if we want to have any.


reply via email to

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