* [Qemu-devel] [PATCH][RFC] elf loader: use the virtual address
@ 2009-01-09 15:47 Aurelien Jarno
2009-01-09 15:57 ` Laurent Desnogues
0 siblings, 1 reply; 6+ messages in thread
From: Aurelien Jarno @ 2009-01-09 15:47 UTC (permalink / raw)
To: qemu-devel
Most Linux kernels have their physical address corresponding to they
virtual address in the ELF header. This is however not true anymore for
the PowerPC kernels (>= 2.6.25).
For PowerPC, the kernel needs to be started with address translation
enabled (that's even true for the firmware), and thus the kernel loaded
at the virtual address.
As all the other kernels/bios I have looked have the same virtual and
physical address, I don't think it will break other targets. This is
what is done in the patch below. Alternatively, we can add a new
argument to the load_elf functions, to select between virtual and
physical load address.
Any opinon?
diff --git a/elf_ops.h b/elf_ops.h
index feea12f..19d1a5e 100644
--- a/elf_ops.h
+++ b/elf_ops.h
@@ -231,7 +231,7 @@ static int glue(load_elf, SZ)(int fd, int64_t address_offset,
}
/* address_offset is hack for kernel images that are
linked at the wrong physical address. */
- addr = ph->p_paddr + address_offset;
+ addr = ph->p_vaddr + address_offset;
cpu_physical_memory_write_rom(addr, data, mem_size);
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH][RFC] elf loader: use the virtual address
2009-01-09 15:47 [Qemu-devel] [PATCH][RFC] elf loader: use the virtual address Aurelien Jarno
@ 2009-01-09 15:57 ` Laurent Desnogues
2009-01-09 16:24 ` Aurelien Jarno
0 siblings, 1 reply; 6+ messages in thread
From: Laurent Desnogues @ 2009-01-09 15:57 UTC (permalink / raw)
To: qemu-devel
On Fri, Jan 9, 2009 at 4:47 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> Most Linux kernels have their physical address corresponding to they
> virtual address in the ELF header. This is however not true anymore for
> the PowerPC kernels (>= 2.6.25).
>
> For PowerPC, the kernel needs to be started with address translation
> enabled (that's even true for the firmware), and thus the kernel loaded
> at the virtual address.
>
> As all the other kernels/bios I have looked have the same virtual and
> physical address, I don't think it will break other targets. This is
> what is done in the patch below. Alternatively, we can add a new
> argument to the load_elf functions, to select between virtual and
> physical load address.
>
> Any opinon?
I wonder if some platforms don't use the address_offset parameter
to simulate that behaviour.
Anyway wouldn't a parameter be cleaner and allow more flexibility?
Laurent
> diff --git a/elf_ops.h b/elf_ops.h
> index feea12f..19d1a5e 100644
> --- a/elf_ops.h
> +++ b/elf_ops.h
> @@ -231,7 +231,7 @@ static int glue(load_elf, SZ)(int fd, int64_t address_offset,
> }
> /* address_offset is hack for kernel images that are
> linked at the wrong physical address. */
> - addr = ph->p_paddr + address_offset;
> + addr = ph->p_vaddr + address_offset;
>
> cpu_physical_memory_write_rom(addr, data, mem_size);
>
> --
> .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
> : :' : Debian developer | Electrical Engineer
> `. `' aurel32@debian.org | aurelien@aurel32.net
> `- people.debian.org/~aurel32 | www.aurel32.net
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH][RFC] elf loader: use the virtual address
2009-01-09 15:57 ` Laurent Desnogues
@ 2009-01-09 16:24 ` Aurelien Jarno
2009-01-09 23:38 ` Paul Brook
0 siblings, 1 reply; 6+ messages in thread
From: Aurelien Jarno @ 2009-01-09 16:24 UTC (permalink / raw)
To: qemu-devel
Laurent Desnogues a écrit :
> On Fri, Jan 9, 2009 at 4:47 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> Most Linux kernels have their physical address corresponding to they
>> virtual address in the ELF header. This is however not true anymore for
>> the PowerPC kernels (>= 2.6.25).
>>
>> For PowerPC, the kernel needs to be started with address translation
>> enabled (that's even true for the firmware), and thus the kernel loaded
>> at the virtual address.
>>
>> As all the other kernels/bios I have looked have the same virtual and
>> physical address, I don't think it will break other targets. This is
>> what is done in the patch below. Alternatively, we can add a new
>> argument to the load_elf functions, to select between virtual and
>> physical load address.
>>
>> Any opinon?
>
> I wonder if some platforms don't use the address_offset parameter
> to simulate that behaviour.
PowerPC already does that. The offset is relative to the load address,
so it should still be read correctly.
> Anyway wouldn't a parameter be cleaner and allow more flexibility?
>
Maybe that's what I am going to implement.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH][RFC] elf loader: use the virtual address
2009-01-09 16:24 ` Aurelien Jarno
@ 2009-01-09 23:38 ` Paul Brook
2009-01-10 3:45 ` Edgar E. Iglesias
2009-01-10 18:35 ` Aurelien Jarno
0 siblings, 2 replies; 6+ messages in thread
From: Paul Brook @ 2009-01-09 23:38 UTC (permalink / raw)
To: qemu-devel; +Cc: Aurelien Jarno
> For PowerPC, the kernel needs to be started with address translation
> enabled (that's even true for the firmware), and thus the kernel loaded
> at the virtual address.
This sounds wrong.
Surely we should be loading it at the paddr with translation disabled, hat's
the whole point of having both paddr and vaddr in the ELF headers. If the ppc
kernel isn't setting p_paddr to the load address then what is it setting it
to?
> /* address_offset is hack for kernel images that are
> linked at the wrong physical address. */
> - addr = ph->p_paddr + address_offset;
> + addr = ph->p_vaddr + address_offset;
> As all the other kernels/bios I have looked have the same virtual and
> physical address, I don't think it will break other targets.
This will definitely break things. In particular bare metal applications built
for the Luminary Micro boards (and probably any other system that uses XIP
from flash). I also have several non-linux OS and bootloaders that rely on
the current elf loader behavior.
It's standard practice to use the paddr when loading an image. This si
consistent with gdb and several boot loaders.
See also http://lists.gnu.org/archive/html/qemu-devel/2008-10/msg00864.html
Paul
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH][RFC] elf loader: use the virtual address
2009-01-09 23:38 ` Paul Brook
@ 2009-01-10 3:45 ` Edgar E. Iglesias
2009-01-10 18:35 ` Aurelien Jarno
1 sibling, 0 replies; 6+ messages in thread
From: Edgar E. Iglesias @ 2009-01-10 3:45 UTC (permalink / raw)
To: qemu-devel; +Cc: Aurelien Jarno
On Fri, Jan 09, 2009 at 03:38:58PM -0800, Paul Brook wrote:
> > For PowerPC, the kernel needs to be started with address translation
> > enabled (that's even true for the firmware), and thus the kernel loaded
> > at the virtual address.
>
> This sounds wrong.
I agree. It sounds to me like if powerpc linux changed their linking
to produce elf files with correct physical addresses and that makes it hard
for qemu to support both the new and the old images.
Maybe ppc could use the low/highaddr arguments to find out if the kernel
objects really needs to use hte -0xc00000000 offset or no?
my guess is that older kernels need that offset but that the newer ones
dont.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH][RFC] elf loader: use the virtual address
2009-01-09 23:38 ` Paul Brook
2009-01-10 3:45 ` Edgar E. Iglesias
@ 2009-01-10 18:35 ` Aurelien Jarno
1 sibling, 0 replies; 6+ messages in thread
From: Aurelien Jarno @ 2009-01-10 18:35 UTC (permalink / raw)
To: qemu-devel
On Fri, Jan 09, 2009 at 03:38:58PM -0800, Paul Brook wrote:
> > For PowerPC, the kernel needs to be started with address translation
> > enabled (that's even true for the firmware), and thus the kernel loaded
> > at the virtual address.
>
> This sounds wrong.
>
> Surely we should be loading it at the paddr with translation disabled, hat's
> the whole point of having both paddr and vaddr in the ELF headers. If the ppc
> kernel isn't setting p_paddr to the load address then what is it setting it
> to?
It was set to the same value as the virtual address (0xc0000000), and it
is now set to 0x00000000.
> > /* address_offset is hack for kernel images that are
> > linked at the wrong physical address. */
> > - addr = ph->p_paddr + address_offset;
> > + addr = ph->p_vaddr + address_offset;
>
> > As all the other kernels/bios I have looked have the same virtual and
> > physical address, I don't think it will break other targets.
>
> This will definitely break things. In particular bare metal applications built
> for the Luminary Micro boards (and probably any other system that uses XIP
> from flash). I also have several non-linux OS and bootloaders that rely on
> the current elf loader behavior.
> It's standard practice to use the paddr when loading an image. This si
> consistent with gdb and several boot loaders.
>
If we want to mimic bootloaders, both quik and yaboot are using
p_vaddr.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-01-10 18:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-09 15:47 [Qemu-devel] [PATCH][RFC] elf loader: use the virtual address Aurelien Jarno
2009-01-09 15:57 ` Laurent Desnogues
2009-01-09 16:24 ` Aurelien Jarno
2009-01-09 23:38 ` Paul Brook
2009-01-10 3:45 ` Edgar E. Iglesias
2009-01-10 18:35 ` Aurelien Jarno
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).