From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:48015)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1bUuWt-00014C-48
	for qemu-devel@nongnu.org; Wed, 03 Aug 2016 07:40:07 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1bUuWp-0002ET-3n
	for qemu-devel@nongnu.org; Wed, 03 Aug 2016 07:40:07 -0400
Message-ID: <1470224389.12584.96.camel@kernel.crashing.org>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 03 Aug 2016 21:39:49 +1000
In-Reply-To: <CAFEAcA-Efa+w5avjyk-fPU_wNUVcoy6mTZqTdu0NkWvokTUJjg@mail.gmail.com>
References: <1470211348.12584.68.camel@kernel.crashing.org>
	<CAFEAcA-QDTgzTsqT3x9FnCHOmLgho+AXwvxVct3M3=9qRjw1Vw@mail.gmail.com>
	<1470223732.12584.88.camel@kernel.crashing.org>
	<CAFEAcA-Efa+w5avjyk-fPU_wNUVcoy6mTZqTdu0NkWvokTUJjg@mail.gmail.com>
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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>, Anton Blanchard <anton@au1.ibm.com>, QEMU Developers <qemu-devel@nongnu.org>, David Gibson <david@gibson.dropbear.id.au>

On Wed, 2016-08-03 at 12:32 +0100, Peter Maydell wrote:
> Yeah, there's an LTP test that fails because of this (we
> send a SIGSEGV when we should be sending a SIGBUS). It's
> a bit painful to fix though, since as you say we've
> effectively thrown away some information. I'm inclined to
> put this in the big pile of "bugs we could fix if we
> ever implemented linux-user-with-softmmu" and otherwise
> ignore it, unless you have a real-world program that
> needs this and makes some kind of bodge fix worthwhile.

Nope, not really...

If we care, a simpler fix would be to add a "translate_user_fault" hook
to the CPU class that takes more info about the original signal than
handle_mmu_fault does, and call it when available (with a fallback)
from user-exec.c

That does mean going through all the=C2=A0cpu_signal_handler() variants i=
n
there though to make them extract more useful info.

Not sure it's worthwhile...

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 ? :-)

Cheers,
Ben
=2E