From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1HI85p-0008NV-Ta
	for qemu-devel@nongnu.org; Fri, 16 Feb 2007 13:46:02 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1HI85n-0008MS-Qk
	for qemu-devel@nongnu.org; Fri, 16 Feb 2007 13:46:01 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1HI85n-0008MN-N7
	for qemu-devel@nongnu.org; Fri, 16 Feb 2007 13:45:59 -0500
Received: from nf-out-0910.google.com ([64.233.182.185])
	by monty-python.gnu.org with esmtp (Exim 4.52) id 1HI85n-0005lc-5l
	for qemu-devel@nongnu.org; Fri, 16 Feb 2007 13:45:59 -0500
Received: by nf-out-0910.google.com with SMTP id x30so1493903nfb
	for <qemu-devel@nongnu.org>; Fri, 16 Feb 2007 10:45:58 -0800 (PST)
Message-ID: <d40b362a0702161045i2494888ej8d2d2cfaae2940a8@mail.gmail.com>
Date: Fri, 16 Feb 2007 13:45:57 -0500
From: Peter <pjcreath+openbios@gmail.com>
Sender: pjcreath@gmail.com
Subject: Re: [Qemu-devel] Potential sparc32 MMU bug
In-Reply-To: <200702161825.28020.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <d40b362a0702160855u4613bc76l77cf962517358bac@mail.gmail.com>
	<200702161701.59960.paul@codesourcery.com>
	<d40b362a0702161017i7f1503a0x26f76a42db76eb14@mail.gmail.com>
	<200702161825.28020.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org

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 <paul@codesourcery.com> 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
>
>