From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Ipn0q-0006Nt-MQ
	for qemu-devel@nongnu.org; Wed, 07 Nov 2007 10:40:16 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Ipn0n-0006ME-0d
	for qemu-devel@nongnu.org; Wed, 07 Nov 2007 10:40:16 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ipn0m-0006MB-Q3
	for qemu-devel@nongnu.org; Wed, 07 Nov 2007 10:40:12 -0500
Received: from wx-out-0506.google.com ([66.249.82.227])
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1Ipn0m-0001gT-7U
	for qemu-devel@nongnu.org; Wed, 07 Nov 2007 10:40:12 -0500
Received: by wx-out-0506.google.com with SMTP id h31so2487137wxd
	for <qemu-devel@nongnu.org>; Wed, 07 Nov 2007 07:40:11 -0800 (PST)
Message-ID: <f43fc5580711070740w3955b4f9o2fb7ca8d95d25951@mail.gmail.com>
Date: Wed, 7 Nov 2007 17:40:09 +0200
From: "Blue Swirl" <blauwirbel@gmail.com>
Subject: Re: [Qemu-devel] [PATCH] sparc32 boot mode flag fix
In-Reply-To: <200711062108.29729.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <472FD561.7020006@earthlink.net>
	<200711062039.12196.paul@codesourcery.com>
	<f43fc5580711061251l763d73bbl8380279557fd781f@mail.gmail.com>
	<200711062108.29729.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>, qemu-devel <qemu-devel@nongnu.org>

On 11/6/07, Paul Brook <paul@codesourcery.com> wrote:
> > > IIUC enabling/disabling boot mode is no different to and other VM change.
> > > If the virtual->physical mapping happens to be the same then it's
> > > perfectly ok to reuse the TB.
> >
> > Not in this case: in boot mode, physical and virtual address 0
> > generates TBs from PROM code.
>
> How is this different to using the MMU to map the PROM at virtual address
> zero?

In that case, the virtual address is zero, but physical address is
0xff0000000. Oh, now I see my error, it is the same in the boot mode
case too! Sorry about the noise.

> I see exactly one use of MMU_BM. It simply hard-wires a particular
> virtual->physical address mapping.

It derives from the Sparc specification, where the PC at reset is
zero. I wonder why they didn't put the start of memory somewhere
higher instead of this hack.

On Sparc64 the reset vector is implementation dependent so it can be
directly set to the PROM address.