From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35756) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKWEx-0001EF-Rb for qemu-devel@nongnu.org; Sun, 30 Oct 2011 10:20:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RKWEw-0001st-AT for qemu-devel@nongnu.org; Sun, 30 Oct 2011 10:19:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:29849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKWEw-0001sj-0S for qemu-devel@nongnu.org; Sun, 30 Oct 2011 10:19:58 -0400 Message-ID: <4EAD5D07.6060004@redhat.com> Date: Sun, 30 Oct 2011 16:19:51 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1319983368-21801-1-git-send-email-avi@redhat.com> <4EAD5B6B.204@codemonkey.ws> In-Reply-To: <4EAD5B6B.204@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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: Anthony Liguori Cc: Blue Swirl , qemu-devel@nongnu.org, David Gibson 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. 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. -- error compiling committee.c: too many arguments to function