Re: [PATCH 0/9] Deprecate sysbus_get_default() and get_system_memory() et. al

[Bernhard Beschow <shentey@xxxxxxxxx>]

Am 20. September 2022 15:36:26 UTC schrieb Mark Cave-Ayland 
<mark.cave-ayland@xxxxxxxxxxxx>:
>On 20/09/2022 10:55, Peter Maydell wrote:
>
>> On Tue, 20 Sept 2022 at 00:18, Bernhard Beschow <shentey@xxxxxxxxx> wrote:
>>> 
>>> In address-spaces.h it can be read that get_system_memory() and
>>> get_system_io() are temporary interfaces which "should only be used 
>>> temporarily
>>> until a proper bus interface is available". This statement certainly 
>>> extends to
>>> the address_space_memory and address_space_io singletons.
>> 
>> This is a long standing "we never really completed a cleanup"...
>> 
>>> This series attempts
>>> to stop further proliferation of their use by turning TYPE_SYSTEM_BUS into 
>>> an
>>> object-oriented, "proper bus interface" inspired by PCIBus.
>>> 
>>> While at it, also the main_system_bus singleton is turned into an attribute 
>>> of
>>> MachineState. Together, this resolves five singletons in total, making the
>>> ownership relations much more obvious which helps comprehension.
>> 
>> ...but I don't think this is the direction we want to go.
>> Overall the reason that the "system memory" and "system IO"
>> singletons are weird is that in theory they should not be necessary
>> at all -- board code should create devices and map them into an
>> entirely arbitrary MemoryRegion or set of MemoryRegions corresponding
>> to address space(s) for the CPU and for DMA-capable devices. But we
>> keep them around because
>>   (a) there is a ton of legacy code that assumes there's only one
>>       address space in the system and this is it
>>   (b) when modelling the kind of board where there really is only
>>       one address space, having the 'system memory' global makes
>>       the APIs for creating and connecting devices a lot simpler
>> 
>> Retaining the whole-system singleton but shoving it into MachineState
>> doesn't really change much, IMHO.
>> 
>> More generally, sysbus is rather weird because it isn't really a
>> bus. Every device in the system of TYPE_SYS_BUS_DEVICE is "on"
>> the unique TYPE_SYSTEM_BUS bus, but that doesn't mean they're
>> all in the same address space or that in real hardware they'd
>> all be on the same bus. sysbus has essentially degraded into a
>> hack for having devices get reset. I really really need to make
>> some time to have another look at reset handling. If we get that
>> right then I think it's probably possible to collapse the few
>> things TYPE_SYS_BUS_DEVICE does that TYPE_DEVICE does not down
>> into TYPE_DEVICE and get rid of sysbus altogether...
>
>Following on from one of the discussion points from Alex's KVM Forum BoF 
>session: I think longer term what we need to aim for is for QEMU machines to 
>define their own address spaces, and then bind those address spaces containing 
>memory-mapped devices to one or more CPUs.

Isn't that more or less impossible with singletons?

>
>Once this in place, as Peter notes above it just remains to solve the reset 
>problem and then it becomes possible to eliminate sysbus altogether as 
>everything else can already be managed by qdev/QOM.

Also see my reply to Peter.

Thanks,
Bernhard
>
>
>ATB,
>
>Mark.