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

[Jan Kiszka]

On 2011-05-18 19:15, Avi Kivity wrote:
> On 05/18/2011 08:07 PM, Jan Kiszka wrote:
>> 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.
> 
> It will change as soon as the memory map changes.

...which is supposed to be properly reported to the client beforehand.

> 
>>>   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.
> 
> Right.  We do a symmetric set difference between the old and new maps 
> and let the client know what has changed.

That would be fine as well. Then the internal representation could be
anything, though I bet a flattened form would have its advantages.

Jan

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