From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMkjQ-0005zH-DW for qemu-devel@nongnu.org; Wed, 18 May 2011 13:40:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMkjP-0003S8-AJ for qemu-devel@nongnu.org; Wed, 18 May 2011 13:40:24 -0400 Received: from goliath.siemens.de ([192.35.17.28]:16867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMkjO-0003Ro-RR for qemu-devel@nongnu.org; Wed, 18 May 2011 13:40:23 -0400 Message-ID: <4DD40484.6030302@siemens.com> Date: Wed, 18 May 2011 19:40:20 +0200 From: Jan Kiszka 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> <4DD3FEC3.90108@redhat.com> In-Reply-To: <4DD3FEC3.90108@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel 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