From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKW8G-00007x-V7 for qemu-devel@nongnu.org; Sun, 30 Oct 2011 10:13:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RKW8F-0000c4-NB for qemu-devel@nongnu.org; Sun, 30 Oct 2011 10:13:04 -0400 Received: from mail-iy0-f173.google.com ([209.85.210.173]:61936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKW8F-0000bt-K7 for qemu-devel@nongnu.org; Sun, 30 Oct 2011 10:13:03 -0400 Received: by iaqq3 with SMTP id q3so915491iaq.4 for ; Sun, 30 Oct 2011 07:13:02 -0700 (PDT) Message-ID: <4EAD5B6B.204@codemonkey.ws> Date: Sun, 30 Oct 2011 09:12:59 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1319983368-21801-1-git-send-email-avi@redhat.com> In-Reply-To: <1319983368-21801-1-git-send-email-avi@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Avi Kivity Cc: Blue Swirl , qemu-devel@nongnu.org, David Gibson 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. Regards, Anthony Liguori > > Avi Kivity (3): > Add support for 128-bit arithmetic > memory: use 128-bit integers for sizes and intermediates > Adjust system and pci address spaces to full 64-bit > > exec.c | 2 +- > hw/pc_piix.c | 2 +- > hw/pci_bridge.c | 2 +- > int128.h | 116 ++++++++++++++++++++++++++++++++ > memory.c | 196 ++++++++++++++++++++++++++++++++---------------------- > memory.h | 3 +- > 6 files changed, 237 insertions(+), 84 deletions(-) > create mode 100644 int128.h >