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

[Jan Kiszka]

On 2011-05-18 18:47, Avi Kivity wrote:
>>>>  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.
> 
> We won't have a natural ID.

The address of the data structure describing a region could be such a
thing. Provided, of course, we prepare a flatted view ahead of time, not
on the fly.

>  But I'll see if I can have a library
> calculate the minimum difference between the previous layout and current 
> layout.  Should not be too hard.

We need exact match on the client side with the old range. E.g. if you
put a new region over an existing one, effectively splitting it into two
halves, the core has to
 - shrink the existing range to form the first half
 - register two new ranges to reflect the rest

On unregistering of that overlap, we need the reverse. So all the client
has to do then is to decide if it is interested in some range, and then
store it internally with some additional data (and process it, of
course). No more merging, no more overlap detection and splitting up at
client level.

Jan

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