All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kiper <daniel.kiper@oracle.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com, sstabellini@kernel.org,
	andrew.cooper3@citrix.com, cardoe@cardoe.com,
	marcos.matsunaga@oracle.com, pgnet.dev@gmail.com,
	ning.sun@intel.com, julien.grall@arm.com, jbeulich@suse.com,
	qiaowei.ren@intel.com, gang.wei@intel.com, fu.wei@linaro.org
Subject: Re: [PATCH v14 2/9] efi: build xen.gz with EFI code
Date: Thu, 2 Feb 2017 23:41:53 +0100	[thread overview]
Message-ID: <20170202224153.GX16671@olila.local.net-space.pl> (raw)
In-Reply-To: <1486072879-31637-3-git-send-email-daniel.kiper@oracle.com>

On Thu, Feb 02, 2017 at 11:01:12PM +0100, Daniel Kiper wrote:
> Build xen.gz with EFI code. We need this to support multiboot2
> protocol on EFI platforms.
>
> If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
> it must contain "linear" (or "flat") representation of code and data.
> This is requirement of both boot protocols. Currently, PE file contains
> many sections which are not "linear" (one after another without any holes)
> or even do not have representation in a file (e.g. BSS). From EFI point
> of view everything is OK and works. However, this file layout cannot be
> properly interpreted by multiboot protocols family. In theory there is
> a chance that we could build proper PE file (from multiboot protocols POV)
> using current build system. However, it means that xen.efi further diverge
> from Xen ELF file (in terms of contents and build method). On the other
> hand ELF has all needed properties. So, it means that this is good starting
> point for further development. Additionally, I think that this is also good
> starting point for further xen.efi code and build optimizations. It looks
> that there is a chance that finally we can generate xen.efi directly from
> Xen ELF using just simple objcopy or other tool. This way we will have one
> Xen binary which can be loaded by three boot protocols: EFI native loader,
> multiboot (v1) and multiboot2.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
> ---
> v14 - suggestions/fixes:
>     - at least GNU Make 4.1 does not build efi/buildid.o if nothing
>       depends on it; so, add "boot.init.o: buildid.o" dependency to
>       force efi/buildid.o on some versions of make; I hope that this
>       small change does not invalidate Acked-by/Reviewed-by; however,
>       I am dropping Tested-by
>       (discovered by Konrad Rzeszutek Wilk and Marcos Matsunaga).

Diff as Doug asked:

diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 442f3fc..3edff1c 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -8,6 +8,8 @@ efi := $(if $(efi),$(shell rm disabled)y)
 %.o: %.ihex
 	$(OBJCOPY) -I ihex -O binary $< $@

+boot.init.o: buildid.o
+
 obj-y := stub.o
 obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
 extra-$(efi) += buildid.o

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-02-02 22:42 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-02 22:01 [PATCH v14 0/9] x86: multiboot2 protocol support Daniel Kiper
2017-02-02 22:01 ` [PATCH v14 1/9] x86: add " Daniel Kiper
2017-02-02 22:01 ` [PATCH v14 2/9] efi: build xen.gz with EFI code Daniel Kiper
2017-02-02 22:41   ` Daniel Kiper [this message]
2017-02-02 22:46     ` Doug Goldstein
2017-02-02 22:56       ` Daniel Kiper
2017-02-02 22:01 ` [PATCH v14 3/9] efi: create new early memory allocator Daniel Kiper
2017-02-02 22:01 ` [PATCH v14 4/9] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
2017-02-02 22:43   ` Daniel Kiper
2017-02-03 10:22     ` Jan Beulich
2017-02-06 10:18   ` Jan Beulich
2017-02-08 13:44     ` Daniel Kiper
2017-02-08 13:52       ` Jan Beulich
2017-02-02 22:01 ` [PATCH v14 5/9] x86: change default load address from 1 MiB to 2 MiB Daniel Kiper
2017-02-02 22:01 ` [PATCH v14 6/9] x86/setup: use XEN_IMG_OFFSET instead of Daniel Kiper
2017-02-02 22:01 ` [PATCH v14 7/9] x86: make Xen early boot code relocatable Daniel Kiper
2017-02-02 22:01 ` [PATCH v14 8/9] x86/boot: rename sym_phys() to sym_offs() Daniel Kiper
2017-02-02 22:01 ` [PATCH v14 9/9] x86: add multiboot2 protocol support for relocatable images Daniel Kiper
2017-02-02 22:27 ` [PATCH v14 0/9] x86: multiboot2 protocol support Doug Goldstein
2017-02-02 22:47   ` Daniel Kiper

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=20170202224153.GX16671@olila.local.net-space.pl \
    --to=daniel.kiper@oracle.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=cardoe@cardoe.com \
    --cc=fu.wei@linaro.org \
    --cc=gang.wei@intel.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=julien.grall@arm.com \
    --cc=marcos.matsunaga@oracle.com \
    --cc=ning.sun@intel.com \
    --cc=pgnet.dev@gmail.com \
    --cc=qiaowei.ren@intel.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.