[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: |
Aurélien Jarno |
Subject: |
Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory |
Date: |
Mon, 5 Aug 2013 14:27:19 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, Aug 05, 2013 at 07:19:08AM +0200, Stefan Weil wrote:
> 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.
Booting YAMON in QEMU also shows the same behaviour, that is trying to
access to the 1fbf8008 address and getting a DBE exception, causing it
to fail. So it is clearly not due to our simple bios emulation, but
rather to the way the I/O are emulated.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
address@hidden http://www.aurel32.net