qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RFC 0/2] s390x: Make the s390-ccw BIOS relocatab


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH RFC 0/2] s390x: Make the s390-ccw BIOS relocatable
Date: Thu, 05 Mar 2015 12:10:11 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0


On 05.03.15 12:02, Thomas Huth wrote:
> Currently, our s390-ccw.img sits at the fix address 126 MiB in memory.
> This has two big disadvantages: 1) We can not start guests with less
> than 128 MiB RAM and 2) if the guest uses a really huge ramdisk > 126 MiB,
> the s390-ccw BIOS gets overwritten and the boot silently crashes.
> 
> These two patches now fix these problems by relocating the s390-ccw
> BIOS to the end of the RAM. The basic idea here is to compile the
> BIOS with the "-fpie" compiler option to create position independent
> code. Sounds easy at a first glance - however, with -fpie, we only
> get position independent _code_ - and a so called GOT (global offset
> table) which contains absolute references to global variables again
> (this is normally needed for supporting dynamic libraries - in our
> s390-ccw BIOS, it's just bad luck that we get a GOT).
> 
> So to be able to really move around our s390-ccw.img in RAM, we've got
> to relocate the entries in the GOT, too. This is what the first patch
> is good for. I've changed the ELF loader there to parse the reloc section
> of the ELF file. I only included the bare minimum of relocation types
> (R_390_RELATIVE) in the patch so far, but this can easily be extended
> in case we need more (with different compiler version etc.).
> 
> The second patch then adds the required changes to the s390-ccw BIOS
> Makefile and our s390 ipl code in QEMU.
> 
> Now I'd like to get some feedback on this approach: Is it ok to extend
> the ELF loader this way? Does anybody have better/nicer ideas to solve
> the problem of a relocatable BIOS?
> 
> Thanks for any insights!

I think the approach is perfectly valid and good :)


Alex



reply via email to

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