xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: jgross@suse.com, grub-devel@gnu.org, eric.snowberg@oracle.com,
	arvidjaar@gmail.com, andrew.cooper3@citrix.com,
	stefano.stabellini@eu.citrix.com, cardoe@cardoe.com,
	pgnet.dev@gmail.com, roy.franz@linaro.org, ning.sun@intel.com,
	david.vrabel@citrix.com, jbeulich@suse.com, phcoder@gmail.com,
	xen-devel@lists.xenproject.org, qiaowei.ren@intel.com,
	richard.l.maliszewski@intel.com, gang.wei@intel.com,
	fu.wei@linaro.org, seth.goldberg@oracle.com
Subject: Re: [GRUB2 PATCH v5 4/4] multiboot2: Add support for relocatable images
Date: Fri, 25 Mar 2016 12:54:19 -0400	[thread overview]
Message-ID: <20160325165419.GB20741__4627.35107071257$1458924984$gmane$org@char.us.oracle.com> (raw)
In-Reply-To: <1458320427-4653-6-git-send-email-daniel.kiper@oracle.com>

On Fri, Mar 18, 2016 at 06:00:27PM +0100, Daniel Kiper wrote:
> Currently multiboot2 protocol loads image exactly at address specified in
> ELF or multiboot2 header. This solution works quite well on legacy BIOS
> platforms. It is possible because memory regions are placed at predictable
> addresses (though I was not able to find any spec which says that it is
> strong requirement, so, it looks that it is just a goodwill of hardware
> designers). However, EFI platforms are more volatile. Even if required
> memory regions live at specific addresses then they are sometimes simply
> not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
> OVMF). This means that you are not able to just set up final image
> destination on build time. You have to provide method to relocate image
> contents to real load address which is usually different than load address
> specified in ELF and multiboot2 headers.
> This patch provides all needed machinery to do self relocation in image code.
> First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
> align (required image alignment), preference (it says which memory regions are
> preferred by image, e.g. none, low, high) from multiboot_header_tag_relocatable
> header tag contained in binary (at this stage load addresses from multiboot2
> and/or ELF headers are ignored). Later loader tries to fulfill request (not only
> that one) and if it succeeds then it informs image about real load address via
> multiboot_tag_load_base_addr tag. At this stage GRUB2 role is finished. Starting
> from now executable must cope with relocations itself using whole static and
> dynamic knowledge provided by boot loader.
> This patch does not provide functionality which could do relocations using
> ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and Vladimir
> 'phcoder' Serbinenko to investigate that thing. It looks that relevant machinery
> could be added to existing code (including this patch) without huge effort.
> Additionally, ELF relocation could live in parallel with self relocation provided
> by this patch. However, during research I realized that first of all we should
> establish the details how ELF relocatable image should look like and how it should
> be build. At least to build proper test/example files.
> So, this patch just provides support for self relocatable images. If ELF file
> with relocs is loaded then GRUB2 complains loudly and ignores it. Support for
> such files will be added later.
> This patch was tested with Xen image which uses that functionality. However, this Xen
> feature is still under development and new patchset will be released in about 3-4 weeks.

> index e3a39b6..8a9ab0c 100644
> --- a/grub-core/loader/multiboot_elfxx.c
> +++ b/grub-core/loader/multiboot_elfxx.c

>  static grub_err_t
> -CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, const char *filename, void *buffer)
> +CONCAT(grub_multiboot_load_elf, XX) (mbi_load_data_t *mld)
>  {
> +  if (highest_load >= 0x100000000)
> +    return grub_error (GRUB_ERR_BAD_OS, "segment cross 4 GiB border");

segment crosses 4GiB border!

Xen-devel mailing list

      parent reply	other threads:[~2016-03-25 16:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1458320427-4653-1-git-send-email-daniel.kiper@oracle.com>
2016-03-18 17:00 ` [GRUB2 PATCH v5 1/4] i386/relocator: Add grub_relocator64_efi relocator Daniel Kiper
2016-03-25 16:28   ` Konrad Rzeszutek Wilk
     [not found]   ` <20160325162846.GA20741@char.us.oracle.com>
2016-03-25 20:43     ` Daniel Kiper
2016-03-18 17:00 ` [GRUB2 PATCH v5 2/4] multiboot2: Add tags used to pass ImageHandle to loaded image Daniel Kiper
2016-03-18 17:00 ` [GRUB2 PATCH v5 3/4 - FOR REVIEW ONLY] multiboot2: Do not pass memory maps to image if EFI boot services are enabled Daniel Kiper
2016-03-18 17:00 ` [GRUB2 PATCH v5 3/4 - FOR COMMIT] " Daniel Kiper
2016-03-18 17:00 ` [GRUB2 PATCH v5 4/4] multiboot2: Add support for relocatable images Daniel Kiper
     [not found] ` <1458320427-4653-6-git-send-email-daniel.kiper@oracle.com>
2016-03-25 16:54   ` Konrad Rzeszutek Wilk [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:

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

  git send-email \
    --in-reply-to='20160325165419.GB20741__4627.35107071257$1458924984$gmane$org@char.us.oracle.com' \
    --to=konrad.wilk@oracle.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=arvidjaar@gmail.com \
    --cc=cardoe@cardoe.com \
    --cc=daniel.kiper@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=eric.snowberg@oracle.com \
    --cc=fu.wei@linaro.org \
    --cc=gang.wei@intel.com \
    --cc=grub-devel@gnu.org \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=ning.sun@intel.com \
    --cc=pgnet.dev@gmail.com \
    --cc=phcoder@gmail.com \
    --cc=qiaowei.ren@intel.com \
    --cc=richard.l.maliszewski@intel.com \
    --cc=roy.franz@linaro.org \
    --cc=seth.goldberg@oracle.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xenproject.org \


* 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).