From: Stefan Weil <sw@weilnetz.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Hervé Poussineau" <hpoussin@reactos.org>,
"Andreas Färber" <afaerber@suse.de>,
"Aurélien Jarno" <aurelien@aurel32.net>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory
Date: Mon, 05 Aug 2013 07:19:08 +0200 [thread overview]
Message-ID: <51FF35CC.4090700@weilnetz.de> (raw)
In-Reply-To: <CAFEAcA8Eg0un4kDHvjr_MgOPuu+_dH3GyCeb-fSqn0PDD2ao6g@mail.gmail.com>
Am 05.08.2013 00:37, schrieb Peter Maydell:
> On 4 August 2013 23:04, Aurélien Jarno <aurelien@aurel32.net> wrote:
>> The real hardware probably returns all 1 or all 0 for addresses not
>> decoded to a device. This is what QEMU should model, and it should
>> not trigger a DBE or IBE exception. Looking at the current MIPS
>> documentation, Bus Error is defined as:
>>
>> A bus error exception occurs when an instruction or data access makes a
>> bus request (due to a cache miss or an uncacheable reference) and
>> that request terminates in an error.
>>
>> Older CPU documentation like the R4000 have a more precise definition:
>>
>> A Bus Error exception is raised by board-level circuitry for events such
>> as bus time-out, backplane bus parity errors, and invalid physical memory
>> addresses or access types.
>>
>> As we don't model this kind of errors, we should definitely just not
>> trigger an exception in that case, and even logging the event as
>> unimplemented is probably wrong.
> Well, we certainly can model invalid-physical-address and
> bus-timeout where that's what the board does for accesses
> to non-decoded addresses; but presumably in this case it
> doesn't...
>
> -- PMM
Is there anybody who has access to physical Malta hardware?
It would be interesting to see whether there is an exception
during the gcmp test or not.
With latest QEMU, the MIPS Malta system emulation starts
handling the exception caused by the gcmp test, but then
gets a second exception which is fatal (see below).
There might be something missing in our very simple bios
emulation.
=> If real hardware triggers an exception, then fixing the
bios emulation would be the correct way to handle this in
QEMU.
Stefan
[ 0.000000] CPU 0 Unable to handle kernel paging request at virtual
address 00000048, epc == 80100f74, ra == 80107f1c
[ 0.000000] Oops[#1]:
[ 0.000000] Cpu 0
[ 0.000000] $ 0 : 00000000 10000000 f8000000 00000000
[ 0.000000] $ 4 : 804edeb8 00000000 8051684c 00000000
[ 0.000000] $ 8 : 10000000 1000001f 8f5b0000 277b0001
[ 0.000000] $12 : af5b0000 80540000 00000000 42000018
[ 0.000000] $16 : 00000000 804edeb8 00000002 00000004
[ 0.000000] $20 : 00000000 00000000 00000000 80540000
[ 0.000000] $24 : 00000000 8010f7f0
[ 0.000000] $28 : 804ec000 804edd38 00000000 80107f1c
[ 0.000000] Hi : 00000000
[ 0.000000] Lo : 00000000
[ 0.000000] epc : 80100f74 malta_be_handler+0x4c/0x224 Not tainted
[ 0.000000] ra : 80107f1c do_be+0x11c/0x1ac
[ 0.000000] Status: 10000002 KERNEL EXL
[ 0.000000] Cause : 00800008
[ 0.000000] BadVA : 00000048
[ 0.000000] PrId : 00019000 (MIPS 4KEc)
[ 0.000000] Modules linked in:
[ 0.000000] Process swapper (pid: 0, threadinfo=804ec000,
task=804ee168, tls=00000000)
[ 0.000000] Stack : ffffffff 00000001 ffffffff 00000002 00000400
802ae1c0 804eded0 804edeee
[ 0.000000] ffffffff 804eded4 00000006 00000001 804edee8
804edf06 ffffffff 804edeec
[ 0.000000] 00000006 00000001 80500000 ffffffff 804edf08
804edf26 ffffffff 804edf0c
[ 0.000000] 00000006 00000001 80500000 ffffffff 7fb120e3
802ae1c0 802ae2a4 00000002
[ 0.000000] ffffffff 00000002 0000000a 00000006 ffffffff
00000001 00000775 00000775
[ 0.000000] ...
[ 0.000000] Call Trace:
[ 0.000000] [<80100f74>] malta_be_handler+0x4c/0x224
[ 0.000000] [<80107f1c>] do_be+0x11c/0x1ac
[ 0.000000] [<80101900>] ret_from_exception+0x0/0x24
[ 0.000000] [<8051684c>] gcmp_probe+0x38/0xa0
[ 0.000000] [<805168dc>] arch_init_irq+0x28/0x124
[ 0.000000] [<8050eb10>] start_kernel+0x1d4/0x400
[ 0.000000] [<80433cb0>] kernel_entry+0x0/0x90
next prev parent reply other threads:[~2013-08-05 5:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-27 16:18 [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory Hervé Poussineau
2013-07-27 16:49 ` Andreas Färber
2013-07-27 17:43 ` Peter Maydell
2013-07-27 19:37 ` Stefan Weil
2013-07-27 20:43 ` Andreas Färber
2013-07-27 20:57 ` Peter Maydell
2013-07-27 20:58 ` Stefan Weil
2013-07-29 20:35 ` Stefan Weil
2013-08-04 22:04 ` Aurélien Jarno
2013-08-04 22:37 ` Peter Maydell
2013-08-05 5:19 ` Stefan Weil [this message]
2013-08-05 12:27 ` Aurélien Jarno
2013-08-05 8:45 ` Andreas Färber
2013-08-05 8:47 ` Jan Kiszka
2013-08-05 13:31 ` Aurélien Jarno
2013-08-05 13:45 ` Andreas Färber
2013-08-05 13:53 ` Hervé Poussineau
2013-08-05 14:07 ` Aurélien Jarno
2013-08-05 14:15 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51FF35CC.4090700@weilnetz.de \
--to=sw@weilnetz.de \
--cc=afaerber@suse.de \
--cc=aurelien@aurel32.net \
--cc=hpoussin@reactos.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).