[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Memory API: handling unassigned physical memory
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] Memory API: handling unassigned physical memory |
Date: |
Tue, 01 May 2012 15:46:46 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 |
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
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, (continued)
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Mark Cave-Ayland, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Peter Maydell, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Avi Kivity, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Anthony Liguori, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Avi Kivity, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Anthony Liguori, 2012/05/01
Re: [Qemu-devel] Memory API: handling unassigned physical memory, Avi Kivity, 2012/05/01
Re: [Qemu-devel] Memory API: handling unassigned physical memory,
Avi Kivity <=