From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36143) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ugrqq-0000VH-07 for qemu-devel@nongnu.org; Mon, 27 May 2013 03:28:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ugrqn-0003GJ-Ta for qemu-devel@nongnu.org; Mon, 27 May 2013 03:28:15 -0400 Received: from mail-ea0-x22e.google.com ([2a00:1450:4013:c01::22e]:61107) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ugrqn-0003EY-Mt for qemu-devel@nongnu.org; Mon, 27 May 2013 03:28:13 -0400 Received: by mail-ea0-f174.google.com with SMTP id z7so3596563eaf.5 for ; Mon, 27 May 2013 00:28:12 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51A30B04.1040702@redhat.com> Date: Mon, 27 May 2013 09:28:04 +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> <51A25D60.9000502@redhat.com> <51A279C0.50601@de.ibm.com> In-Reply-To: <51A279C0.50601@de.ibm.com> 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: Christian Borntraeger Cc: qemu-devel@nongnu.org, Alexander Graf , Avi Kivity , =?ISO-8859-15?Q?Andreas_F=E4rber?= Il 26/05/2013 23:08, Christian Borntraeger ha scritto: > On 26/05/13 21:07, Paolo Bonzini wrote: >> 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. > > I would prefer to allow 64bit of address space. Memory on s390x can be > discontiguous. It is currently not used under KVM and it might not make > a lot of sense, but the current KVM code would allow a guest that has a > layout of lets say 0...1GB + 16EB-1GB...16EB. > > Furthermore, I know of some (prototype only) hw memory devices that actually > populated the upper memory addresses. If such a thing becomes reality in the > future we cannot provide virtualization of those. Ok, I'll drop this patch and the next one from the pull request. Paolo