From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFylf-0000Ny-L8 for qemu-devel@nongnu.org; Mon, 17 Oct 2011 21:47:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFyle-0000bk-1u for qemu-devel@nongnu.org; Mon, 17 Oct 2011 21:46:59 -0400 Received: from ozlabs.org ([203.10.76.45]:44215) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFyld-0000VE-5Q for qemu-devel@nongnu.org; Mon, 17 Oct 2011 21:46:57 -0400 Date: Tue, 18 Oct 2011 12:38:48 +1100 From: David Gibson Message-ID: <20111018013848.GA6655@truffala.fritz.box> References: <1318387026-21569-1-git-send-email-david@gibson.dropbear.id.au> <4E9AAA33.3010806@redhat.com> <20111016114011.GG4580@truffala.fritz.box> <4E9ACF99.9020507@redhat.com> <20111017053153.GB30114@truffala.fritz.box> <4E9C04AB.6000003@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E9C04AB.6000003@redhat.com> Subject: Re: [Qemu-devel] [PATCH] Memory API bugfix - abolish addrrrange_end() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: aik@ozlabs.ru, agraf@suse.de, qemu-devel@nongnu.org On Mon, Oct 17, 2011 at 12:34:19PM +0200, Avi Kivity wrote: > On 10/17/2011 07:31 AM, David Gibson wrote: > > > > > > In terms of how the code looks, it's seriously more ugly (see the > > > patches I sent out). Conceptually it's cleaner, since we're not dodging > > > the issue that we need to deal with a full 64-bit domain. > > > > We don't have to dodge that issue. I know how to remove the > > requirement for intermediate negative values, I just haven't made up a > > patch yet. With that we can change to uint64 and cover the full 64 > > bit range. In fact I think I can make it so that size==0 represents > > size=2^64 and even handle the full 64-bit, inclusive range properly. > > That means you can't do a real size == 0. Yeah... a memory range with size 0 has no effect by definition, I think we can do without it. > > > But my main concern is maintainability. The 64-bit blanket is to short, > > > if we keep pulling it in various directions we'll just expose ourselves > > > in new ways. > > > > Nonsense, dealing with full X-bit range calculations in X-bit types is > > a fairly standard problem. The kernel does it in VMA handling for > > one. It just requires thinking about overflow cases. > > We discovered three bugs already (you found two, and I had one during > development). Even if it can probably be done with extreme care, but is > it worth spending all that development time on? > > I'm not sure there is a parallel with vmas, since we're offsetting in > both the positive and negative directions. I think the so-called "negative offsetting" is just an artifact of our implementation. I don't see that it's any different from having a VMA whose file offset is larger than its memory address. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson