From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgwuV-0006F8-0i for qemu-devel@nongnu.org; Mon, 27 May 2013 08:52:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UgwuR-00053m-LW for qemu-devel@nongnu.org; Mon, 27 May 2013 08:52:22 -0400 Received: from cantor2.suse.de ([195.135.220.15]:57649 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgwuR-00053L-Ek for qemu-devel@nongnu.org; Mon, 27 May 2013 08:52:19 -0400 Message-ID: <51A35701.80305@suse.de> Date: Mon, 27 May 2013 14:52:17 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= 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> <51A30B04.1040702@redhat.com> In-Reply-To: <51A30B04.1040702@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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: Paolo Bonzini Cc: Christian Borntraeger , Alexander Graf , qemu-devel@nongnu.org Am 27.05.2013 09:28, schrieb Paolo Bonzini: > 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=E4rber 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 [...] >> I would prefer to allow 64bit of address space. Memory on s390x can be= =20 >> discontiguous. It is currently not used under KVM and it might not mak= e >> a lot of sense, but the current KVM code would allow a guest that has= a=20 >> layout of lets say 0...1GB + 16EB-1GB...16EB.=20 >> >> Furthermore, I know of some (prototype only) hw memory devices that ac= tually >> populated the upper memory addresses. If such a thing becomes reality = in the >> future we cannot provide virtualization of those. >=20 > Ok, I'll drop this patch and the next one from the pull request. It has already been merged, that's how I became aware of it: http://git.qemu.org/?p=3Dqemu.git;a=3Dcommit;h=3Dfd469df97ab4277411ecdd40= 32a2f045a3a87b2a Note that Alex is currently absent, so please CC some of the other s390x folks or wait for an ack if you plan alternative changes. Cheers, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg