Re: [PATCH 0/9] hw/sysbus/platform-bus: Introduce TYPE_DYNAMIC_SYS_BUS_DEVICE

[Bernhard Beschow <shentey@xxxxxxxxx>]

Am 28. Januar 2025 15:10:18 UTC schrieb "Philippe Mathieu-Daudé" 
<philmd@xxxxxxxxxx>:
>On 28/1/25 13:57, BALATON Zoltan wrote:
>> On Tue, 28 Jan 2025, Peter Maydell wrote:
>>> On Tue, 28 Jan 2025 at 10:42, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote:
>>>> 
>>>> On Sat, Jan 25, 2025 at 07:13:34PM +0100, Philippe Mathieu-Daudé wrote:
>>>>> Some SysBus devices can optionally be dynamically plugged onto
>>>>> the sysbus-platform-bus (then virtual guests are aware of
>>>>> mmio mapping and IRQs via device tree / ACPI rules).
>>>> 
>>>> Do we have some sane way to have user-pluggable sysbus devices on arm?
>>> 
>>> The answer in a general sense is "no, because user pluggable
>>> sysbus is a weird idea". "sysbus" means "it's wired into a
>>> specific bit of the memory map and to specific IRQs, and whoever
>>> does that needs to know what IRQs and bits of memory are usable,
>>> and the guest OS needs to know it's there". "user-pluggable" means
>>> "it's all automatic and the guest can just do some kind of
>>> probing for what is or isn't present". All the platform bus stuff
>>> is a nasty mess that's working around the things people want
>>> to plug in not being clean devices on probeable buses :-(
>>> And the platform bus is only supported on the "virt" board,
>>> because that's the only one where QEMU is generating its
>>> own dtb or ACPI tables where it can tell the guest "hey,
>>> there's some device here".
>> 
>> There are some SoCs that have memory mapped devices but different versions 
>> in the same family have different devices. Either older ones missing some 
>> devices or have less USB or network ports while newer SoCs have more of 
>> those or they have PCIe instead of PCI. Modelling these could use pluggable 
>> sysbus devices so one could add the devices needed for a SoC version without 
>> having to write or modify a board code. I think Bernhard's attempt to try 
>> creating e500 SoCs from a device tree goes in that direction too. We could 
>> also model this by having a SoC that can instantiate devices based on some 
>> properties but maybe pluggable devices could be more generic for this. The 
>> issue seems to be how to tell the board or SoC where to map it and what IRQ 
>> to connect it as this is done by the board and not the device so properties 
>> on the device to set these does not really help unless the board can somehow 
>> query it and instantiate the devices based on that. Otherwise whatever 
>> handles the -device option to create the device would need knowledge about 
>> the board. (E.g. the e500 devices are mapped in the CCSR memory region so 
>> one can't just use system address space for them.)
>
>IIRC Bernard's series takes a DTB as input and create the machine
>matching this DTB.

That's correct. It's still on my todo list to send an RFC. I first wanted to 
gain some experience implementing a machine in the classic way which I've now 
done by means of the imx8mp-evk series. Once I clean up the e500-fdt branch I'd 
send an RFC.

Best regards,
Bernhard

>
>As Peter explained, sysbus-platform-bus fits TYPE_DYNAMIC_SYS_BUS_DEVICE
>in free slots, then generates the corresponding ACPI/DTB.
>
>What you describe seems closer to the QEMU Dynamic Machine project,
>following Damien's idea:
>https://lore.kernel.org/qemu-devel/20220223090706.4888-1-damien.hedde@xxxxxxxxxxxxx/
>We are not quite there yet...