Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

[Aurélien Jarno]

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