qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Mips target '-kernel' option bug


From: Jocelyn Mayer
Subject: Re: [Qemu-devel] Mips target '-kernel' option bug
Date: Wed, 17 Oct 2007 20:50:54 +0200

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 ?

[...]






reply via email to

[Prev in Thread] Current Thread [Next in Thread]