From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:38303)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <qemu@g3gg0.de>) id 1W6zIk-0006Ag-7L
	for qemu-devel@nongnu.org; Sat, 25 Jan 2014 04:13:24 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <qemu@g3gg0.de>) id 1W6zIe-0000Mb-CE
	for qemu-devel@nongnu.org; Sat, 25 Jan 2014 04:13:18 -0500
Received: from gluon.lx-networking.de ([178.63.72.57]:43487)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <qemu@g3gg0.de>) id 1W6zIe-0000LI-5m
	for qemu-devel@nongnu.org; Sat, 25 Jan 2014 04:13:12 -0500
Message-ID: <52E38029.2080308@g3gg0.de>
Date: Sat, 25 Jan 2014 10:13:13 +0100
From: Georg Hofstetter <qemu@g3gg0.de>
MIME-Version: 1.0
References: <CAFEAcA8UF0m3K8p_cOYQ64gRwcxYY5ZxdOX5pAs9dk8APc+MwA@mail.gmail.com>
	<20140124123156.7ecda5d7a994df1097c89ef9@gmail.com>
In-Reply-To: <20140124123156.7ecda5d7a994df1097c89ef9@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] QEMU ARM946 emulation, DIGIC,
	and MPU fault handling
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: Antony Pavlov <antonynpavlov@gmail.com>, Peter Maydell <peter.maydell@linaro.org>
Cc: Alex Dumitrache <broscutamaker@gmail.com>, Giovanni Condello <condellog@gmail.com>, QEMU Developers <qemu-devel@nongnu.org>, g3gg0 <georg.hofstetter@lx-networking.de>, =?UTF-8?B?QW5kcmVhcyBGw6RyYmU=?= =?UTF-8?B?cg==?= <afaerber@suse.de>

Am 24.01.2014 09:31, schrieb Antony Pavlov:
> On Thu, 23 Jan 2014 22:25:36 +0000
> Peter Maydell <peter.maydell@linaro.org> wrote:
> 
>> Since the 946 doesn't provide any way to find out what the fault
>> address actually was (it has no DFAR or IFAR) I presume that all
>> guest software treats a data abort or prefetch abort as a fatal error,
>> which is probably part of why nobody's ever noticed this.

Hi,

speaking for EOS models: indeed the original manufacturer's OS does not
handle these cases very different. They pick up the context (including
LR, the failing instruction), print an error message and kill the
failing task.

So at least the original OS does not use MPU systematically, like it
would be necessary for some kind of swapping etc.

BR,
Georg