From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWCIW-0004Wx-8U for qemu-devel@nongnu.org; Sat, 06 Aug 2016 20:50:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWCIT-0003Ls-Pc for qemu-devel@nongnu.org; Sat, 06 Aug 2016 20:50:34 -0400 Message-ID: <1470531016.12584.180.camel@kernel.crashing.org> From: Benjamin Herrenschmidt Date: Sun, 07 Aug 2016 10:50:16 +1000 In-Reply-To: References: <1470211348.12584.68.camel@kernel.crashing.org> <1470223732.12584.88.camel@kernel.crashing.org> <1470224389.12584.96.camel@kernel.crashing.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] ppc: Stop dumping state on all exceptions in linux-user List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , Peter Maydell Cc: Anton Blanchard , "qemu-ppc@nongnu.org" , QEMU Developers , David Gibson On Sat, 2016-08-06 at 15:23 +0530, Richard Henderson wrote: > On 08/03/2016 05:09 PM, Benjamin Herrenschmidt wrote: > >=20 > > As far user-with-softmmu, I'm not too sure... softmmu significantly > > increases the overhead of load and stores. Maybe after we add 128-bit > > integers to TGC to alleviate that a bit ? :-) >=20 > It wouldn't be mandatory, but there are certain bugs we can't fix witho= ut it.=C2=A0 > The big issues to be fixed with softmmu are >=20 > (1) Host page size > guest page size. >=20 > E.g. there are many programs (i386, sparc, etc, all with 4k pages) that= you=C2=A0 > can't even load, much less run, on a ppc64 host using a 64k page size. Can't we advertise the host page size to the guest ? Or there are too man= y compiled-in assumptions ? > > (2) Host virtual address space bits !=3D guest virtual address space = bits >=20 > My alpha emulation has run into this.=C2=A0=C2=A0A real Alpha guest has= a 44-bit address=C2=A0 > space, but an x86_64 host has a 48-bit address space.=C2=A0=C2=A0The x8= 6_64 kernel cannot=C2=A0 > be persuaded to reliably map memory below (1ul << 44), so I have to pre= tend=C2=A0 > than Alpha has a 48-bit address space.=C2=A0=C2=A0(Indeed, I set this t= o 63 bits, so that=C2=A0 > it works for even wider va, like on ppc64 and sparc64.) You can't just set a no-access VMA covering the top of the address space = ? Are alpha programs relying on the fact that they won't get addresses above 44= ? > > More theoretically, if the guest uses high bits for some purpose (e.g= . ia64=C2=A0 > segmentation in the top 3 bits), and the host doesn't have a full 64-bi= t=C2=A0 > virtual address space, then we cannot even map the program, since we ca= nnot set=C2=A0 > bits 61-63 to non-zero values. I see. We could definitely have the option then. Cheers, Ben.