From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54411) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UggHy-0003oJ-UD for qemu-devel@nongnu.org; Sun, 26 May 2013 15:07:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UggHr-0001L4-3O for qemu-devel@nongnu.org; Sun, 26 May 2013 15:07:30 -0400 Received: from mail-ea0-x22b.google.com ([2a00:1450:4013:c01::22b]:36082) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UggHq-0001Kt-T9 for qemu-devel@nongnu.org; Sun, 26 May 2013 15:07:23 -0400 Received: by mail-ea0-f171.google.com with SMTP id b15so3512767eae.2 for ; Sun, 26 May 2013 12:07:22 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51A25D60.9000502@redhat.com> Date: Sun, 26 May 2013 21:07:12 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1369414987-8839-1-git-send-email-pbonzini@redhat.com> <1369414987-8839-13-git-send-email-pbonzini@redhat.com> <51A218DF.2070506@suse.de> In-Reply-To: <51A218DF.2070506@suse.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 12/15] s390x: reduce TARGET_PHYS_ADDR_SPACE_BITS to 62 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-15?Q?Andreas_F=E4rber?= Cc: Christian Borntraeger , Alexander Graf , qemu-devel@nongnu.org, Avi Kivity Il 26/05/2013 16:14, Andreas Färber ha scritto: > > With the next patch, the memory API will complain if the > > TARGET_PHYS_ADDR_SPACE_BITS gets dangerously close to an > > overflow. s390x can handle up to 64 bit of physical address > > space from its page tables, but we never use that much. Just > > decrease the value. > > > > Cc: Alexander Graf > > Signed-off-by: Paolo Bonzini > > Didn't Avi introduce 128-bit arithmetic into QEMU to avoid 64-bit values > overflowing? Why are you limiting Memory API to 62-bit now? The next patch makes a difference between artificial memory regions (containers and aliases) which can have arbitrary placement and width, and the final view of the address space which cannot have a full 64-bit size. 63 bits probably would work, but I preferred to be safe since 62 is the largest used by other targets. It should be fixable, but if it is not a problem I wouldn't worry much about it. Paolo