qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH 2/2] spapr: -kernel: allow linking with spec


From: Andrew Jones
Subject: Re: [Qemu-devel] [RFC PATCH 2/2] spapr: -kernel: allow linking with specified addr
Date: Tue, 21 Jul 2015 09:44:35 +0200
User-agent: Mutt/1.5.23.1 (2014-03-12)

On Tue, Jul 21, 2015 at 09:10:44AM +0200, Thomas Huth wrote:
> On 20/07/15 15:09, Andrew Jones wrote:
> > On Mon, Jul 20, 2015 at 08:47:53AM +0200, Thomas Huth wrote:
> ...
> >> ... or you could try to get the elf_reloc code working for POWER, too
> >> (see include/hw/elf_ops.h). That way QEMU would take care of relocating
> >> your program. (you can peek at elf_apply_rela64() in
> >>  https://github.com/aik/SLOF/blob/master/lib/libelf/elf64.c
> >> if you want to know what basically has to be done for POWER relocations).
> > 
> > kvm-unit-tests doesn't load the unit test elf itself. It relies on QEMU's
> > -kernel parameter to get the "kernel" (the unit test) into memory.
> 
> I was talking about the -kernel parameter of QEMU. That triggers the
> load_elf() function of QEMU - and this function can provide ELF
> relocation, too. It is used for s390x already to relocate the firmware
> there, so I think it could be done for ppc64, too.

Ah, I think I see what you mean now, extend QEMU's elf loader to do the
relocating. Then, when the relocatable kernel starts, it has already
been pre-relocated. That would certainly be do-able, but I think any
kernel that expects to be relocatable will already have it's own code,
and we'd end up doing the relocation twice. Kernels that want to avoid
relocation would typically depend on the linker load addresses (but the
problem here is that spapr has it's own opinion for those...)

I took a quick peek at what s390x does right now for its firmware. afaict
it's similar to what spapr is doing, just overriding the elf's LMA.

drew



reply via email to

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