From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45078) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUuMH-0008Ol-OH for qemu-devel@nongnu.org; Wed, 03 Aug 2016 07:29:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUuMD-0007hZ-CP for qemu-devel@nongnu.org; Wed, 03 Aug 2016 07:29:09 -0400 Message-ID: <1470223732.12584.88.camel@kernel.crashing.org> From: Benjamin Herrenschmidt Date: Wed, 03 Aug 2016 21:28:52 +1000 In-Reply-To: References: <1470211348.12584.68.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: Peter Maydell Cc: "qemu-ppc@nongnu.org" , Anton Blanchard , QEMU Developers , David Gibson On Wed, 2016-08-03 at 12:05 +0100, Peter Maydell wrote: > On 3 August 2016 at 09:02, Benjamin Herrenschmidt > > wrote: > >=20 > > Other archs don't do it, some programs catch signals just fine > > and those dumps just clutter the output. Keep the dumps for cases > > that aren't supposed to happen such as unknown codes. > >=20 > > > > Signed-off-by: Benjamin Herrenschmidt > > --- > > =C2=A0linux-user/main.c | 14 -------------- > > =C2=A01 file changed, 14 deletions(-) > >=20 > > diff --git a/linux-user/main.c b/linux-user/main.c > > index eb9975c..8fbc5a6 100644 > > --- a/linux-user/main.c > > +++ b/linux-user/main.c > > @@ -1651,9 +1651,6 @@ void cpu_loop(CPUPPCState *env) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Abo= rting\n"); > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0break; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0case POWERPC_EX= CP_DSI:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0/* Data storage exception=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0*/ > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0EXCP_DUMP(env, "Invalid data memory access: 0x" TARGET_FMT_lx "\n", > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0env->spr[S= PR_DAR]); > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0/* XXX: check this. Seems bugged */ >=20 > Are you removing these XXX comments because you've checked the > error code cases below? If so it would be useful to say so > in the commit message... Well I fix some of it in another patch... To the best of my understanding we only ever generate 0x40000000 and 0x42000000 via ppc_cpu_handle_mmu_fault() in user_only_helper.c unless there's another path to DSI in user mode that I missed. That being said, the comment isn't useful anyway. Nobody looks at it :-) I can respin with the comment back in or do put some blurb in the cset comment, let me know. BTW. I noticed, the generic path from the original signal coming from the host kernel through to here loses the information that would allow us to differenciate between a map error (no mapping) or a protection fault. It's a bit unfortunate, not sure if we can do much about it though without stopping to hijack the existing MMU translate hook in the CPU class and using a user mode dediated one that takes that sort of info as an argument. Cheers, Ben.