Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Avi Kivity <avi@redhat.com>]

On 04/30/2012 04:40 PM, Mark Cave-Ayland wrote:
> On 30/04/12 14:23, Avi Kivity wrote:
>
> Hi Avi,
>
>>> My understanding based upon this is that it would be impossible to
>>> register a different parent MemoryRegion without duplicating the init
>>> function for all shared devices which seems undesirable :(
>>
>> What are the requirements?  You need a different catch-all mmio handler
>> for each slot?  Or would one catch-all mmio handler for all sysbus
>> devices suffice?
>
> A single catch-all for all sysbus devices would suffice, however I'm
> thinking it makes sense to have one MemoryRegion per slot so that the
> devices can register onto the bus using their "slot relative" address
> to allow for potentially moving hardware between slots.

Ok, so you have a hierarchy: bus -> slot -> devices in slot?  That
hierarchy is present in the hardware too, or that's how I interpret
"slot relative addresses".

>
>>> The only solution I can think of is to make sysbus_mmio_map() more
>>> intelligent so that instead of blindly adding the device to the "root"
>>> MemoryRegion, it traverses down the MemoryRegion hierarchy starting
>>> from the root to the furtherest leaf node it can find based upon the
>>> specified address and then adds the new subregion there. Hence if I
>>> add my SBus memory regions first before call the various peripheral
>>> init functions, everything should end up in the correct part of the
>>> memory tree.
>>>
>>
>> This solution attempts to reconstruct the memory hierarchy from the
>> address, instead of maintaining it in the device tree.
>
> So I guess that is bad...

Well, it's a lot of work -> bad.

>
>>> I believe this should preserve compatibility for existing sysbus API
>>> users with just a single "root" MemoryRegion, however due to lack of
>>> any documentation related to sysbus I'm not sure if this would break
>>> other platforms or maybe even violate one of its key design features?
>>
>> IMO the best fix is to unsysbus the device and qomify it instead.  This
>> way we're 100% flexible in how we can attach it.
>
> That's interesting - I didn't realise that sysbus is a legacy
> interface with respect to QOM. 

Maybe it's just wishful thinking on my part.  But I always saw sysbus as
a wrong interface - it corresponds to no real bus and doesn't allow
hierarchy, unlike our pci or even isa implementations.

> Is there any documentation related to this? Then again, converting all
> of the devices over to QOM and testing that it doesn't break all
> platforms/busses suddenly becomes a huge job...
>

You can just follow Peter's suggestion, although qomification would be
preferable IMO.

-- 
error compiling committee.c: too many arguments to function