Re: [Xen-devel] [PATCH v14 2/9] efi: build xen.gz with EFI code

2017-02-02 Thread Daniel Kiper
On Thu, Feb 02, 2017 at 04:46:14PM -0600, Doug Goldstein wrote:
> On 2/2/17 4:41 PM, Daniel Kiper wrote:
> > 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 
> >> Acked-by: Jan Beulich 
> >> Reviewed-by: Doug Goldstein 
> >> ---
> >> 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
> >
>
> FWIW, I had a similar fix for this cause I ran into it earlier today. I
> used runtime.o but I've switched to using boot.init.o so as to not
> conflict with you. This issue affects a lot more than this series so I'm

Great! Thanks a lot!

> going to mail mine once the tests finish at:
>
> https://travis-ci.org/cardoe/xen/builds/197819721

I am OK with it. If you wish you can add my
Reviewed-by: Daniel Kiper 
to this patch.

Daniel

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


Re: [Xen-devel] [PATCH v14 2/9] efi: build xen.gz with EFI code

2017-02-02 Thread Doug Goldstein
On 2/2/17 4:41 PM, Daniel Kiper wrote:
> 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 
>> Acked-by: Jan Beulich 
>> Reviewed-by: Doug Goldstein 
>> ---
>> 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
> 

FWIW, I had a similar fix for this cause I ran into it earlier today. I
used runtime.o but I've switched to using boot.init.o so as to not
conflict with you. This issue affects a lot more than this series so I'm
going to mail mine once the tests finish at:

https://travis-ci.org/cardoe/xen/builds/197819721

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v14 2/9] efi: build xen.gz with EFI code

2017-02-02 Thread Daniel Kiper
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 
> Acked-by: Jan Beulich 
> Reviewed-by: Doug Goldstein 
> ---
> 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


[Xen-devel] [PATCH v14 2/9] efi: build xen.gz with EFI code

2017-02-02 Thread Daniel Kiper
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 
Acked-by: Jan Beulich 
Reviewed-by: Doug Goldstein 
---
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).

v6 - suggestions/fixes:
   - improve efi_enabled() checks in efi_runtime_call()
 (suggested by Jan Beulich).

v5 - suggestions/fixes:
   - properly calculate efi symbol address in
 xen/arch/x86/xen.lds.S (I hope that this
 change does not invalidate Jan's ACK).

v4 - suggestions/fixes:
   - functions should return -ENOSYS instead
 of -EOPNOTSUPP if EFI runtime services
 are not available
 (suggested by Jan Beulich),
   - remove stale bits from xen/arch/x86/Makefile
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - check for EFI platform in EFI code
 (suggested by Jan Beulich),
   - fix Makefiles
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - build EFI code only if it is supported in a given build environment
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile |2 +-
 xen/arch/x86/efi/Makefile |   14 ++
 xen/arch/x86/xen.lds.S|4 ++--
 xen/common/efi/boot.c |3 +++
 xen/common/efi/runtime.c  |9 +
 5 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 007dced..08e9f7b 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -219,6 +219,6 @@ efi/mkreloc: efi/mkreloc.c
 clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
-   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi 
efi/disabled efi/mkreloc
+   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
rm -f note.o
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index ad3fdf7..3edff1c 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,18 +1,16 @@
 CFLAGS += -fshort-wchar
 
-obj-y += stub.o
-
-create = test -e $(1) || touch -t 19990101 $(1)
-
 efi := y$(shell rm -f disabled)
 efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
check.c 2>disabled && echo y))
 efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); 
$(call create,runtime.o)))
-
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o buildid.o
+efi := $(if $(efi),$(shell rm disabled)y)
 
 %.o: %.ihex
$(OBJCOPY) -I ihex -O binary $< $@
 
-stub.o: $(extra-y)
+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
 nogcov-$(efi) += stub.o
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 7676de9..b0b1c9b 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -270,10 +270,10 @@ SECTIONS
   .pad : {
 . = ALIGN(MB(16));
   } :text
-#else
-  efi = .;
 #endif
 
+  efi = DEFINED(efi) ? efi : .;
+
   /* Sections to be discarded */
   /DISCARD/ : {
*(.exit.text)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 3e5e4ab..df8c702 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -125