From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3BZB-0008QL-Jo for qemu-devel@nongnu.org; Sat, 27 Jul 2013 16:58:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3BZ5-0001Yw-Gm for qemu-devel@nongnu.org; Sat, 27 Jul 2013 16:58:17 -0400 Received: from smtp.mail.uni-mannheim.de ([134.155.96.80]:46451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3BZ5-0001Yr-9e for qemu-devel@nongnu.org; Sat, 27 Jul 2013 16:58:11 -0400 Message-ID: <51F4345D.6080007@weilnetz.de> Date: Sat, 27 Jul 2013 22:58:05 +0200 From: Stefan Weil MIME-Version: 1.0 References: <1374941897-11956-1-git-send-email-hpoussin@reactos.org> <51F4218A.1060802@weilnetz.de> <51F430F4.6020708@suse.de> In-Reply-To: <51F430F4.6020708@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: Peter Maydell , =?UTF-8?B?SGVydsOpIFBvdXNzaW5lYXU=?= , qemu-devel@nongnu.org Am 27.07.2013 22:43, schrieb Andreas F=C3=A4rber: > 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=C3=A9 Poussineau w= rote: >>>> Another solution would be to add a big dummy memory regions on all M= IPS boards >>>> to catch memory accesses and not raise an exception. However, this m= eans that >>>> each MIPS board will have its own unassigned memory handler, differe= nt 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 lis= t > of what memory ranges / devices we are talking about. > > The simplest for 1.6 might be to re-add an #ifndef TARGET_MIPS around > the refactored call to restore old behavior. > > Andreas Herv=C3=A9's patch or the big dummy memory region can be used to get the memory addresses in a certain test scenario from log messages. These addresses can then be added as "undefined devices" with a TODO comm= ent. I might send a fix for MIPS Malta which gets Linux working again, but maybe not before 1.6.1. Stefan