From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKgzn-0000ow-6a for qemu-devel@nongnu.org; Sun, 30 Oct 2011 21:49:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RKgzl-0002Og-E9 for qemu-devel@nongnu.org; Sun, 30 Oct 2011 21:49:03 -0400 Received: from e23smtp07.au.ibm.com ([202.81.31.140]:55163) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKgzk-0002OG-UL for qemu-devel@nongnu.org; Sun, 30 Oct 2011 21:49:01 -0400 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp07.au.ibm.com (8.14.4/8.13.1) with ESMTP id p9V1mtZH026926 for ; Mon, 31 Oct 2011 12:48:55 +1100 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p9V1mtZt1781856 for ; Mon, 31 Oct 2011 12:48:55 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p9V1msC3005947 for ; Mon, 31 Oct 2011 12:48:55 +1100 Date: Mon, 31 Oct 2011 11:36:58 +1100 From: David Gibson Message-ID: <20111031003658.GC9698@truffala.fritz.box> References: <1319983368-21801-1-git-send-email-avi@redhat.com> <4EAD5B6B.204@codemonkey.ws> <4EAD5D07.6060004@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EAD5D07.6060004@redhat.com> Subject: Re: [Qemu-devel] [PULL 0/3] 128-bit support for the memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Blue Swirl , qemu-devel@nongnu.org On Sun, Oct 30, 2011 at 04:19:51PM +0200, Avi Kivity wrote: > On 10/30/2011 04:12 PM, Anthony Liguori wrote: > > On 10/30/2011 09:02 AM, Avi Kivity wrote: > >> This somewhat controversial patchset converts internal arithmetic in the > >> memory API to 128 bits. > >> > >> It has been argued that with careful coding we can make 64-bit work as > >> well. I don't think this is true in general - a memory router can > >> adjust > >> addresses either forwards or backwards, and some buses (PCIe) need the > >> full 64-bit space - though it's probably the case for all the > >> configurations > >> we support today. Regardless, the need for careful coding means > >> subtle bugs, > >> which I don't want in a core API that is driven by guest supplied > >> values. > > > > The primary need for signed arithmetic is aliases, correct? > > > Where do we actually make use of this in practice? I think having > > negative address spaces is a weird aspect of the memory api and wonder > > if refactoring it away is a better solution tot he problem. > > There is no direct use of signed arithmetic in the API (just in the > implementation). Aliases can cause a region to move in either the > positive or negative direction, and this requires either signed > arithmetic or special casing the two directions. You keep saying we need signed arithmetic for this, but it's not really true. *If* you see aliases as shifting the entire aliases address space w.r.t., then just allowing a window to show through, you get negative offsets, yes, but that's by no means the only way t think about it. It's basically one spot - the alias handling in render_memory_region() - that generates a negative start intermediate. I'm convinced it's pretty straightforward to remove this - making a patch for it just hasn't bubbled to the top of my priority queue, though. > Signed arithmetic is not the only motivation - overflow is another. > Nothing prevents a user from placing a 64-bit 4k BAR at address > ffff_ffff_ffff_f000; we could move to base/limit representation, but > that will likely cause its own bugs. Finally, we should be able to > represent both a 0-sized region and a 2^64 sized region. Note that an (inclusive) start/end representation also cannot represent a 0 sized region. -- 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