From: Alexander Graf <agraf@suse.de>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
Thomas Huth <thuth@linux.vnet.ibm.com>,
qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC 0/2] s390x: Make the s390-ccw BIOS relocatable
Date: Thu, 05 Mar 2015 13:49:28 +0100 [thread overview]
Message-ID: <54F850D8.3030805@suse.de> (raw)
In-Reply-To: <54F84F70.8070006@de.ibm.com>
On 05.03.15 13:43, Christian Borntraeger wrote:
> Am 05.03.2015 um 12:10 schrieb Alexander Graf:
>>
>>
>> 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 :)
>
> Yes, looks good. It relocated much higher, but not beyond 2GB, and it can
> now handle guests < 128MB.
>
> I can take these patches via the s390 tree.
>
> Would be good if somebody else (Paolo,Alex ??)
> could Ack the change in include/hw/elf_ops.h.
Acked-by: Alexander Graf <agraf@suse.de>
Alex
prev parent reply other threads:[~2015-03-05 12:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-05 11:02 [Qemu-devel] [PATCH RFC 0/2] s390x: Make the s390-ccw BIOS relocatable Thomas Huth
2015-03-05 11:02 ` [Qemu-devel] [PATCH RFC 1/2] elf-loader: Provide the possibility to relocate s390 ELF files Thomas Huth
2015-03-05 11:02 ` [Qemu-devel] [PATCH RFC 2/2] s390/bios: Make the s390-ccw.img relocatable Thomas Huth
2015-03-05 11:10 ` [Qemu-devel] [PATCH RFC 0/2] s390x: Make the s390-ccw BIOS relocatable Alexander Graf
2015-03-05 12:43 ` Christian Borntraeger
2015-03-05 12:49 ` Alexander Graf [this message]
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=54F850D8.3030805@suse.de \
--to=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@linux.vnet.ibm.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).