Re: [Qemu-devel] [RFC] Memory API

[Jan Kiszka]

On 2011-05-18 18:14, Avi Kivity wrote:
> On 05/18/2011 07:00 PM, Jan Kiszka wrote:
>> On 2011-05-18 17:42, Avi Kivity wrote:
>>>  On 05/18/2011 06:36 PM, Jan Kiszka wrote:
>>>>>
>>>>>   We need to head for the more hardware-like approach.  What happens when
>>>>>   you program overlapping BARs?  I imagine the result is
>>>>>   implementation-defined, but ends up with one region decoded in
>>>>>   preference to the other.  There is simply no way to reject an
>>>>>   overlapping mapping.
>>>>
>>>>  But there is also now simple way to allow them. At least not without
>>>>  exposing control about their ordering AND allowing to hook up managing
>>>>  code (e.g. of the PCI bridge or the chipset) that controls registrations.
>>>
>>>  What about memory_region_add_subregion(..., int priority) as I suggested
>>>  in another message?
>>
>> That's fine, but also requires a change how, or better where devices
>> register their regions.
> 
> Lost you - please elaborate.

Devices currently register against the core, that's nothing your API
automatically changes (though it lays the foundation to do so). But
devices should rather register against the corresponding bus. The bus
(ie. the device managing it) could then forward the request, stick it
into a subregion, or have it for dinner.

However, we are yet in troubles if we want to change that because
devices can only be on one bus - at least so far.

...
>> I'm specifically thinking of fully trackable slot updates. The clients
>> should not have to maintain the flat layout. They should just receive
>> updates in the form of slot X added/modified/removed. For now, this
>> magic happens multiple times in the clients, and that is very bad.
> 
> Slots don't have any meaning.  You can have a RAM region which is 
> overlaid by a smaller mmio region -> the RAM slot is split into two.
> 
> We should just send clients a list of ranges, and they can associate 
> them with slots themselves.

And that association logic should be as simple as matching a unique
range ID against an existing slot (for updates and deletions) or adding
a new slot for a new range and storing the ID. Anything else will not
allow to simplify the existing code bases noticeably. That's my point.

> 
>> Given that not only memory clients need that view but that ever TLB miss
>> (in TCG mode) requires to identify the effective slot as well, it might
>> be worth preparing a runtime structure at registration time that
>> supports this efficiently - but this time without wasting memory.
> 
> Yes.  Won't be easy though.  Perhaps a perfect hash table for small 
> regions and a sorted-by-size array for large regions.

Keep in mind that TCG will be our benchmark for these changes as it
requires much more accesses than KVM. We must avoid designing the new
infrastructure with exclusive focus on KVM (and also x86).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux