From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44380) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKX2L-0006YH-VE for qemu-devel@nongnu.org; Sun, 30 Oct 2011 11:11:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RKX2K-00012B-K3 for qemu-devel@nongnu.org; Sun, 30 Oct 2011 11:11:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKX2K-000125-C5 for qemu-devel@nongnu.org; Sun, 30 Oct 2011 11:11:00 -0400 Message-ID: <4EAD68FB.9090209@redhat.com> Date: Sun, 30 Oct 2011 17:10:51 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1319983368-21801-1-git-send-email-avi@redhat.com> <4EAD5B6B.204@codemonkey.ws> <4EAD5D07.6060004@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Blue Swirl Cc: qemu-devel@nongnu.org, David Gibson On 10/30/2011 04:59 PM, Blue Swirl wrote: > > > > 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. > > > > 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. > > It looks like 64 bit saturating arithmetic could also work. Depends when you saturate. The standard example (vga) takes a alias of (say) 0xe01a0000 and aliases it into 0x000a0000. So you need to adjust addresses downwards by -0xe0100000. That brings the start of the real region (0xe0000000) into the negative territory. Saturating it there would break it. > It should > also be possible to work only with (start, end) address pairs and > never with start + size, then 2^64 shouldn't be an issue. Then 0 becomes an issue (end < start). -- error compiling committee.c: too many arguments to function