qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: dgibson@redhat.com, agraf@suse.de, qemu-devel@nongnu.org,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [RFC PATCH 2/2] spapr: -kernel: allow linking with specified addr
Date: Tue, 21 Jul 2015 09:44:35 +0200	[thread overview]
Message-ID: <20150721074435.GC8797@hawk.localdomain> (raw)
In-Reply-To: <55ADF074.6000606@redhat.com>

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	other threads:[~2015-07-21  7:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-17 11:56 [Qemu-devel] [RFC PATCH 0/2] spapr: changes for kvm-unit-tests Andrew Jones
2015-07-17 11:56 ` [Qemu-devel] [RFC PATCH 1/2] spapr: add dumpdtb support Andrew Jones
2015-07-20  4:02   ` David Gibson
2015-07-20 13:20     ` Andrew Jones
2015-07-17 11:56 ` [Qemu-devel] [RFC PATCH 2/2] spapr: -kernel: allow linking with specified addr Andrew Jones
2015-07-20  5:01   ` David Gibson
2015-07-20  6:47     ` Thomas Huth
2015-07-20 13:09       ` Andrew Jones
2015-07-21  7:10         ` Thomas Huth
2015-07-21  7:44           ` Andrew Jones [this message]
2015-07-21  7:07   ` Andrew Jones
2015-07-20  4:32 ` [Qemu-devel] [RFC PATCH 0/2] spapr: changes for kvm-unit-tests David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150721074435.GC8797@hawk.localdomain \
    --to=drjones@redhat.com \
    --cc=agraf@suse.de \
    --cc=david@gibson.dropbear.id.au \
    --cc=dgibson@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).