Re: [PATCH v5 11/16] efi: build xen.gz with EFI code

From: "Jan Beulich" <JBeulich@suse.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: Juergen Gross <JGross@suse.com>,
	sstabellini@kernel.org, andrew.cooper3@citrix.com,
	cardoe@cardoe.com, pgnet.dev@gmail.com, ning.sun@intel.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	qiaowei.ren@intel.com, gang.wei@intel.com, fu.wei@linaro.org
Subject: Re: [PATCH v5 11/16] efi: build xen.gz with EFI code
Date: Thu, 25 Aug 2016 06:23:22 -0600	[thread overview]
Message-ID: <57BEFF5A0200007800109002@prv-mh.provo.novell.com> (raw)
In-Reply-To: <1471646606-28519-12-git-send-email-daniel.kiper@oracle.com>

>>> On 20.08.16 at 00:43, <daniel.kiper@oracle.com> 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>
> ---
> 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).

Looks okay. But there's one more thing:

> @@ -309,6 +312,9 @@ int efi_runtime_call(struct xenpf_efi_runtime_call *op)
>      EFI_STATUS status = EFI_NOT_STARTED;
>      int rc = 0;
>  
> +    if ( !efi_enabled(EFI_RS) )
> +        return -ENOSYS;

I think this should be two checks:

    if ( !efi_enabled(EFI_BOOT) )
        return -ENOSYS;
    if ( !efi_enabled(EFI_RS) )
        return -EOPNOTSUPP;

Jan

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