From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HIBtw-0002sl-7X for qemu-devel@nongnu.org; Fri, 16 Feb 2007 17:50:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HIBtu-0002s2-Lk for qemu-devel@nongnu.org; Fri, 16 Feb 2007 17:49:59 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HIBtu-0002rw-F9 for qemu-devel@nongnu.org; Fri, 16 Feb 2007 17:49:58 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by monty-python.gnu.org with esmtp (Exim 4.52) id 1HIBtt-0002U0-Q2 for qemu-devel@nongnu.org; Fri, 16 Feb 2007 17:49:58 -0500 Received: by ug-out-1314.google.com with SMTP id j40so281706ugd for ; Fri, 16 Feb 2007 14:49:57 -0800 (PST) Message-ID: From: "Peter Creath" Subject: Re: [Qemu-devel] Potential sparc32 MMU bug In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200702161701.59960.paul@codesourcery.com> <200702161825.28020.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 16 Feb 2007 22:50:00 -0000 To: Paul Brook Cc: qemu-devel@nongnu.org By banging on get_physical_address, I was able to confirm that qemu will properly assert an exception if the VM's MMU believes the page is read-only. How does env->mmuregs[] get mapped to the VM's MMU? I would normally write this off as an OpenBIOS bug, but it seems like bad behavior for an emulator to silently suppress all such access violations. At least there should be a way to turn the suppression off for debugging -- or at least a way for QEMU to log the suppressed error. Is there such a way that I've missed? On 2/16/07, Peter wrote: > Where is the policy of silently ignoring ROM writes implemented? It > may not be the proper behavior for sparc, and I'd like to tinker with > it. I'm just not sure where the write is getting suppressed (or, > alternatively, where the exception is getting suppressed). > > On 2/16/07, Paul Brook wrote: > > > > I don't know about sparc, but it's normal for writes to ROM to be > > > > ignored. However by my reading the sparc bios is loaded into RAM anyway, > > > > so it shouldn't matter. > > > > > > It definitely gets blocked by something: if I leave the the trap table > > > in the .text section, the write silently fails. If I move the trap > > > table to the .data section, the write succeeds. If I move the trap > > > table over to .rodata, the write fails again. What are you looking at > > > that suggests the whole sparc bios is loaded read/write? > > > > I was mistaken. There is a ROM area defined, it's just the elf loader doesn't > > care whether it's loading to rom or ram. > > > > My comment about rom writes being silently ignored still applies. > > > > Paul > > > > >