From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZH4rw-0003UF-RE for qemu-devel@nongnu.org; Mon, 20 Jul 2015 02:48:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZH4rt-0001iH-Lr for qemu-devel@nongnu.org; Mon, 20 Jul 2015 02:48:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37318) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZH4rt-0001hx-El for qemu-devel@nongnu.org; Mon, 20 Jul 2015 02:48:05 -0400 Message-ID: <55AC9999.9050506@redhat.com> Date: Mon, 20 Jul 2015 08:47:53 +0200 From: Thomas Huth MIME-Version: 1.0 References: <1437134200-13086-1-git-send-email-drjones@redhat.com> <1437134200-13086-3-git-send-email-drjones@redhat.com> <20150720050105.GF19189@voom.fritz.box> In-Reply-To: <20150720050105.GF19189@voom.fritz.box> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9GIkFVIHpNmSXUQ8VEKLKLbHTxjN2OGDt" Subject: Re: [Qemu-devel] [RFC PATCH 2/2] spapr: -kernel: allow linking with specified addr List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson , Andrew Jones Cc: dgibson@redhat.com, qemu-devel@nongnu.org, agraf@suse.de This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9GIkFVIHpNmSXUQ8VEKLKLbHTxjN2OGDt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 20/07/15 07:01, David Gibson wrote: > On Fri, Jul 17, 2015 at 01:56:40PM +0200, Andrew Jones wrote: >> I've started playing with adding ppc support to kvm-unit-tests, >> using spapr for the machine model. I wanted to link the unit test >> at 0x400000 to match qemu's load address, making the unit test >> startup code simpler, but ended up with 0x800000 instead, due to >> how translate_kernel_address works. The translation makes sense >> for how Linux kernels are linked (always at 0xc0000000 or >> 0xc000000000000000), but for the unit test case we need to avoid >> adding the offset. >> >> Signed-off-by: Andrew Jones >> --- >> Big RFC because I don't know if the "always at 0xc..." statement >> is 100% true for Linux, nor if this patch would break other stuff... >=20 > Yeah, I'm pretty dubious about this too, especially since I don't > entirely grasp what the load_elf() translation function is all about > anyway. Well, AFAIK it's used to modify the addresses before the ELF loader uses the address for loading. For example if your ELF binary is linked at address 0x1000, the translate function would move your binary to 0x401000 instead so that it does not interfere with the SLOF firmware (which is loaded to address 0 IIRC). So I also think your fix here is wrong, Andrew. E.g. when you have a binary that is linked to address 0x1000, you don't want to bypass the translation step here since it then would clash with the firmware. > That said, I suspect making your unit test assume a fixed load address > may not be the best idea - qemu or SLOF could change in future to move > things about, so it might be more robust to have your test copy itself > to address it wants to be at before executing. +1 =2E.. 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).= Thomas --9GIkFVIHpNmSXUQ8VEKLKLbHTxjN2OGDt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVrJmfAAoJEC7Z13T+cC21H0IQAJjoPjhrD0xeeDUmgvS1FFEd WmzwDfE+r8pXzdMSDPcp/stepUiWOw3mX+R9niAh4zyYKW1JNCp3JVJlXnt+fO1Q Gp2Vlg/fUzmGHaUOAb9mHlDu/88DxEZz3RzULfkb+t1zRHgXM0q/e1vJ1YIHA3h4 MNi9P3gkGd75gv+9tJSp2C+RmYx42JLCsPXmZ7D0EBpWZygDSg6NfRt0B3S0Tvqz mrFbYCf9vWdChzJanu80PNSlJu2pfw1g8j6Kzadk5Fiq4KM55/ugyiMMzdzAkUJm 59fJ7hpMO7jsuFjCOhQZ9zRa3kYwdc8f/5NR5JuS1qTcufFhqONw4k6IOogXIZEk Sh0Y029ogXTCk6JGgD7hIOcywgKYaycvZeS37Fk/USQaUGGSBg1r6onqFITwYQ6E bCdqs+8reIZz5DLLVTa0ukXReOdRPS2sFTn2MSh5e6i5xbb1XL4gqgNqcsc2qjLQ Lu0Ha/7rX7ZjYov7B8o2qeNNqHLGS0H1mcLW7zDGn4wU0QsZok2udmcUKTALfTnj 5LjFrAxEWghlrBCSYruhfJuu7laocqFqalk6bfVPl23UN0GhRSH6KuxBVvWs1viG G6rU3dUBu/Us/1Nfs4MavqO1C7WN7Jjw/2vtqa5k7GLnPVJJOcx5hOFz8fi3JJvz XzGo5+0rnnfikgtQdyKe =fBRZ -----END PGP SIGNATURE----- --9GIkFVIHpNmSXUQ8VEKLKLbHTxjN2OGDt--