From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37294) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMkDd-0005q4-R2 for qemu-devel@nongnu.org; Wed, 18 May 2011 13:07:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMkDb-0006j3-7v for qemu-devel@nongnu.org; Wed, 18 May 2011 13:07:33 -0400 Received: from david.siemens.de ([192.35.17.14]:25774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMkDa-0006ic-NU for qemu-devel@nongnu.org; Wed, 18 May 2011 13:07:31 -0400 Message-ID: <4DD3FCCE.1090605@siemens.com> Date: Wed, 18 May 2011 19:07:26 +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> In-Reply-To: <4DD3F83E.4090700@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 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