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

[Alexander Graf <agraf@suse.de>]

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


Alex