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

[Avi Kivity <avi@redhat.com>]

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.

> >   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.

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