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: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory
Date: Sat, 27 Jul 2013 21:57:29 +0100

On 27 July 2013 21:43, Andreas Färber <address@hidden> wrote:
> Am 27.07.2013 21:37, schrieb Stefan Weil:
>> Am 27.07.2013 19:43, schrieb Peter Maydell:
>>> On 27 July 2013 17:18, Hervé Poussineau <address@hidden> wrote:
>>>> Another solution would be to add a big dummy memory regions on all MIPS 
>>>> boards
>>>> to catch memory accesses and not raise an exception. However, this means 
>>>> that
>>>> each MIPS board will have its own unassigned memory handler, different 
>>>> from the
>>>> global QEMU one.
>>> Better would be to at least provide fake RAZ/WI implementations of
>>> devices for the boards, rather than making the dummy region cover
>>> the whole of the address space. Not 1.6 material, though.
>>
>> I prefer keeping the correct code for target-mips/op_helper.c
>> and adding either the big dummy memory regions or fake
>> device implementations (both with TODO comments) for 1.6.
>
> The problem I see with that is, so far no one has stepped up with a list
> of what memory ranges / devices we are talking about.

Yeah, that was what I meant with my comment about providing
fake devices being "not 1.6". Longer term if nobody
cares enough about the boards to dig up enough info to do this
then maybe we should drop the board models, but for 1.6 trying
to get that right for all the affected boards in the time we
have seems a bit risky.

> The simplest for 1.6 might be to re-add an #ifndef TARGET_MIPS around
> the refactored call to restore old behavior.

The advantage of adding single whole-space RAZ/WI regions
for each affected board is that then we can fix them up
one at a time to be more discriminating about how much
space they do this for. A single ifdef would certainly
be simpler though.

-- PMM



reply via email to

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