On Thu, Jan 21, 2021 at 04:51:43PM -0800, Bobby Eshleman wrote:
> From: Daniel Kiper <daniel.ki...@oracle.com>
> 
> In comparison to ELF the PE format is not supported by the Multiboot2
> protocol. So, if we wish to load xen.mb.efi using this protocol we have
> to add MULTIBOOT2_HEADER_TAG_ADDRESS and MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS
> tags into Multiboot2 header.
> 
> Additionally, put MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS and
> MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64 tags close to each
> other to make the header more readable.
> 
> The Multiboot2 protocol spec can be found at
>   https://www.gnu.org/software/grub/manual/multiboot2/
> 
> Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
> Signed-off-by: Bobby Eshleman <bobbyeshle...@gmail.com>
> ---
>  xen/arch/x86/boot/head.S | 19 +++++++++++++++----
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 189d91a872..f2edd182a5 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -94,6 +94,13 @@ multiboot2_header:
>          /* Align modules at page boundry. */
>          mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
>  
> +        /* The address tag. */
> +        mb2ht_init MB2_HT(ADDRESS), MB2_HT(REQUIRED), \
> +                   sym_offs(multiboot2_header), /* header_addr */ \
> +                   sym_offs(start),             /* load_addr */ \
> +                   sym_offs(__bss_start),       /* load_end_addr */ \
> +                   sym_offs(__2M_rwdata_end)    /* bss_end_addr */

Shouldn't this only be present when a PE binary is built?

You seem to unconditionally add this to the header, even when the
resulting binary will be in ELF format?

According to the spec: "This information does not need to be provided
if the kernel image is in ELF format", and hence Xen shouldn't require
the loader to understand this tag unless it's strictly required, as
the presence of the tag forces the bootloader to use the presented
information in order to load the kernel, regardless of the underlying
binary format.

Thanks, Roger.

Reply via email to