qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions wh


From: Stefan Weil
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
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7

Am 05.08.2013 00:37, schrieb Peter Maydell:
> On 4 August 2013 23:04, Aurélien Jarno <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]