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

[Alexander Graf <agraf@suse.de>]

On 27.06.14 12:54, Peter Crosthwaite wrote:
> On Fri, Jun 27, 2014 at 8:30 PM, Andreas Färber <afaerber@suse.de> 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.
>>
> Do you mean &address_space_memory (as used by sysbus_mmio_map)? We all
> hate that global singleton, but can we decouple it from sysbus which
> is not the root cause of that problem? sysbus_mmio_map usages just
> need to be replaced with sysbus_mmio_get_region and you can create
> whatever heirachy you want using unchanged sysbus devices.
>
> Even if we phase out the global singleton and the SysBus "bus", the
> sysbus "device" abstraction is still sound and should be usable
> busless. Then theres no need a for a tree-wide to implement Alex's
> feature for all devs (assuming his plugger can be made to work
> hintless?).

The plugger works just fine when you don't give hints - then it's up to 
dynamic allocation (same as PCI).

Yes I fully agree with you here.


Alex