From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44578) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMkLi-0008RY-5R for qemu-devel@nongnu.org; Wed, 18 May 2011 13:15:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMkLf-0007v4-Ph for qemu-devel@nongnu.org; Wed, 18 May 2011 13:15:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMkLf-0007uv-Gr for qemu-devel@nongnu.org; Wed, 18 May 2011 13:15:51 -0400 Message-ID: <4DD3FEC3.90108@redhat.com> Date: Wed, 18 May 2011 20:15:47 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4DD3C5B9.1080908@redhat.com> <4DD3D236.90708@siemens.com> <4DD3D95E.2060105@redhat.com> <4DD3E1B3.3020405@siemens.com> <4DD3E47F.9060104@redhat.com> <4DD3E782.8090208@siemens.com> <4DD3E8D6.6090807@redhat.com> <4DD3ED22.6080005@siemens.com> <4DD3F055.6000905@redhat.com> <4DD3F626.7060500@siemens.com> <4DD3F83E.4090700@redhat.com> <4DD3FCCE.1090605@siemens.com> In-Reply-To: <4DD3FCCE.1090605@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel 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