On 27 July 2013 21:43, Andreas Färber <afaer...@suse.de> 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 <hpous...@reactos.org> 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
