Re: [Xen-devel] [PATCH v2 10/23] efi: build xen.gz with EFI code

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Thu, Aug 20, 2015 at 09:39:39AM -0600, Jan Beulich wrote:
> >>> On 20.07.15 at 16:29, <daniel.kiper@xxxxxxxxxx> wrote:
> > Build xen.gz with EFI code. We need this to support multiboot2
> > protocol on EFI platforms.
> >
> > If we wish to load not ELF file using multiboot (v1) or multiboot2 then
>
> DYM "a non-ELF file"?
>
> > it must contain "linear" (or "flat") representation of code and data.
>
> Why? Please don't just put out statements, but also reasons (i.e.
> at least which component is unable to deal with the current [valid
> afaict] PE image we have).

This is a requirement of multiboot (v1) or multiboot2 protocol. They both
know nothing about PE image format.

> > 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). In theory there is a chance that we could build
> > proper PE file using current build system. However, it means that
>
> What is "improper" about the currently built PE file? And if there is
> anything improper, did you inform the binutils maintainers of the
> problem?

From PE loader point of view everything is OK. However, current Xen PE
image (at least build on my machines) is not usable by multiboot (v1)
or multiboot2 protocol compatible loader because it is not linear (one
section does not live immediately after another without any voids).
Potentially we can change that (probably by playing with linker script
or using objcopy or just simply building proper PE file ourselves; I did
some experiments once but they are not exhaustive and I am not able to
tell which solution will be the best in our case), however, this is next
step and it will be investigated after applying this patch series to
Xen source.

> > --- a/xen/arch/x86/efi/Makefile
> > +++ b/xen/arch/x86/efi/Makefile
> > @@ -1,14 +1,16 @@
> >  CFLAGS += -fshort-wchar
> >
> > -obj-y += stub.o
> > -
> > -create = test -e $(1) || touch -t 199901010000 $(1)
> > -
> >  efi := $(filter y,$(x86_64)$(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)))
> > +efi := $(if $(efi),$(shell rm disabled)y)
> >
> > -extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o
> > +extra-y += relocs-dummy.o
>
> Why is this no longer extra-$(efi)?

Because we need proper EFI code in xen.gz to support boot
via multiboot2 on EFI platforms.

> > -stub.o: $(extra-y)
>
> With this dependency removed (instead of perhaps replaced or
> extended) - what will trigger relocs-dummy.o to be (re)built?

It is triggered by prelink.o build rule in xen/arch/x86/Makefile.
Looks that it will suffice but I am not sure right now this is
good solution. Hmmm... If it is OK then we can remove
"extra-y += relocs-dummy.o".

Daniel

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