From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1IiECO-0000hI-Jc
	for qemu-devel@nongnu.org; Wed, 17 Oct 2007 15:04:56 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1IiECM-0000cp-21
	for qemu-devel@nongnu.org; Wed, 17 Oct 2007 15:04:56 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1IiECL-0000cL-SR
	for qemu-devel@nongnu.org; Wed, 17 Oct 2007 15:04:53 -0400
Received: from relay01.mx.bawue.net ([193.7.176.67])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <ths@networkno.de>) id 1IiECL-0003VH-92
	for qemu-devel@nongnu.org; Wed, 17 Oct 2007 15:04:53 -0400
Date: Wed, 17 Oct 2007 20:04:26 +0100
From: Thiemo Seufer <ths@networkno.de>
Subject: Re: [Qemu-devel] Mips target '-kernel' option bug
Message-ID: <20071017190426.GA3379@networkno.de>
References: <1192568594.9976.523.camel@rapid>
	<20071017135148.GZ3379@networkno.de>
	<1192647054.32421.41.camel@jma4.dev.netgem.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1192647054.32421.41.camel@jma4.dev.netgem.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: Jocelyn Mayer <l_indien@magic.fr>
Cc: qemu-devel@nongnu.org

Jocelyn Mayer wrote:
> On Wed, 2007-10-17 at 14:51 +0100, Thiemo Seufer wrote:
> > J. Mayer wrote:
> > > I failed to run Mips target test image on my amd64 machine and I now
> > > found the reason of the bug:
> > > the kernel loader code used in hw/mips_r4k.c and hw/mips_malta.c
> > > implicitelly assumes that the ram_addr_t is 32 bits long.
> > > Unfortunatelly, on 64 bits hosts, this won't be the case and the kernel
> > > load address then is over 4 GB. Then, when computing the initrd_offset,
> > > the code always concludes that there's not enough RAM available to load
> > > it at the top of the kernel.
> > > I found 2 ways of fixing the bug, but I don't know which one is correct
> > > in Mips execution environment.
> > > The first patch is to make the VIRT_TO_PHYS_ADDEND negative, thus
> > > translating the kernel virtual address from 0x8000nnnn to the physical
> > > one 0x0000nnnn (instead of 0x10000nnnn, when running on 64 bits hosts).
> > > The second solution would be to explicitelly always cast the kernel_high
> > > value to 32 bits.
> > > As I do not really know if some Mips target specific constraints would
> > > make one of the other solution prefered, I'd better let the specialist
> > > choose !
> > > 
> > > The good news is that, once this issue is fixed, the Mips test images
> > > run with the reverse-endian softmmu patch applied.
> > 
> > I think this patch is the correct fix. Please test and comment.
> 
> Thanks, I'll test it at home tonight.
> To satisfy my curiosity, is there a specific reason to have a positive
> VIRT_TO_PHYS_ADDEND ?

So it wraps around correctly WRT the sign extension rules.


Thiemo