[PATCH 00/18] x86: multiboot2 protocol support

[PATCH 00/18] x86: multiboot2 protocol support

[Daniel Kiper]

Hi,

I am sending, long awaited, first version of multiboot2 protocol
support for legacy BIOS and EFI platforms.

The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
multiboot2 protocol. This way we will have:
  - smaller Xen code base,
  - one code base for xen.gz and xen.efi,
  - one build method for xen.gz and xen.efi;
    xen.efi will be extracted from xen file
    using objcopy; PE header will be contained
    in ELF file and will precede Xen code,
  - xen.efi build will not so strongly depend
    on a given GCC and binutils version.

GRUB2 patch series will follow this patch series.

GRUB2 guys should check patch #18 but I am sending
to you all Xen related patches just in case.

Daniel

 xen/arch/x86/Makefile             |   17 ++--
 xen/arch/x86/boot/Makefile        |    3 +-
 xen/arch/x86/boot/head.S          |  291 ++++++++++++++++++++++++++++++++++++++++++++++++++----
 xen/arch/x86/boot/reloc.c         |  219 ++++++++++++++++++++++++++++++++++-------
 xen/arch/x86/dmi_scan.c           |    4 +-
 xen/arch/x86/domain_page.c        |    2 +-
 xen/arch/x86/e820.c               |   29 ++----
 xen/arch/x86/efi/Makefile         |   12 +--
 xen/arch/x86/efi/efi-boot.h       |   66 +++++++++++--
 xen/arch/x86/efi/stub.c           |   41 --------
 xen/arch/x86/mpparse.c            |    4 +-
 xen/arch/x86/setup.c              |   30 +++---
 xen/arch/x86/shutdown.c           |    3 +-
 xen/arch/x86/time.c               |    2 +-
 xen/arch/x86/x86_64/asm-offsets.c |    8 ++
 xen/arch/x86/xen.lds.S            |    2 -
 xen/common/efi/boot.c             |  441 +++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------
 xen/common/efi/runtime.c          |   11 ++-
 xen/drivers/acpi/osl.c            |    2 +-
 xen/include/xen/efi.h             |    6 +-
 xen/include/xen/multiboot2.h      |  169 ++++++++++++++++++++++++++++++++
 21 files changed, 1018 insertions(+), 344 deletions(-)

Daniel Kiper (18):
      x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags
      x86/boot/reloc: create generic alloc and copy functions
      x86/boot: use %ecx instead of %eax
      xen/x86: add multiboot2 protocol support
      efi: split efi_enabled to efi_platform and efi_loader
      x86: remove commented out stale references to efi_enabled
      efi: run EFI specific code on EFI platform only
      efi: build xen.gz with EFI code
      efi: create efi_init()
      efi: create efi_console_set_mode()
      efi: create efi_get_gop()
      efi: create efi_find_gop_mode()
      efi: create efi_tables()
      efi: create efi_variables()
      efi: create efi_set_gop_mode()
      efi: create efi_exit_boot()
      x86/efi: create new early memory allocator
      x86: add multiboot2 protocol support for EFI platforms

[PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags

[Daniel Kiper]

..because it is ignored by Xen.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/arch/x86/boot/reloc.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index f971920..63045c0 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -90,7 +90,6 @@ multiboot_info_t *reloc(multiboot_info_t *mbi_old)
 
     /* Mask features we don't understand or don't relocate. */
     mbi->flags &= (MBI_MEMLIMITS |
-                   MBI_BOOTDEV |
                    MBI_CMDLINE |
                    MBI_MODULES |
                    MBI_MEMMAP |
-- 
1.7.10.4

Re: [Xen-devel] [PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags

[Andrew Cooper]

On 30/01/15 17:54, Daniel Kiper wrote:
> ..because it is ignored by Xen.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  xen/arch/x86/boot/reloc.c |    1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
> index f971920..63045c0 100644
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -90,7 +90,6 @@ multiboot_info_t *reloc(multiboot_info_t *mbi_old)
>  
>      /* Mask features we don't understand or don't relocate. */
>      mbi->flags &= (MBI_MEMLIMITS |
> -                   MBI_BOOTDEV |
>                     MBI_CMDLINE |
>                     MBI_MODULES |
>                     MBI_MEMMAP |

Re: [PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags

[Andrew Cooper]

On 30/01/15 17:54, Daniel Kiper wrote:
> ..because it is ignored by Xen.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  xen/arch/x86/boot/reloc.c |    1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
> index f971920..63045c0 100644
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -90,7 +90,6 @@ multiboot_info_t *reloc(multiboot_info_t *mbi_old)
>  
>      /* Mask features we don't understand or don't relocate. */
>      mbi->flags &= (MBI_MEMLIMITS |
> -                   MBI_BOOTDEV |
>                     MBI_CMDLINE |
>                     MBI_MODULES |
>                     MBI_MEMMAP |

[PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags

[Daniel Kiper]

..because it is ignored by Xen.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/arch/x86/boot/reloc.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index f971920..63045c0 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -90,7 +90,6 @@ multiboot_info_t *reloc(multiboot_info_t *mbi_old)
 
     /* Mask features we don't understand or don't relocate. */
     mbi->flags &= (MBI_MEMLIMITS |
-                   MBI_BOOTDEV |
                    MBI_CMDLINE |
                    MBI_MODULES |
                    MBI_MEMMAP |
-- 
1.7.10.4

[PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions

[Daniel Kiper]

Create generic alloc and copy functions. We need
separate tools for memory allocation and copy to
provide multiboot2 protocol support.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/arch/x86/boot/reloc.c |   52 ++++++++++++++++++++++++++++-----------------
 1 file changed, 33 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 63045c0..f964cda 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -33,9 +33,10 @@ asm (
 typedef unsigned int u32;
 #include "../../../include/xen/multiboot.h"
 
-static void *reloc_mbi_struct(void *old, unsigned int bytes)
+static u32 alloc_struct(u32 bytes)
 {
-    void *new;
+    u32 s;
+
     asm(
     "    call 1f                      \n"
     "1:  pop  %%edx                   \n"
@@ -43,50 +44,63 @@ static void *reloc_mbi_struct(void *old, unsigned int bytes)
     "    sub  %1,%0                   \n"
     "    and  $~15,%0                 \n"
     "    mov  %0,alloc-1b(%%edx)      \n"
-    "    mov  %0,%%edi                \n"
-    "    rep  movsb                   \n"
-       : "=&r" (new), "+c" (bytes), "+S" (old)
-	: : "edx", "edi", "memory");
-    return new;
+       : "=&r" (s) : "r" (bytes) : "edx", "memory");
+
+    return s;
+}
+
+static u32 copy_struct(u32 src, u32 bytes)
+{
+    u32 dst, dst_asm;
+
+    dst = alloc_struct(bytes);
+    dst_asm = dst;
+
+    asm volatile("rep movsb" : "+S" (src), "+D" (dst_asm), "+c" (bytes) : : "memory");
+
+    return dst;
 }
 
-static char *reloc_mbi_string(char *old)
+static u32 copy_string(u32 src)
 {
     char *p;
-    for ( p = old; *p != '\0'; p++ )
+
+    if ( src == 0 )
+        return 0;
+
+    for ( p = (char *)src; *p != '\0'; p++ )
         continue;
-    return reloc_mbi_struct(old, p - old + 1);
+
+    return copy_struct(src, p - (char *)src + 1);
 }
 
 multiboot_info_t *reloc(multiboot_info_t *mbi_old)
 {
-    multiboot_info_t *mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
+    multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, sizeof(*mbi));
     int i;
 
     if ( mbi->flags & MBI_CMDLINE )
-        mbi->cmdline = (u32)reloc_mbi_string((char *)mbi->cmdline);
+        mbi->cmdline = copy_string(mbi->cmdline);
 
     if ( mbi->flags & MBI_MODULES )
     {
-        module_t *mods = reloc_mbi_struct(
-            (module_t *)mbi->mods_addr, mbi->mods_count * sizeof(module_t));
+        module_t *mods = (module_t *)copy_struct(
+            mbi->mods_addr, mbi->mods_count * sizeof(module_t));
 
         mbi->mods_addr = (u32)mods;
 
         for ( i = 0; i < mbi->mods_count; i++ )
         {
             if ( mods[i].string )
-                mods[i].string = (u32)reloc_mbi_string((char *)mods[i].string);
+                mods[i].string = copy_string(mods[i].string);
         }
     }
 
     if ( mbi->flags & MBI_MEMMAP )
-        mbi->mmap_addr = (u32)reloc_mbi_struct(
-            (memory_map_t *)mbi->mmap_addr, mbi->mmap_length);
+        mbi->mmap_addr = copy_struct(mbi->mmap_addr, mbi->mmap_length);
 
     if ( mbi->flags & MBI_LOADERNAME )
-        mbi->boot_loader_name = (u32)reloc_mbi_string(
-            (char *)mbi->boot_loader_name);
+        mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
 
     /* Mask features we don't understand or don't relocate. */
     mbi->flags &= (MBI_MEMLIMITS |
-- 
1.7.10.4

Re: [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions

[Andrew Cooper]

On 30/01/15 17:54, Daniel Kiper wrote:
> Create generic alloc and copy functions. We need
> separate tools for memory allocation and copy to
> provide multiboot2 protocol support.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  xen/arch/x86/boot/reloc.c |   52 ++++++++++++++++++++++++++++-----------------
>  1 file changed, 33 insertions(+), 19 deletions(-)
>
> diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
> index 63045c0..f964cda 100644
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -33,9 +33,10 @@ asm (
>  typedef unsigned int u32;
>  #include "../../../include/xen/multiboot.h"
>  
> -static void *reloc_mbi_struct(void *old, unsigned int bytes)
> +static u32 alloc_struct(u32 bytes)
>  {
> -    void *new;
> +    u32 s;
> +
>      asm(
>      "    call 1f                      \n"
>      "1:  pop  %%edx                   \n"
> @@ -43,50 +44,63 @@ static void *reloc_mbi_struct(void *old, unsigned int bytes)
>      "    sub  %1,%0                   \n"
>      "    and  $~15,%0                 \n"
>      "    mov  %0,alloc-1b(%%edx)      \n"
> -    "    mov  %0,%%edi                \n"
> -    "    rep  movsb                   \n"
> -       : "=&r" (new), "+c" (bytes), "+S" (old)
> -	: : "edx", "edi", "memory");
> -    return new;
> +       : "=&r" (s) : "r" (bytes) : "edx", "memory");
> +
> +    return s;
> +}
> +
> +static u32 copy_struct(u32 src, u32 bytes)
> +{
> +    u32 dst, dst_asm;
> +
> +    dst = alloc_struct(bytes);
> +    dst_asm = dst;
> +
> +    asm volatile("rep movsb" : "+S" (src), "+D" (dst_asm), "+c" (bytes) : : "memory");
> +
> +    return dst;
>  }
>  
> -static char *reloc_mbi_string(char *old)
> +static u32 copy_string(u32 src)
>  {
>      char *p;
> -    for ( p = old; *p != '\0'; p++ )
> +
> +    if ( src == 0 )
> +        return 0;
> +
> +    for ( p = (char *)src; *p != '\0'; p++ )
>          continue;
> -    return reloc_mbi_struct(old, p - old + 1);
> +
> +    return copy_struct(src, p - (char *)src + 1);
>  }
>  
>  multiboot_info_t *reloc(multiboot_info_t *mbi_old)
>  {
> -    multiboot_info_t *mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
> +    multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, sizeof(*mbi));
>      int i;
>  
>      if ( mbi->flags & MBI_CMDLINE )
> -        mbi->cmdline = (u32)reloc_mbi_string((char *)mbi->cmdline);
> +        mbi->cmdline = copy_string(mbi->cmdline);
>  
>      if ( mbi->flags & MBI_MODULES )
>      {
> -        module_t *mods = reloc_mbi_struct(
> -            (module_t *)mbi->mods_addr, mbi->mods_count * sizeof(module_t));
> +        module_t *mods = (module_t *)copy_struct(
> +            mbi->mods_addr, mbi->mods_count * sizeof(module_t));
>  
>          mbi->mods_addr = (u32)mods;
>  
>          for ( i = 0; i < mbi->mods_count; i++ )
>          {
>              if ( mods[i].string )
> -                mods[i].string = (u32)reloc_mbi_string((char *)mods[i].string);
> +                mods[i].string = copy_string(mods[i].string);
>          }
>      }
>  
>      if ( mbi->flags & MBI_MEMMAP )
> -        mbi->mmap_addr = (u32)reloc_mbi_struct(
> -            (memory_map_t *)mbi->mmap_addr, mbi->mmap_length);
> +        mbi->mmap_addr = copy_struct(mbi->mmap_addr, mbi->mmap_length);
>  
>      if ( mbi->flags & MBI_LOADERNAME )
> -        mbi->boot_loader_name = (u32)reloc_mbi_string(
> -            (char *)mbi->boot_loader_name);
> +        mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
>  
>      /* Mask features we don't understand or don't relocate. */
>      mbi->flags &= (MBI_MEMLIMITS |

Re: [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions

[Andrew Cooper]

On 30/01/15 17:54, Daniel Kiper wrote:
> Create generic alloc and copy functions. We need
> separate tools for memory allocation and copy to
> provide multiboot2 protocol support.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  xen/arch/x86/boot/reloc.c |   52 ++++++++++++++++++++++++++++-----------------
>  1 file changed, 33 insertions(+), 19 deletions(-)
>
> diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
> index 63045c0..f964cda 100644
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -33,9 +33,10 @@ asm (
>  typedef unsigned int u32;
>  #include "../../../include/xen/multiboot.h"
>  
> -static void *reloc_mbi_struct(void *old, unsigned int bytes)
> +static u32 alloc_struct(u32 bytes)
>  {
> -    void *new;
> +    u32 s;
> +
>      asm(
>      "    call 1f                      \n"
>      "1:  pop  %%edx                   \n"
> @@ -43,50 +44,63 @@ static void *reloc_mbi_struct(void *old, unsigned int bytes)
>      "    sub  %1,%0                   \n"
>      "    and  $~15,%0                 \n"
>      "    mov  %0,alloc-1b(%%edx)      \n"
> -    "    mov  %0,%%edi                \n"
> -    "    rep  movsb                   \n"
> -       : "=&r" (new), "+c" (bytes), "+S" (old)
> -	: : "edx", "edi", "memory");
> -    return new;
> +       : "=&r" (s) : "r" (bytes) : "edx", "memory");
> +
> +    return s;
> +}
> +
> +static u32 copy_struct(u32 src, u32 bytes)
> +{
> +    u32 dst, dst_asm;
> +
> +    dst = alloc_struct(bytes);
> +    dst_asm = dst;
> +
> +    asm volatile("rep movsb" : "+S" (src), "+D" (dst_asm), "+c" (bytes) : : "memory");
> +
> +    return dst;
>  }
>  
> -static char *reloc_mbi_string(char *old)
> +static u32 copy_string(u32 src)
>  {
>      char *p;
> -    for ( p = old; *p != '\0'; p++ )
> +
> +    if ( src == 0 )
> +        return 0;
> +
> +    for ( p = (char *)src; *p != '\0'; p++ )
>          continue;
> -    return reloc_mbi_struct(old, p - old + 1);
> +
> +    return copy_struct(src, p - (char *)src + 1);
>  }
>  
>  multiboot_info_t *reloc(multiboot_info_t *mbi_old)
>  {
> -    multiboot_info_t *mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
> +    multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, sizeof(*mbi));
>      int i;
>  
>      if ( mbi->flags & MBI_CMDLINE )
> -        mbi->cmdline = (u32)reloc_mbi_string((char *)mbi->cmdline);
> +        mbi->cmdline = copy_string(mbi->cmdline);
>  
>      if ( mbi->flags & MBI_MODULES )
>      {
> -        module_t *mods = reloc_mbi_struct(
> -            (module_t *)mbi->mods_addr, mbi->mods_count * sizeof(module_t));
> +        module_t *mods = (module_t *)copy_struct(
> +            mbi->mods_addr, mbi->mods_count * sizeof(module_t));
>  
>          mbi->mods_addr = (u32)mods;
>  
>          for ( i = 0; i < mbi->mods_count; i++ )
>          {
>              if ( mods[i].string )
> -                mods[i].string = (u32)reloc_mbi_string((char *)mods[i].string);
> +                mods[i].string = copy_string(mods[i].string);
>          }
>      }
>  
>      if ( mbi->flags & MBI_MEMMAP )
> -        mbi->mmap_addr = (u32)reloc_mbi_struct(
> -            (memory_map_t *)mbi->mmap_addr, mbi->mmap_length);
> +        mbi->mmap_addr = copy_struct(mbi->mmap_addr, mbi->mmap_length);
>  
>      if ( mbi->flags & MBI_LOADERNAME )
> -        mbi->boot_loader_name = (u32)reloc_mbi_string(
> -            (char *)mbi->boot_loader_name);
> +        mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
>  
>      /* Mask features we don't understand or don't relocate. */
>      mbi->flags &= (MBI_MEMLIMITS |

Re: [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -33,9 +33,10 @@ asm (
>  typedef unsigned int u32;
>  #include "../../../include/xen/multiboot.h"
>  
> -static void *reloc_mbi_struct(void *old, unsigned int bytes)
> +static u32 alloc_struct(u32 bytes)

The generalization calls for the naming to change. Especially with the
use from copy_string(), both of the functions no longer deal with
struct-s alone. Please name them ..._block() or some other more
neutral way.

> +static u32 copy_string(u32 src)
>  {
>      char *p;
> -    for ( p = old; *p != '\0'; p++ )
> +
> +    if ( src == 0 )
> +        return 0;
> +
> +    for ( p = (char *)src; *p != '\0'; p++ )
>          continue;
> -    return reloc_mbi_struct(old, p - old + 1);
> +
> +    return copy_struct(src, p - (char *)src + 1);
>  }

As few casts as possible please: You can get away with one if you type
"p" u32.

>  multiboot_info_t *reloc(multiboot_info_t *mbi_old)
>  {
> -    multiboot_info_t *mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
> +    multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, sizeof(*mbi));

Please get rid of the cast on the first argument by converting
reloc()'s parameter type accordingly.

>      int i;
>  
>      if ( mbi->flags & MBI_CMDLINE )
> -        mbi->cmdline = (u32)reloc_mbi_string((char *)mbi->cmdline);
> +        mbi->cmdline = copy_string(mbi->cmdline);
>  
>      if ( mbi->flags & MBI_MODULES )
>      {
> -        module_t *mods = reloc_mbi_struct(
> -            (module_t *)mbi->mods_addr, mbi->mods_count * sizeof(module_t));
> +        module_t *mods = (module_t *)copy_struct(
> +            mbi->mods_addr, mbi->mods_count * sizeof(module_t));
>  
>          mbi->mods_addr = (u32)mods;

And again you can get away with one less cast if you store the
result of copy_struct() here and then assign "mods".

Jan

Re: [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -33,9 +33,10 @@ asm (
>  typedef unsigned int u32;
>  #include "../../../include/xen/multiboot.h"
>  
> -static void *reloc_mbi_struct(void *old, unsigned int bytes)
> +static u32 alloc_struct(u32 bytes)

The generalization calls for the naming to change. Especially with the
use from copy_string(), both of the functions no longer deal with
struct-s alone. Please name them ..._block() or some other more
neutral way.

> +static u32 copy_string(u32 src)
>  {
>      char *p;
> -    for ( p = old; *p != '\0'; p++ )
> +
> +    if ( src == 0 )
> +        return 0;
> +
> +    for ( p = (char *)src; *p != '\0'; p++ )
>          continue;
> -    return reloc_mbi_struct(old, p - old + 1);
> +
> +    return copy_struct(src, p - (char *)src + 1);
>  }

As few casts as possible please: You can get away with one if you type
"p" u32.

>  multiboot_info_t *reloc(multiboot_info_t *mbi_old)
>  {
> -    multiboot_info_t *mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
> +    multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, sizeof(*mbi));

Please get rid of the cast on the first argument by converting
reloc()'s parameter type accordingly.

>      int i;
>  
>      if ( mbi->flags & MBI_CMDLINE )
> -        mbi->cmdline = (u32)reloc_mbi_string((char *)mbi->cmdline);
> +        mbi->cmdline = copy_string(mbi->cmdline);
>  
>      if ( mbi->flags & MBI_MODULES )
>      {
> -        module_t *mods = reloc_mbi_struct(
> -            (module_t *)mbi->mods_addr, mbi->mods_count * sizeof(module_t));
> +        module_t *mods = (module_t *)copy_struct(
> +            mbi->mods_addr, mbi->mods_count * sizeof(module_t));
>  
>          mbi->mods_addr = (u32)mods;

And again you can get away with one less cast if you store the
result of copy_struct() here and then assign "mods".

Jan

[PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions

[Daniel Kiper]

Create generic alloc and copy functions. We need
separate tools for memory allocation and copy to
provide multiboot2 protocol support.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/arch/x86/boot/reloc.c |   52 ++++++++++++++++++++++++++++-----------------
 1 file changed, 33 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 63045c0..f964cda 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -33,9 +33,10 @@ asm (
 typedef unsigned int u32;
 #include "../../../include/xen/multiboot.h"
 
-static void *reloc_mbi_struct(void *old, unsigned int bytes)
+static u32 alloc_struct(u32 bytes)
 {
-    void *new;
+    u32 s;
+
     asm(
     "    call 1f                      \n"
     "1:  pop  %%edx                   \n"
@@ -43,50 +44,63 @@ static void *reloc_mbi_struct(void *old, unsigned int bytes)
     "    sub  %1,%0                   \n"
     "    and  $~15,%0                 \n"
     "    mov  %0,alloc-1b(%%edx)      \n"
-    "    mov  %0,%%edi                \n"
-    "    rep  movsb                   \n"
-       : "=&r" (new), "+c" (bytes), "+S" (old)
-	: : "edx", "edi", "memory");
-    return new;
+       : "=&r" (s) : "r" (bytes) : "edx", "memory");
+
+    return s;
+}
+
+static u32 copy_struct(u32 src, u32 bytes)
+{
+    u32 dst, dst_asm;
+
+    dst = alloc_struct(bytes);
+    dst_asm = dst;
+
+    asm volatile("rep movsb" : "+S" (src), "+D" (dst_asm), "+c" (bytes) : : "memory");
+
+    return dst;
 }
 
-static char *reloc_mbi_string(char *old)
+static u32 copy_string(u32 src)
 {
     char *p;
-    for ( p = old; *p != '\0'; p++ )
+
+    if ( src == 0 )
+        return 0;
+
+    for ( p = (char *)src; *p != '\0'; p++ )
         continue;
-    return reloc_mbi_struct(old, p - old + 1);
+
+    return copy_struct(src, p - (char *)src + 1);
 }
 
 multiboot_info_t *reloc(multiboot_info_t *mbi_old)
 {
-    multiboot_info_t *mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
+    multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, sizeof(*mbi));
     int i;
 
     if ( mbi->flags & MBI_CMDLINE )
-        mbi->cmdline = (u32)reloc_mbi_string((char *)mbi->cmdline);
+        mbi->cmdline = copy_string(mbi->cmdline);
 
     if ( mbi->flags & MBI_MODULES )
     {
-        module_t *mods = reloc_mbi_struct(
-            (module_t *)mbi->mods_addr, mbi->mods_count * sizeof(module_t));
+        module_t *mods = (module_t *)copy_struct(
+            mbi->mods_addr, mbi->mods_count * sizeof(module_t));
 
         mbi->mods_addr = (u32)mods;
 
         for ( i = 0; i < mbi->mods_count; i++ )
         {
             if ( mods[i].string )
-                mods[i].string = (u32)reloc_mbi_string((char *)mods[i].string);
+                mods[i].string = copy_string(mods[i].string);
         }
     }
 
     if ( mbi->flags & MBI_MEMMAP )
-        mbi->mmap_addr = (u32)reloc_mbi_struct(
-            (memory_map_t *)mbi->mmap_addr, mbi->mmap_length);
+        mbi->mmap_addr = copy_struct(mbi->mmap_addr, mbi->mmap_length);
 
     if ( mbi->flags & MBI_LOADERNAME )
-        mbi->boot_loader_name = (u32)reloc_mbi_string(
-            (char *)mbi->boot_loader_name);
+        mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
 
     /* Mask features we don't understand or don't relocate. */
     mbi->flags &= (MBI_MEMLIMITS |
-- 
1.7.10.4

[PATCH 03/18] x86/boot: use %ecx instead of %eax

[Daniel Kiper]

Use %ecx instead of %eax to store low memory upper limit from EBDA.
This way we do not wipe multiboot protocol identifier. It is needed
in reloc() to differentiate between multiboot (v1) and
multiboot2 protocol.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
 xen/arch/x86/boot/head.S |   27 ++++++++++++++-------------
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index c99f739..6180783 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -86,14 +86,14 @@ __start:
         jne     not_multiboot
 
         /* Set up trampoline segment 64k below EBDA */
-        movzwl  0x40e,%eax          /* EBDA segment */
-        cmp     $0xa000,%eax        /* sanity check (high) */
+        movzwl  0x40e,%ecx          /* EBDA segment */
+        cmp     $0xa000,%ecx        /* sanity check (high) */
         jae     0f
-        cmp     $0x4000,%eax        /* sanity check (low) */
+        cmp     $0x4000,%ecx        /* sanity check (low) */
         jae     1f
 0:
-        movzwl  0x413,%eax          /* use base memory size on failure */
-        shl     $10-4,%eax
+        movzwl  0x413,%ecx          /* use base memory size on failure */
+        shl     $10-4,%ecx
 1:
         /*
          * Compare the value in the BDA with the information from the
@@ -105,21 +105,22 @@ __start:
         cmp     $0x100,%edx         /* is the multiboot value too small? */
         jb      2f                  /* if so, do not use it */
         shl     $10-4,%edx
-        cmp     %eax,%edx           /* compare with BDA value */
-        cmovb   %edx,%eax           /* and use the smaller */
+        cmp     %ecx,%edx           /* compare with BDA value */
+        cmovb   %edx,%ecx           /* and use the smaller */
 
 2:      /* Reserve 64kb for the trampoline */
-        sub     $0x1000,%eax
+        sub     $0x1000,%ecx
 
         /* From arch/x86/smpboot.c: start_eip had better be page-aligned! */
-        xor     %al, %al
-        shl     $4, %eax
-        mov     %eax,sym_phys(trampoline_phys)
+        xor     %cl, %cl
+        shl     $4, %ecx
+        mov     %ecx,sym_phys(trampoline_phys)
 
         /* Save the Multiboot info struct (after relocation) for later use. */
         mov     $sym_phys(cpu0_stack)+1024,%esp
-        push    %ebx
-        call    reloc
+        mov     %ecx,%eax
+        push    %ebx                /* Multiboot information address */
+        call    reloc               /* %eax contains trampoline address */
         mov     %eax,sym_phys(multiboot_ptr)
 
         /* Initialize BSS (no nasty surprises!) */
-- 
1.7.10.4

Re: [PATCH 03/18] x86/boot: use %ecx instead of %eax

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>          /* Save the Multiboot info struct (after relocation) for later use. */
>          mov     $sym_phys(cpu0_stack)+1024,%esp
> -        push    %ebx
> -        call    reloc
> +        mov     %ecx,%eax
> +        push    %ebx                /* Multiboot information address */
> +        call    reloc               /* %eax contains trampoline address */

This last part looks completely unrelated to the change made here
(and contrary to the description, as here you clobber %eax while
the description says reloc() needs it unclobbered); afaict it belongs
in whatever patch add the consumption of this value in reloc().
That said - passing parameters to reloc() by two different means
looks very odd too. I'm clearly of the opinion that parameter
passing should follow an existing convention unless entirely
unfeasible. Which then raises the question whether this patch is
really needed: Rather than fiddling with a lot of code, can't you
just copy the incoming %eax into some other register, making this
a single line change that can again simply be done in the patch
where you actually consume the new information?

Jan

Re: [PATCH 03/18] x86/boot: use %ecx instead of %eax

[Daniel Kiper]

On Tue, Feb 03, 2015 at 10:02:09AM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >          /* Save the Multiboot info struct (after relocation) for later use. */
> >          mov     $sym_phys(cpu0_stack)+1024,%esp
> > -        push    %ebx
> > -        call    reloc
> > +        mov     %ecx,%eax
> > +        push    %ebx                /* Multiboot information address */
> > +        call    reloc               /* %eax contains trampoline address */
>
> This last part looks completely unrelated to the change made here
> (and contrary to the description, as here you clobber %eax while
> the description says reloc() needs it unclobbered); afaict it belongs
> in whatever patch add the consumption of this value in reloc().

Yep, this is confusing. I should change reloc.c:_start() in this patch too.

> That said - passing parameters to reloc() by two different means
> looks very odd too. I'm clearly of the opinion that parameter
> passing should follow an existing convention unless entirely
> unfeasible. Which then raises the question whether this patch is

So, I think that we should add another patch which fixes this issue
and put all arguments on the stack according to the cdecl calling
convention on x86.

> really needed: Rather than fiddling with a lot of code, can't you
> just copy the incoming %eax into some other register, making this
> a single line change that can again simply be done in the patch
> where you actually consume the new information?

If we do thing(s) mentioned above then this issue will disappear too.
Additionally, I think that we should not use another register if
it is not really required.

Daniel

Re: [PATCH 03/18] x86/boot: use %ecx instead of %eax

[Daniel Kiper]

On Tue, Feb 03, 2015 at 10:02:09AM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >          /* Save the Multiboot info struct (after relocation) for later use. */
> >          mov     $sym_phys(cpu0_stack)+1024,%esp
> > -        push    %ebx
> > -        call    reloc
> > +        mov     %ecx,%eax
> > +        push    %ebx                /* Multiboot information address */
> > +        call    reloc               /* %eax contains trampoline address */
>
> This last part looks completely unrelated to the change made here
> (and contrary to the description, as here you clobber %eax while
> the description says reloc() needs it unclobbered); afaict it belongs
> in whatever patch add the consumption of this value in reloc().

Yep, this is confusing. I should change reloc.c:_start() in this patch too.

> That said - passing parameters to reloc() by two different means
> looks very odd too. I'm clearly of the opinion that parameter
> passing should follow an existing convention unless entirely
> unfeasible. Which then raises the question whether this patch is

So, I think that we should add another patch which fixes this issue
and put all arguments on the stack according to the cdecl calling
convention on x86.

> really needed: Rather than fiddling with a lot of code, can't you
> just copy the incoming %eax into some other register, making this
> a single line change that can again simply be done in the patch
> where you actually consume the new information?

If we do thing(s) mentioned above then this issue will disappear too.
Additionally, I think that we should not use another register if
it is not really required.

Daniel

Re: [PATCH 03/18] x86/boot: use %ecx instead of %eax

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>          /* Save the Multiboot info struct (after relocation) for later use. */
>          mov     $sym_phys(cpu0_stack)+1024,%esp
> -        push    %ebx
> -        call    reloc
> +        mov     %ecx,%eax
> +        push    %ebx                /* Multiboot information address */
> +        call    reloc               /* %eax contains trampoline address */

This last part looks completely unrelated to the change made here
(and contrary to the description, as here you clobber %eax while
the description says reloc() needs it unclobbered); afaict it belongs
in whatever patch add the consumption of this value in reloc().
That said - passing parameters to reloc() by two different means
looks very odd too. I'm clearly of the opinion that parameter
passing should follow an existing convention unless entirely
unfeasible. Which then raises the question whether this patch is
really needed: Rather than fiddling with a lot of code, can't you
just copy the incoming %eax into some other register, making this
a single line change that can again simply be done in the patch
where you actually consume the new information?

Jan

[PATCH 03/18] x86/boot: use %ecx instead of %eax

[Daniel Kiper]

Use %ecx instead of %eax to store low memory upper limit from EBDA.
This way we do not wipe multiboot protocol identifier. It is needed
in reloc() to differentiate between multiboot (v1) and
multiboot2 protocol.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
 xen/arch/x86/boot/head.S |   27 ++++++++++++++-------------
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index c99f739..6180783 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -86,14 +86,14 @@ __start:
         jne     not_multiboot
 
         /* Set up trampoline segment 64k below EBDA */
-        movzwl  0x40e,%eax          /* EBDA segment */
-        cmp     $0xa000,%eax        /* sanity check (high) */
+        movzwl  0x40e,%ecx          /* EBDA segment */
+        cmp     $0xa000,%ecx        /* sanity check (high) */
         jae     0f
-        cmp     $0x4000,%eax        /* sanity check (low) */
+        cmp     $0x4000,%ecx        /* sanity check (low) */
         jae     1f
 0:
-        movzwl  0x413,%eax          /* use base memory size on failure */
-        shl     $10-4,%eax
+        movzwl  0x413,%ecx          /* use base memory size on failure */
+        shl     $10-4,%ecx
 1:
         /*
          * Compare the value in the BDA with the information from the
@@ -105,21 +105,22 @@ __start:
         cmp     $0x100,%edx         /* is the multiboot value too small? */
         jb      2f                  /* if so, do not use it */
         shl     $10-4,%edx
-        cmp     %eax,%edx           /* compare with BDA value */
-        cmovb   %edx,%eax           /* and use the smaller */
+        cmp     %ecx,%edx           /* compare with BDA value */
+        cmovb   %edx,%ecx           /* and use the smaller */
 
 2:      /* Reserve 64kb for the trampoline */
-        sub     $0x1000,%eax
+        sub     $0x1000,%ecx
 
         /* From arch/x86/smpboot.c: start_eip had better be page-aligned! */
-        xor     %al, %al
-        shl     $4, %eax
-        mov     %eax,sym_phys(trampoline_phys)
+        xor     %cl, %cl
+        shl     $4, %ecx
+        mov     %ecx,sym_phys(trampoline_phys)
 
         /* Save the Multiboot info struct (after relocation) for later use. */
         mov     $sym_phys(cpu0_stack)+1024,%esp
-        push    %ebx
-        call    reloc
+        mov     %ecx,%eax
+        push    %ebx                /* Multiboot information address */
+        call    reloc               /* %eax contains trampoline address */
         mov     %eax,sym_phys(multiboot_ptr)
 
         /* Initialize BSS (no nasty surprises!) */
-- 
1.7.10.4

[PATCH 04/18] xen/x86: add multiboot2 protocol support

[Daniel Kiper]

Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.

This way we are laying the foundation for EFI + GRUB2 + Xen development.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/arch/x86/boot/Makefile        |    3 +-
 xen/arch/x86/boot/head.S          |  104 ++++++++++++++++++++--
 xen/arch/x86/boot/reloc.c         |  174 ++++++++++++++++++++++++++++++++-----
 xen/arch/x86/x86_64/asm-offsets.c |    6 ++
 xen/include/xen/multiboot2.h      |  169 +++++++++++++++++++++++++++++++++++
 5 files changed, 429 insertions(+), 27 deletions(-)
 create mode 100644 xen/include/xen/multiboot2.h

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 5fdb5ae..0efa7d2 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,6 +1,7 @@
 obj-bin-y += head.o
 
-RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h
+RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/compiler.h \
+	     $(BASEDIR)/include/xen/multiboot.h $(BASEDIR)/include/xen/multiboot2.h
 
 head.o: reloc.S
 
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 6180783..7861057 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <xen/multiboot.h>
+#include <xen/multiboot2.h>
 #include <public/xen.h>
 #include <asm/asm_defns.h>
 #include <asm/desc.h>
@@ -32,6 +33,59 @@ ENTRY(start)
         .long   MULTIBOOT_HEADER_FLAGS
         /* Checksum: must be the negated sum of the first two fields. */
         .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
+ 
+/*** MULTIBOOT2 HEADER ****/
+/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S file. */
+        .align  MULTIBOOT2_HEADER_ALIGN
+
+.Lmultiboot2_header:
+        /* Magic number indicating a Multiboot2 header. */
+        .long   MULTIBOOT2_HEADER_MAGIC
+        /* Architecture: i386. */
+        .long   MULTIBOOT2_ARCHITECTURE_I386
+        /* Multiboot2 header length. */
+        .long   .Lmultiboot2_header_end - .Lmultiboot2_header
+        /* Multiboot2 header checksum. */
+        .long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
+                        (.Lmultiboot2_header_end - .Lmultiboot2_header))
+
+        /* Multiboot2 tags... */
+.Lmultiboot2_info_req:
+        /* Multiboot2 information request tag. */
+        .short  MULTIBOOT2_HEADER_TAG_INFORMATION_REQUEST
+        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
+        .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
+        .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
+        .long   MULTIBOOT2_TAG_TYPE_MMAP
+.Lmultiboot2_info_req_end:
+
+        .align  MULTIBOOT2_TAG_ALIGN
+        .short  MULTIBOOT2_HEADER_TAG_MODULE_ALIGN
+        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
+        .long   8 /* Tag size. */
+
+        /* Console flags tag. */
+        .align  MULTIBOOT2_TAG_ALIGN
+        .short  MULTIBOOT2_HEADER_TAG_CONSOLE_FLAGS
+        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
+        .long   12 /* Tag size. */
+        .long   MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
+
+        /* Framebuffer tag. */
+        .align  MULTIBOOT2_TAG_ALIGN
+        .short  MULTIBOOT2_HEADER_TAG_FRAMEBUFFER
+        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
+        .long   20 /* Tag size. */
+        .long   0 /* Number of the columns - no preference. */
+        .long   0 /* Number of the lines - no preference. */
+        .long   0 /* Number of bits per pixel - no preference. */
+
+        /* Multiboot2 header end tag. */
+        .align  MULTIBOOT2_TAG_ALIGN
+        .short  MULTIBOOT2_HEADER_TAG_END
+        .short  0
+        .long   8 /* Tag size. */
+.Lmultiboot2_header_end:
 
         .section .init.rodata, "a", @progbits
         .align 4
@@ -81,10 +135,51 @@ __start:
         mov     %ecx,%es
         mov     %ecx,%ss
 
+        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
+        xor     %edx,%edx
+
         /* Check for Multiboot bootloader */
         cmp     $MULTIBOOT_BOOTLOADER_MAGIC,%eax
-        jne     not_multiboot
+        je      multiboot1_proto
 
+        /* Check for Multiboot2 bootloader */
+        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
+        je      multiboot2_proto
+
+        jmp     not_multiboot
+
+multiboot1_proto:
+        /* Get mem_lower from Multiboot information */
+        testb   $MBI_MEMLIMITS,(%ebx)
+        jz      trampoline_setup    /* not available? BDA value will be fine */
+
+        mov     MB_mem_lower(%ebx),%edx
+        jmp     trampoline_setup
+
+multiboot2_proto:
+        /* Skip Multiboot2 information fixed part */
+        lea     MB2_fixed_sizeof(%ebx),%ecx
+
+0:
+        /* Get mem_lower from Multiboot2 information */
+        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
+        jne     1f
+
+        mov     MB2_mem_lower(%ecx),%edx
+        jmp     trampoline_setup
+
+1:
+        /* Is it the end of Multiboot2 information? */
+        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
+        je      trampoline_setup
+
+        /* Go to next Multiboot2 information tag */
+        add     MB2_tag_size(%ecx),%ecx
+        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
+        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
+        jmp     0b
+
+trampoline_setup:
         /* Set up trampoline segment 64k below EBDA */
         movzwl  0x40e,%ecx          /* EBDA segment */
         cmp     $0xa000,%ecx        /* sanity check (high) */
@@ -99,9 +194,6 @@ __start:
          * Compare the value in the BDA with the information from the
          * multiboot structure (if available) and use the smallest.
          */
-        testb   $MBI_MEMLIMITS,(%ebx)
-        jz      2f                  /* not available? BDA value will be fine */
-        mov     MB_mem_lower(%ebx),%edx
         cmp     $0x100,%edx         /* is the multiboot value too small? */
         jb      2f                  /* if so, do not use it */
         shl     $10-4,%edx
@@ -118,9 +210,9 @@ __start:
 
         /* Save the Multiboot info struct (after relocation) for later use. */
         mov     $sym_phys(cpu0_stack)+1024,%esp
-        mov     %ecx,%eax
+        push    %eax                /* Multiboot magic */
         push    %ebx                /* Multiboot information address */
-        call    reloc               /* %eax contains trampoline address */
+        call    reloc               /* %ecx contains trampoline address */
         mov     %eax,sym_phys(multiboot_ptr)
 
         /* Initialize BSS (no nasty surprises!) */
diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index f964cda..4b89838 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -5,19 +5,26 @@
  * and modules. This is most easily done early with paging disabled.
  *
  * Copyright (c) 2009, Citrix Systems, Inc.
+ * Copyright (c) 2013, 2014, 2015 Oracle Corp.
  *
  * Authors:
  *    Keir Fraser <keir@xen.org>
+ *    Daniel Kiper
  */
 
-/* entered with %eax = BOOT_TRAMPOLINE */
+/*
+ * This entry point is entered from xen/arch/x86/boot/head.S with:
+ *   - %eax = MULTIBOOT_MAGIC,
+ *   - %ebx = MULTIBOOT_INFORMATION_ADDRESS,
+ *   - %ecx = BOOT_TRAMPOLINE.
+ */
 asm (
     "    .text                         \n"
     "    .globl _start                 \n"
     "_start:                           \n"
     "    call 1f                       \n"
     "1:  pop  %ebx                     \n"
-    "    mov  %eax,alloc-1b(%ebx)      \n"
+    "    mov  %ecx,alloc-1b(%ebx)      \n"
     "    jmp  reloc                    \n"
     );
 
@@ -31,7 +38,16 @@ asm (
     );
 
 typedef unsigned int u32;
+typedef unsigned long long u64;
+
+#include "../../../include/xen/compiler.h"
 #include "../../../include/xen/multiboot.h"
+#include "../../../include/xen/multiboot2.h"
+
+#define ALIGN_UP(addr, align) \
+                (((addr) + (typeof(addr))(align) - 1) & ~((typeof(addr))(align) - 1))
+
+#define get_mb2_data(tag, type, member) (((type *)(tag))->member)
 
 static u32 alloc_struct(u32 bytes)
 {
@@ -49,6 +65,11 @@ static u32 alloc_struct(u32 bytes)
     return s;
 }
 
+static void zero_struct(u32 s, u32 bytes)
+{
+    asm volatile("rep stosb" : "+D" (s), "+c" (bytes) : "a" (0) : "memory");
+}
+
 static u32 copy_struct(u32 src, u32 bytes)
 {
     u32 dst, dst_asm;
@@ -74,40 +95,153 @@ static u32 copy_string(u32 src)
     return copy_struct(src, p - (char *)src + 1);
 }
 
-multiboot_info_t *reloc(multiboot_info_t *mbi_old)
+static multiboot_info_t *mbi_mbi(void *mbi_in)
 {
-    multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, sizeof(*mbi));
     int i;
+    multiboot_info_t *mbi_out;
 
-    if ( mbi->flags & MBI_CMDLINE )
-        mbi->cmdline = copy_string(mbi->cmdline);
+    mbi_out = (multiboot_info_t *)copy_struct((u32)mbi_in, sizeof(*mbi_out));
 
-    if ( mbi->flags & MBI_MODULES )
+    if ( mbi_out->flags & MBI_CMDLINE )
+        mbi_out->cmdline = copy_string(mbi_out->cmdline);
+
+    if ( mbi_out->flags & MBI_MODULES )
     {
         module_t *mods = (module_t *)copy_struct(
-            mbi->mods_addr, mbi->mods_count * sizeof(module_t));
+            mbi_out->mods_addr, mbi_out->mods_count * sizeof(module_t));
 
-        mbi->mods_addr = (u32)mods;
+        mbi_out->mods_addr = (u32)mods;
 
-        for ( i = 0; i < mbi->mods_count; i++ )
+        for ( i = 0; i < mbi_out->mods_count; i++ )
         {
             if ( mods[i].string )
                 mods[i].string = copy_string(mods[i].string);
         }
     }
 
-    if ( mbi->flags & MBI_MEMMAP )
-        mbi->mmap_addr = copy_struct(mbi->mmap_addr, mbi->mmap_length);
+    if ( mbi_out->flags & MBI_MEMMAP )
+        mbi_out->mmap_addr = copy_struct(mbi_out->mmap_addr, mbi_out->mmap_length);
 
-    if ( mbi->flags & MBI_LOADERNAME )
-        mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
+    if ( mbi_out->flags & MBI_LOADERNAME )
+        mbi_out->boot_loader_name = copy_string(mbi_out->boot_loader_name);
 
     /* Mask features we don't understand or don't relocate. */
-    mbi->flags &= (MBI_MEMLIMITS |
-                   MBI_CMDLINE |
-                   MBI_MODULES |
-                   MBI_MEMMAP |
-                   MBI_LOADERNAME);
+    mbi_out->flags &= (MBI_MEMLIMITS |
+                       MBI_CMDLINE |
+                       MBI_MODULES |
+                       MBI_MEMMAP |
+                       MBI_LOADERNAME);
 
-    return mbi;
+    return mbi_out;
+}
+
+static multiboot_info_t *mbi2_mbi(void *mbi_in)
+{
+    module_t *mbi_out_mods;
+    memory_map_t *mmap_dst;
+    multiboot2_memory_map_t *mmap_src;
+    multiboot2_tag_t *tag;
+    multiboot_info_t *mbi_out;
+    u32 ptr;
+    unsigned int i, mod_idx = 0;
+
+    mbi_out = (multiboot_info_t *)alloc_struct(sizeof(*mbi_out));
+    zero_struct((u32)mbi_out, sizeof(*mbi_out));
+
+    /* Skip Multiboot2 information fixed part. */
+    tag = mbi_in + sizeof(multiboot2_fixed_t);
+
+    for ( ; ; )
+    {
+        if ( tag->type == MULTIBOOT2_TAG_TYPE_MODULE )
+            ++mbi_out->mods_count;
+        else if ( tag->type == MULTIBOOT2_TAG_TYPE_END )
+        {
+            mbi_out->flags = MBI_MODULES;
+            mbi_out->mods_addr = alloc_struct(mbi_out->mods_count * sizeof(module_t));
+            mbi_out_mods = (module_t *)mbi_out->mods_addr;
+            break;
+        }
+
+        /* Go to next Multiboot2 information tag. */
+        tag = (multiboot2_tag_t *)(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN));
+    }
+
+    /* Skip Multiboot2 information fixed part. */
+    tag = mbi_in + sizeof(multiboot2_fixed_t);
+
+    for ( ; ; )
+    {
+        switch ( tag->type )
+        {
+        case MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME:
+            mbi_out->flags |= MBI_LOADERNAME;
+            ptr = (u32)get_mb2_data(tag, multiboot2_tag_string_t, string);
+            mbi_out->boot_loader_name = copy_string(ptr);
+            break;
+
+        case MULTIBOOT2_TAG_TYPE_CMDLINE:
+            mbi_out->flags |= MBI_CMDLINE;
+            ptr = (u32)get_mb2_data(tag, multiboot2_tag_string_t, string);
+            mbi_out->cmdline = copy_string(ptr);
+            break;
+
+        case MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO:
+            mbi_out->flags |= MBI_MEMLIMITS;
+            mbi_out->mem_lower = get_mb2_data(tag, multiboot2_tag_basic_meminfo_t, mem_lower);
+            mbi_out->mem_upper = get_mb2_data(tag, multiboot2_tag_basic_meminfo_t, mem_upper);
+            break;
+
+        case MULTIBOOT2_TAG_TYPE_MMAP:
+            mbi_out->flags |= MBI_MEMMAP;
+            mbi_out->mmap_length = get_mb2_data(tag, multiboot2_tag_mmap_t, size);
+            mbi_out->mmap_length -= sizeof(multiboot2_tag_mmap_t);
+            mbi_out->mmap_length += sizeof(((multiboot2_tag_mmap_t){0}).entries);
+            mbi_out->mmap_length /= get_mb2_data(tag, multiboot2_tag_mmap_t, entry_size);
+            mbi_out->mmap_length *= sizeof(memory_map_t);
+
+            mbi_out->mmap_addr = alloc_struct(mbi_out->mmap_length);
+
+            mmap_src = get_mb2_data(tag, multiboot2_tag_mmap_t, entries);
+            mmap_dst = (memory_map_t *)mbi_out->mmap_addr;
+
+            for ( i = 0; i < mbi_out->mmap_length / sizeof(memory_map_t); ++i )
+            {
+                mmap_dst[i].size = sizeof(memory_map_t);
+                mmap_dst[i].size -= sizeof(((memory_map_t){0}).size);
+                mmap_dst[i].base_addr_low = (u32)mmap_src[i].addr;
+                mmap_dst[i].base_addr_high = (u32)(mmap_src[i].addr >> 32);
+                mmap_dst[i].length_low = (u32)mmap_src[i].len;
+                mmap_dst[i].length_high = (u32)(mmap_src[i].len >> 32);
+                mmap_dst[i].type = mmap_src[i].type;
+            }
+            break;
+
+        case MULTIBOOT2_TAG_TYPE_MODULE:
+            mbi_out_mods[mod_idx].mod_start = get_mb2_data(tag, multiboot2_tag_module_t, mod_start);
+            mbi_out_mods[mod_idx].mod_end = get_mb2_data(tag, multiboot2_tag_module_t, mod_end);
+            ptr = (u32)get_mb2_data(tag, multiboot2_tag_module_t, cmdline);
+            mbi_out_mods[mod_idx].string = copy_string(ptr);
+            mbi_out_mods[mod_idx].reserved = 0;
+            ++mod_idx;
+            break;
+
+        case MULTIBOOT2_TAG_TYPE_END:
+            return mbi_out;
+
+        default:
+            break;
+        }
+
+        /* Go to next Multiboot2 information tag. */
+        tag = (multiboot2_tag_t *)(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN));
+    }
+}
+
+static multiboot_info_t __used *reloc(void *mbi_in, u32 mb_magic)
+{
+    if ( mb_magic == MULTIBOOT2_BOOTLOADER_MAGIC )
+        return mbi2_mbi(mbi_in);
+    else
+        return mbi_mbi(mbi_in);
 }
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index 447c650..ca3712f 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -13,6 +13,7 @@
 #include <asm/fixmap.h>
 #include <asm/hardirq.h>
 #include <xen/multiboot.h>
+#include <xen/multiboot2.h>
 
 #define DEFINE(_sym, _val)                                                 \
     asm volatile ("\n.ascii\"==>#define " #_sym " %0 /* " #_val " */<==\"" \
@@ -166,4 +167,9 @@ void __dummy__(void)
     OFFSET(MB_flags, multiboot_info_t, flags);
     OFFSET(MB_cmdline, multiboot_info_t, cmdline);
     OFFSET(MB_mem_lower, multiboot_info_t, mem_lower);
+    BLANK();
+
+    DEFINE(MB2_fixed_sizeof, sizeof(multiboot2_fixed_t));
+    OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+    OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
 }
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
new file mode 100644
index 0000000..09ee64e
--- /dev/null
+++ b/xen/include/xen/multiboot2.h
@@ -0,0 +1,169 @@
+/*
+ *  Copyright (C) 1999,2003,2007,2008,2009,2010  Free Software Foundation, Inc.
+ *
+ *  multiboot2.h - Multiboot 2 header file.
+ *
+ *  Based on grub-2.00/include/multiboot2.h file.
+ *
+ *  Permission is hereby granted, free of charge, to any person obtaining a copy
+ *  of this software and associated documentation files (the "Software"), to
+ *  deal in the Software without restriction, including without limitation the
+ *  rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ *  sell copies of the Software, and to permit persons to whom the Software is
+ *  furnished to do so, subject to the following conditions:
+ *
+ *  The above copyright notice and this permission notice shall be included in
+ *  all copies or substantial portions of the Software.
+ *
+ *  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ *  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ *  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL ANY
+ *  DEVELOPER OR DISTRIBUTOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *  WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR
+ *  IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __MULTIBOOT2_H__
+#define __MULTIBOOT2_H__
+
+/* The magic field should contain this.  */
+#define MULTIBOOT2_HEADER_MAGIC			0xe85250d6
+
+/* This should be in %eax on x86 architecture.  */
+#define MULTIBOOT2_BOOTLOADER_MAGIC		0x36d76289
+
+/* How many bytes from the start of the file we search for the header.  */
+#define MULTIBOOT2_SEARCH			32768
+
+/* Multiboot 2 header alignment. */
+#define MULTIBOOT2_HEADER_ALIGN			8
+
+/* Alignment of multiboot 2 modules.  */
+#define MULTIBOOT2_MOD_ALIGN			0x00001000
+
+/* Alignment of the multiboot 2 info structure.  */
+#define MULTIBOOT2_INFO_ALIGN			0x00000008
+
+/* Multiboot 2 architectures. */
+#define MULTIBOOT2_ARCHITECTURE_I386	0
+#define MULTIBOOT2_ARCHITECTURE_MIPS32	4
+
+/* Header tag types. */
+#define MULTIBOOT2_HEADER_TAG_END			0
+#define MULTIBOOT2_HEADER_TAG_INFORMATION_REQUEST	1
+#define MULTIBOOT2_HEADER_TAG_ADDRESS			2
+#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS		3
+#define MULTIBOOT2_HEADER_TAG_CONSOLE_FLAGS		4
+#define MULTIBOOT2_HEADER_TAG_FRAMEBUFFER		5
+#define MULTIBOOT2_HEADER_TAG_MODULE_ALIGN		6
+#define MULTIBOOT2_HEADER_TAG_EFI_BS			7
+#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32	8
+#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64	9
+
+/* Header tag flags. */
+#define MULTIBOOT2_HEADER_TAG_REQUIRED	0
+#define MULTIBOOT2_HEADER_TAG_OPTIONAL	1
+
+/* Header console tag console_flags. */
+#define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED	1
+#define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED	2
+
+/* Flags set in the 'flags' member of the multiboot header.  */
+#define MULTIBOOT2_TAG_TYPE_END			0
+#define MULTIBOOT2_TAG_TYPE_CMDLINE		1
+#define MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME	2
+#define MULTIBOOT2_TAG_TYPE_MODULE		3
+#define MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO	4
+#define MULTIBOOT2_TAG_TYPE_BOOTDEV		5
+#define MULTIBOOT2_TAG_TYPE_MMAP		6
+#define MULTIBOOT2_TAG_TYPE_VBE			7
+#define MULTIBOOT2_TAG_TYPE_FRAMEBUFFER		8
+#define MULTIBOOT2_TAG_TYPE_ELF_SECTIONS	9
+#define MULTIBOOT2_TAG_TYPE_APM			10
+#define MULTIBOOT2_TAG_TYPE_EFI32		11
+#define MULTIBOOT2_TAG_TYPE_EFI64		12
+#define MULTIBOOT2_TAG_TYPE_SMBIOS		13
+#define MULTIBOOT2_TAG_TYPE_ACPI_OLD		14
+#define MULTIBOOT2_TAG_TYPE_ACPI_NEW		15
+#define MULTIBOOT2_TAG_TYPE_NETWORK		16
+#define MULTIBOOT2_TAG_TYPE_EFI_MMAP		17
+#define MULTIBOOT2_TAG_TYPE_EFI_BS		18
+#define MULTIBOOT2_TAG_TYPE_EFI32_IH		19
+#define MULTIBOOT2_TAG_TYPE_EFI64_IH		20
+
+/* Multiboot 2 tag alignment. */
+#define MULTIBOOT2_TAG_ALIGN			8
+
+/* Memory types. */
+#define MULTIBOOT2_MEMORY_AVAILABLE		1
+#define MULTIBOOT2_MEMORY_RESERVED		2
+#define MULTIBOOT2_MEMORY_ACPI_RECLAIMABLE	3
+#define MULTIBOOT2_MEMORY_NVS			4
+#define MULTIBOOT2_MEMORY_BADRAM		5
+
+/* Framebuffer types. */
+#define MULTIBOOT2_FRAMEBUFFER_TYPE_INDEXED	0
+#define MULTIBOOT2_FRAMEBUFFER_TYPE_RGB		1
+#define MULTIBOOT2_FRAMEBUFFER_TYPE_EGA_TEXT	2
+
+#ifndef __ASSEMBLY__
+typedef struct {
+    u32 total_size;
+    u32 reserved;
+} multiboot2_fixed_t;
+
+typedef struct {
+    u32 type;
+    u32 size;
+} multiboot2_tag_t;
+
+typedef struct {
+    u32 type;
+    u32 size;
+    char string[0];
+} multiboot2_tag_string_t;
+
+typedef struct {
+    u32 type;
+    u32 size;
+    u32 mem_lower;
+    u32 mem_upper;
+} multiboot2_tag_basic_meminfo_t;
+
+typedef struct __packed {
+    u64 addr;
+    u64 len;
+    u32 type;
+    u32 zero;
+} multiboot2_memory_map_t;
+
+typedef struct {
+    u32 type;
+    u32 size;
+    u32 entry_size;
+    u32 entry_version;
+    multiboot2_memory_map_t entries[0];
+} multiboot2_tag_mmap_t;
+
+typedef struct {
+    u32 type;
+    u32 size;
+    u64 pointer;
+} multiboot2_tag_efi64_t;
+
+typedef struct {
+    u32 type;
+    u32 size;
+    u64 pointer;
+} multiboot2_tag_efi64_ih_t;
+
+typedef struct {
+    u32 type;
+    u32 size;
+    u32 mod_start;
+    u32 mod_end;
+    char cmdline[0];
+} multiboot2_tag_module_t;
+#endif /* __ASSEMBLY__ */
+
+#endif /* __MULTIBOOT2_H__ */
-- 
1.7.10.4

[PATCH 04/18] xen/x86: add multiboot2 protocol support

[Daniel Kiper]

Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.

This way we are laying the foundation for EFI + GRUB2 + Xen development.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/arch/x86/boot/Makefile        |    3 +-
 xen/arch/x86/boot/head.S          |  104 ++++++++++++++++++++--
 xen/arch/x86/boot/reloc.c         |  174 ++++++++++++++++++++++++++++++++-----
 xen/arch/x86/x86_64/asm-offsets.c |    6 ++
 xen/include/xen/multiboot2.h      |  169 +++++++++++++++++++++++++++++++++++
 5 files changed, 429 insertions(+), 27 deletions(-)
 create mode 100644 xen/include/xen/multiboot2.h

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 5fdb5ae..0efa7d2 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,6 +1,7 @@
 obj-bin-y += head.o
 
-RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h
+RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/compiler.h \
+	     $(BASEDIR)/include/xen/multiboot.h $(BASEDIR)/include/xen/multiboot2.h
 
 head.o: reloc.S
 
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 6180783..7861057 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -1,5 +1,6 @@
 #include <xen/config.h>
 #include <xen/multiboot.h>
+#include <xen/multiboot2.h>
 #include <public/xen.h>
 #include <asm/asm_defns.h>
 #include <asm/desc.h>
@@ -32,6 +33,59 @@ ENTRY(start)
         .long   MULTIBOOT_HEADER_FLAGS
         /* Checksum: must be the negated sum of the first two fields. */
         .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
+ 
+/*** MULTIBOOT2 HEADER ****/
+/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S file. */
+        .align  MULTIBOOT2_HEADER_ALIGN
+
+.Lmultiboot2_header:
+        /* Magic number indicating a Multiboot2 header. */
+        .long   MULTIBOOT2_HEADER_MAGIC
+        /* Architecture: i386. */
+        .long   MULTIBOOT2_ARCHITECTURE_I386
+        /* Multiboot2 header length. */
+        .long   .Lmultiboot2_header_end - .Lmultiboot2_header
+        /* Multiboot2 header checksum. */
+        .long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
+                        (.Lmultiboot2_header_end - .Lmultiboot2_header))
+
+        /* Multiboot2 tags... */
+.Lmultiboot2_info_req:
+        /* Multiboot2 information request tag. */
+        .short  MULTIBOOT2_HEADER_TAG_INFORMATION_REQUEST
+        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
+        .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
+        .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
+        .long   MULTIBOOT2_TAG_TYPE_MMAP
+.Lmultiboot2_info_req_end:
+
+        .align  MULTIBOOT2_TAG_ALIGN
+        .short  MULTIBOOT2_HEADER_TAG_MODULE_ALIGN
+        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
+        .long   8 /* Tag size. */
+
+        /* Console flags tag. */
+        .align  MULTIBOOT2_TAG_ALIGN
+        .short  MULTIBOOT2_HEADER_TAG_CONSOLE_FLAGS
+        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
+        .long   12 /* Tag size. */
+        .long   MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
+
+        /* Framebuffer tag. */
+        .align  MULTIBOOT2_TAG_ALIGN
+        .short  MULTIBOOT2_HEADER_TAG_FRAMEBUFFER
+        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
+        .long   20 /* Tag size. */
+        .long   0 /* Number of the columns - no preference. */
+        .long   0 /* Number of the lines - no preference. */
+        .long   0 /* Number of bits per pixel - no preference. */
+
+        /* Multiboot2 header end tag. */
+        .align  MULTIBOOT2_TAG_ALIGN
+        .short  MULTIBOOT2_HEADER_TAG_END
+        .short  0
+        .long   8 /* Tag size. */
+.Lmultiboot2_header_end:
 
         .section .init.rodata, "a", @progbits
         .align 4
@@ -81,10 +135,51 @@ __start:
         mov     %ecx,%es
         mov     %ecx,%ss
 
+        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
+        xor     %edx,%edx
+
         /* Check for Multiboot bootloader */
         cmp     $MULTIBOOT_BOOTLOADER_MAGIC,%eax
-        jne     not_multiboot
+        je      multiboot1_proto
 
+        /* Check for Multiboot2 bootloader */
+        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
+        je      multiboot2_proto
+
+        jmp     not_multiboot
+
+multiboot1_proto:
+        /* Get mem_lower from Multiboot information */
+        testb   $MBI_MEMLIMITS,(%ebx)
+        jz      trampoline_setup    /* not available? BDA value will be fine */
+
+        mov     MB_mem_lower(%ebx),%edx
+        jmp     trampoline_setup
+
+multiboot2_proto:
+        /* Skip Multiboot2 information fixed part */
+        lea     MB2_fixed_sizeof(%ebx),%ecx
+
+0:
+        /* Get mem_lower from Multiboot2 information */
+        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
+        jne     1f
+
+        mov     MB2_mem_lower(%ecx),%edx
+        jmp     trampoline_setup
+
+1:
+        /* Is it the end of Multiboot2 information? */
+        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
+        je      trampoline_setup
+
+        /* Go to next Multiboot2 information tag */
+        add     MB2_tag_size(%ecx),%ecx
+        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
+        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
+        jmp     0b
+
+trampoline_setup:
         /* Set up trampoline segment 64k below EBDA */
         movzwl  0x40e,%ecx          /* EBDA segment */
         cmp     $0xa000,%ecx        /* sanity check (high) */
@@ -99,9 +194,6 @@ __start:
          * Compare the value in the BDA with the information from the
          * multiboot structure (if available) and use the smallest.
          */
-        testb   $MBI_MEMLIMITS,(%ebx)
-        jz      2f                  /* not available? BDA value will be fine */
-        mov     MB_mem_lower(%ebx),%edx
         cmp     $0x100,%edx         /* is the multiboot value too small? */
         jb      2f                  /* if so, do not use it */
         shl     $10-4,%edx
@@ -118,9 +210,9 @@ __start:
 
         /* Save the Multiboot info struct (after relocation) for later use. */
         mov     $sym_phys(cpu0_stack)+1024,%esp
-        mov     %ecx,%eax
+        push    %eax                /* Multiboot magic */
         push    %ebx                /* Multiboot information address */
-        call    reloc               /* %eax contains trampoline address */
+        call    reloc               /* %ecx contains trampoline address */
         mov     %eax,sym_phys(multiboot_ptr)
 
         /* Initialize BSS (no nasty surprises!) */
diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index f964cda..4b89838 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -5,19 +5,26 @@
  * and modules. This is most easily done early with paging disabled.
  *
  * Copyright (c) 2009, Citrix Systems, Inc.
+ * Copyright (c) 2013, 2014, 2015 Oracle Corp.
  *
  * Authors:
  *    Keir Fraser <keir@xen.org>
+ *    Daniel Kiper
  */
 
-/* entered with %eax = BOOT_TRAMPOLINE */
+/*
+ * This entry point is entered from xen/arch/x86/boot/head.S with:
+ *   - %eax = MULTIBOOT_MAGIC,
+ *   - %ebx = MULTIBOOT_INFORMATION_ADDRESS,
+ *   - %ecx = BOOT_TRAMPOLINE.
+ */
 asm (
     "    .text                         \n"
     "    .globl _start                 \n"
     "_start:                           \n"
     "    call 1f                       \n"
     "1:  pop  %ebx                     \n"
-    "    mov  %eax,alloc-1b(%ebx)      \n"
+    "    mov  %ecx,alloc-1b(%ebx)      \n"
     "    jmp  reloc                    \n"
     );
 
@@ -31,7 +38,16 @@ asm (
     );
 
 typedef unsigned int u32;
+typedef unsigned long long u64;
+
+#include "../../../include/xen/compiler.h"
 #include "../../../include/xen/multiboot.h"
+#include "../../../include/xen/multiboot2.h"
+
+#define ALIGN_UP(addr, align) \
+                (((addr) + (typeof(addr))(align) - 1) & ~((typeof(addr))(align) - 1))
+
+#define get_mb2_data(tag, type, member) (((type *)(tag))->member)
 
 static u32 alloc_struct(u32 bytes)
 {
@@ -49,6 +65,11 @@ static u32 alloc_struct(u32 bytes)
     return s;
 }
 
+static void zero_struct(u32 s, u32 bytes)
+{
+    asm volatile("rep stosb" : "+D" (s), "+c" (bytes) : "a" (0) : "memory");
+}
+
 static u32 copy_struct(u32 src, u32 bytes)
 {
     u32 dst, dst_asm;
@@ -74,40 +95,153 @@ static u32 copy_string(u32 src)
     return copy_struct(src, p - (char *)src + 1);
 }
 
-multiboot_info_t *reloc(multiboot_info_t *mbi_old)
+static multiboot_info_t *mbi_mbi(void *mbi_in)
 {
-    multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, sizeof(*mbi));
     int i;
+    multiboot_info_t *mbi_out;
 
-    if ( mbi->flags & MBI_CMDLINE )
-        mbi->cmdline = copy_string(mbi->cmdline);
+    mbi_out = (multiboot_info_t *)copy_struct((u32)mbi_in, sizeof(*mbi_out));
 
-    if ( mbi->flags & MBI_MODULES )
+    if ( mbi_out->flags & MBI_CMDLINE )
+        mbi_out->cmdline = copy_string(mbi_out->cmdline);
+
+    if ( mbi_out->flags & MBI_MODULES )
     {
         module_t *mods = (module_t *)copy_struct(
-            mbi->mods_addr, mbi->mods_count * sizeof(module_t));
+            mbi_out->mods_addr, mbi_out->mods_count * sizeof(module_t));
 
-        mbi->mods_addr = (u32)mods;
+        mbi_out->mods_addr = (u32)mods;
 
-        for ( i = 0; i < mbi->mods_count; i++ )
+        for ( i = 0; i < mbi_out->mods_count; i++ )
         {
             if ( mods[i].string )
                 mods[i].string = copy_string(mods[i].string);
         }
     }
 
-    if ( mbi->flags & MBI_MEMMAP )
-        mbi->mmap_addr = copy_struct(mbi->mmap_addr, mbi->mmap_length);
+    if ( mbi_out->flags & MBI_MEMMAP )
+        mbi_out->mmap_addr = copy_struct(mbi_out->mmap_addr, mbi_out->mmap_length);
 
-    if ( mbi->flags & MBI_LOADERNAME )
-        mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
+    if ( mbi_out->flags & MBI_LOADERNAME )
+        mbi_out->boot_loader_name = copy_string(mbi_out->boot_loader_name);
 
     /* Mask features we don't understand or don't relocate. */
-    mbi->flags &= (MBI_MEMLIMITS |
-                   MBI_CMDLINE |
-                   MBI_MODULES |
-                   MBI_MEMMAP |
-                   MBI_LOADERNAME);
+    mbi_out->flags &= (MBI_MEMLIMITS |
+                       MBI_CMDLINE |
+                       MBI_MODULES |
+                       MBI_MEMMAP |
+                       MBI_LOADERNAME);
 
-    return mbi;
+    return mbi_out;
+}
+
+static multiboot_info_t *mbi2_mbi(void *mbi_in)
+{
+    module_t *mbi_out_mods;
+    memory_map_t *mmap_dst;
+    multiboot2_memory_map_t *mmap_src;
+    multiboot2_tag_t *tag;
+    multiboot_info_t *mbi_out;
+    u32 ptr;
+    unsigned int i, mod_idx = 0;
+
+    mbi_out = (multiboot_info_t *)alloc_struct(sizeof(*mbi_out));
+    zero_struct((u32)mbi_out, sizeof(*mbi_out));
+
+    /* Skip Multiboot2 information fixed part. */
+    tag = mbi_in + sizeof(multiboot2_fixed_t);
+
+    for ( ; ; )
+    {
+        if ( tag->type == MULTIBOOT2_TAG_TYPE_MODULE )
+            ++mbi_out->mods_count;
+        else if ( tag->type == MULTIBOOT2_TAG_TYPE_END )
+        {
+            mbi_out->flags = MBI_MODULES;
+            mbi_out->mods_addr = alloc_struct(mbi_out->mods_count * sizeof(module_t));
+            mbi_out_mods = (module_t *)mbi_out->mods_addr;
+            break;
+        }
+
+        /* Go to next Multiboot2 information tag. */
+        tag = (multiboot2_tag_t *)(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN));
+    }
+
+    /* Skip Multiboot2 information fixed part. */
+    tag = mbi_in + sizeof(multiboot2_fixed_t);
+
+    for ( ; ; )
+    {
+        switch ( tag->type )
+        {
+        case MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME:
+            mbi_out->flags |= MBI_LOADERNAME;
+            ptr = (u32)get_mb2_data(tag, multiboot2_tag_string_t, string);
+            mbi_out->boot_loader_name = copy_string(ptr);
+            break;
+
+        case MULTIBOOT2_TAG_TYPE_CMDLINE:
+            mbi_out->flags |= MBI_CMDLINE;
+            ptr = (u32)get_mb2_data(tag, multiboot2_tag_string_t, string);
+            mbi_out->cmdline = copy_string(ptr);
+            break;
+
+        case MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO:
+            mbi_out->flags |= MBI_MEMLIMITS;
+            mbi_out->mem_lower = get_mb2_data(tag, multiboot2_tag_basic_meminfo_t, mem_lower);
+            mbi_out->mem_upper = get_mb2_data(tag, multiboot2_tag_basic_meminfo_t, mem_upper);
+            break;
+
+        case MULTIBOOT2_TAG_TYPE_MMAP:
+            mbi_out->flags |= MBI_MEMMAP;
+            mbi_out->mmap_length = get_mb2_data(tag, multiboot2_tag_mmap_t, size);
+            mbi_out->mmap_length -= sizeof(multiboot2_tag_mmap_t);
+            mbi_out->mmap_length += sizeof(((multiboot2_tag_mmap_t){0}).entries);
+            mbi_out->mmap_length /= get_mb2_data(tag, multiboot2_tag_mmap_t, entry_size);
+            mbi_out->mmap_length *= sizeof(memory_map_t);
+
+            mbi_out->mmap_addr = alloc_struct(mbi_out->mmap_length);
+
+            mmap_src = get_mb2_data(tag, multiboot2_tag_mmap_t, entries);
+            mmap_dst = (memory_map_t *)mbi_out->mmap_addr;
+
+            for ( i = 0; i < mbi_out->mmap_length / sizeof(memory_map_t); ++i )
+            {
+                mmap_dst[i].size = sizeof(memory_map_t);
+                mmap_dst[i].size -= sizeof(((memory_map_t){0}).size);
+                mmap_dst[i].base_addr_low = (u32)mmap_src[i].addr;
+                mmap_dst[i].base_addr_high = (u32)(mmap_src[i].addr >> 32);
+                mmap_dst[i].length_low = (u32)mmap_src[i].len;
+                mmap_dst[i].length_high = (u32)(mmap_src[i].len >> 32);
+                mmap_dst[i].type = mmap_src[i].type;
+            }
+            break;
+
+        case MULTIBOOT2_TAG_TYPE_MODULE:
+            mbi_out_mods[mod_idx].mod_start = get_mb2_data(tag, multiboot2_tag_module_t, mod_start);
+            mbi_out_mods[mod_idx].mod_end = get_mb2_data(tag, multiboot2_tag_module_t, mod_end);
+            ptr = (u32)get_mb2_data(tag, multiboot2_tag_module_t, cmdline);
+            mbi_out_mods[mod_idx].string = copy_string(ptr);
+            mbi_out_mods[mod_idx].reserved = 0;
+            ++mod_idx;
+            break;
+
+        case MULTIBOOT2_TAG_TYPE_END:
+            return mbi_out;
+
+        default:
+            break;
+        }
+
+        /* Go to next Multiboot2 information tag. */
+        tag = (multiboot2_tag_t *)(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN));
+    }
+}
+
+static multiboot_info_t __used *reloc(void *mbi_in, u32 mb_magic)
+{
+    if ( mb_magic == MULTIBOOT2_BOOTLOADER_MAGIC )
+        return mbi2_mbi(mbi_in);
+    else
+        return mbi_mbi(mbi_in);
 }
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index 447c650..ca3712f 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -13,6 +13,7 @@
 #include <asm/fixmap.h>
 #include <asm/hardirq.h>
 #include <xen/multiboot.h>
+#include <xen/multiboot2.h>
 
 #define DEFINE(_sym, _val)                                                 \
     asm volatile ("\n.ascii\"==>#define " #_sym " %0 /* " #_val " */<==\"" \
@@ -166,4 +167,9 @@ void __dummy__(void)
     OFFSET(MB_flags, multiboot_info_t, flags);
     OFFSET(MB_cmdline, multiboot_info_t, cmdline);
     OFFSET(MB_mem_lower, multiboot_info_t, mem_lower);
+    BLANK();
+
+    DEFINE(MB2_fixed_sizeof, sizeof(multiboot2_fixed_t));
+    OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+    OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
 }
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
new file mode 100644
index 0000000..09ee64e
--- /dev/null
+++ b/xen/include/xen/multiboot2.h
@@ -0,0 +1,169 @@
+/*
+ *  Copyright (C) 1999,2003,2007,2008,2009,2010  Free Software Foundation, Inc.
+ *
+ *  multiboot2.h - Multiboot 2 header file.
+ *
+ *  Based on grub-2.00/include/multiboot2.h file.
+ *
+ *  Permission is hereby granted, free of charge, to any person obtaining a copy
+ *  of this software and associated documentation files (the "Software"), to
+ *  deal in the Software without restriction, including without limitation the
+ *  rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ *  sell copies of the Software, and to permit persons to whom the Software is
+ *  furnished to do so, subject to the following conditions:
+ *
+ *  The above copyright notice and this permission notice shall be included in
+ *  all copies or substantial portions of the Software.
+ *
+ *  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ *  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ *  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL ANY
+ *  DEVELOPER OR DISTRIBUTOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *  WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR
+ *  IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __MULTIBOOT2_H__
+#define __MULTIBOOT2_H__
+
+/* The magic field should contain this.  */
+#define MULTIBOOT2_HEADER_MAGIC			0xe85250d6
+
+/* This should be in %eax on x86 architecture.  */
+#define MULTIBOOT2_BOOTLOADER_MAGIC		0x36d76289
+
+/* How many bytes from the start of the file we search for the header.  */
+#define MULTIBOOT2_SEARCH			32768
+
+/* Multiboot 2 header alignment. */
+#define MULTIBOOT2_HEADER_ALIGN			8
+
+/* Alignment of multiboot 2 modules.  */
+#define MULTIBOOT2_MOD_ALIGN			0x00001000
+
+/* Alignment of the multiboot 2 info structure.  */
+#define MULTIBOOT2_INFO_ALIGN			0x00000008
+
+/* Multiboot 2 architectures. */
+#define MULTIBOOT2_ARCHITECTURE_I386	0
+#define MULTIBOOT2_ARCHITECTURE_MIPS32	4
+
+/* Header tag types. */
+#define MULTIBOOT2_HEADER_TAG_END			0
+#define MULTIBOOT2_HEADER_TAG_INFORMATION_REQUEST	1
+#define MULTIBOOT2_HEADER_TAG_ADDRESS			2
+#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS		3
+#define MULTIBOOT2_HEADER_TAG_CONSOLE_FLAGS		4
+#define MULTIBOOT2_HEADER_TAG_FRAMEBUFFER		5
+#define MULTIBOOT2_HEADER_TAG_MODULE_ALIGN		6
+#define MULTIBOOT2_HEADER_TAG_EFI_BS			7
+#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32	8
+#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64	9
+
+/* Header tag flags. */
+#define MULTIBOOT2_HEADER_TAG_REQUIRED	0
+#define MULTIBOOT2_HEADER_TAG_OPTIONAL	1
+
+/* Header console tag console_flags. */
+#define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED	1
+#define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED	2
+
+/* Flags set in the 'flags' member of the multiboot header.  */
+#define MULTIBOOT2_TAG_TYPE_END			0
+#define MULTIBOOT2_TAG_TYPE_CMDLINE		1
+#define MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME	2
+#define MULTIBOOT2_TAG_TYPE_MODULE		3
+#define MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO	4
+#define MULTIBOOT2_TAG_TYPE_BOOTDEV		5
+#define MULTIBOOT2_TAG_TYPE_MMAP		6
+#define MULTIBOOT2_TAG_TYPE_VBE			7
+#define MULTIBOOT2_TAG_TYPE_FRAMEBUFFER		8
+#define MULTIBOOT2_TAG_TYPE_ELF_SECTIONS	9
+#define MULTIBOOT2_TAG_TYPE_APM			10
+#define MULTIBOOT2_TAG_TYPE_EFI32		11
+#define MULTIBOOT2_TAG_TYPE_EFI64		12
+#define MULTIBOOT2_TAG_TYPE_SMBIOS		13
+#define MULTIBOOT2_TAG_TYPE_ACPI_OLD		14
+#define MULTIBOOT2_TAG_TYPE_ACPI_NEW		15
+#define MULTIBOOT2_TAG_TYPE_NETWORK		16
+#define MULTIBOOT2_TAG_TYPE_EFI_MMAP		17
+#define MULTIBOOT2_TAG_TYPE_EFI_BS		18
+#define MULTIBOOT2_TAG_TYPE_EFI32_IH		19
+#define MULTIBOOT2_TAG_TYPE_EFI64_IH		20
+
+/* Multiboot 2 tag alignment. */
+#define MULTIBOOT2_TAG_ALIGN			8
+
+/* Memory types. */
+#define MULTIBOOT2_MEMORY_AVAILABLE		1
+#define MULTIBOOT2_MEMORY_RESERVED		2
+#define MULTIBOOT2_MEMORY_ACPI_RECLAIMABLE	3
+#define MULTIBOOT2_MEMORY_NVS			4
+#define MULTIBOOT2_MEMORY_BADRAM		5
+
+/* Framebuffer types. */
+#define MULTIBOOT2_FRAMEBUFFER_TYPE_INDEXED	0
+#define MULTIBOOT2_FRAMEBUFFER_TYPE_RGB		1
+#define MULTIBOOT2_FRAMEBUFFER_TYPE_EGA_TEXT	2
+
+#ifndef __ASSEMBLY__
+typedef struct {
+    u32 total_size;
+    u32 reserved;
+} multiboot2_fixed_t;
+
+typedef struct {
+    u32 type;
+    u32 size;
+} multiboot2_tag_t;
+
+typedef struct {
+    u32 type;
+    u32 size;
+    char string[0];
+} multiboot2_tag_string_t;
+
+typedef struct {
+    u32 type;
+    u32 size;
+    u32 mem_lower;
+    u32 mem_upper;
+} multiboot2_tag_basic_meminfo_t;
+
+typedef struct __packed {
+    u64 addr;
+    u64 len;
+    u32 type;
+    u32 zero;
+} multiboot2_memory_map_t;
+
+typedef struct {
+    u32 type;
+    u32 size;
+    u32 entry_size;
+    u32 entry_version;
+    multiboot2_memory_map_t entries[0];
+} multiboot2_tag_mmap_t;
+
+typedef struct {
+    u32 type;
+    u32 size;
+    u64 pointer;
+} multiboot2_tag_efi64_t;
+
+typedef struct {
+    u32 type;
+    u32 size;
+    u64 pointer;
+} multiboot2_tag_efi64_ih_t;
+
+typedef struct {
+    u32 type;
+    u32 size;
+    u32 mod_start;
+    u32 mod_end;
+    char cmdline[0];
+} multiboot2_tag_module_t;
+#endif /* __ASSEMBLY__ */
+
+#endif /* __MULTIBOOT2_H__ */
-- 
1.7.10.4

Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support

[Andrew Cooper]

On 30/01/15 17:54, Daniel Kiper wrote:
> Add multiboot2 protocol support. Alter min memory limit handling as we
> now may not find it from either multiboot (v1) or multiboot2.
>
> This way we are laying the foundation for EFI + GRUB2 + Xen development.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

I have not reviewed the multiboot2 protocol in detail, but it appears
sane and I presume it is suitably tested and works.

As far as the mb1/mb2 interaction goes, this is looking far better.

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  xen/arch/x86/boot/Makefile        |    3 +-
>  xen/arch/x86/boot/head.S          |  104 ++++++++++++++++++++--
>  xen/arch/x86/boot/reloc.c         |  174 ++++++++++++++++++++++++++++++++-----
>  xen/arch/x86/x86_64/asm-offsets.c |    6 ++
>  xen/include/xen/multiboot2.h      |  169 +++++++++++++++++++++++++++++++++++
>  5 files changed, 429 insertions(+), 27 deletions(-)
>  create mode 100644 xen/include/xen/multiboot2.h
>
> diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
> index 5fdb5ae..0efa7d2 100644
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -1,6 +1,7 @@
>  obj-bin-y += head.o
>  
> -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h
> +RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/compiler.h \
> +	     $(BASEDIR)/include/xen/multiboot.h $(BASEDIR)/include/xen/multiboot2.h
>  
>  head.o: reloc.S
>  
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 6180783..7861057 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -1,5 +1,6 @@
>  #include <xen/config.h>
>  #include <xen/multiboot.h>
> +#include <xen/multiboot2.h>
>  #include <public/xen.h>
>  #include <asm/asm_defns.h>
>  #include <asm/desc.h>
> @@ -32,6 +33,59 @@ ENTRY(start)
>          .long   MULTIBOOT_HEADER_FLAGS
>          /* Checksum: must be the negated sum of the first two fields. */
>          .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
> + 
> +/*** MULTIBOOT2 HEADER ****/
> +/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S file. */
> +        .align  MULTIBOOT2_HEADER_ALIGN
> +
> +.Lmultiboot2_header:
> +        /* Magic number indicating a Multiboot2 header. */
> +        .long   MULTIBOOT2_HEADER_MAGIC
> +        /* Architecture: i386. */
> +        .long   MULTIBOOT2_ARCHITECTURE_I386
> +        /* Multiboot2 header length. */
> +        .long   .Lmultiboot2_header_end - .Lmultiboot2_header
> +        /* Multiboot2 header checksum. */
> +        .long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
> +                        (.Lmultiboot2_header_end - .Lmultiboot2_header))
> +
> +        /* Multiboot2 tags... */
> +.Lmultiboot2_info_req:
> +        /* Multiboot2 information request tag. */
> +        .short  MULTIBOOT2_HEADER_TAG_INFORMATION_REQUEST
> +        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
> +        .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
> +        .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
> +        .long   MULTIBOOT2_TAG_TYPE_MMAP
> +.Lmultiboot2_info_req_end:
> +
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_MODULE_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
> +        .long   8 /* Tag size. */
> +
> +        /* Console flags tag. */
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_CONSOLE_FLAGS
> +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> +        .long   12 /* Tag size. */
> +        .long   MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
> +
> +        /* Framebuffer tag. */
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_FRAMEBUFFER
> +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> +        .long   20 /* Tag size. */
> +        .long   0 /* Number of the columns - no preference. */
> +        .long   0 /* Number of the lines - no preference. */
> +        .long   0 /* Number of bits per pixel - no preference. */
> +
> +        /* Multiboot2 header end tag. */
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_END
> +        .short  0
> +        .long   8 /* Tag size. */
> +.Lmultiboot2_header_end:
>  
>          .section .init.rodata, "a", @progbits
>          .align 4
> @@ -81,10 +135,51 @@ __start:
>          mov     %ecx,%es
>          mov     %ecx,%ss
>  
> +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> +        xor     %edx,%edx
> +
>          /* Check for Multiboot bootloader */
>          cmp     $MULTIBOOT_BOOTLOADER_MAGIC,%eax
> -        jne     not_multiboot
> +        je      multiboot1_proto
>  
> +        /* Check for Multiboot2 bootloader */
> +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> +        je      multiboot2_proto
> +
> +        jmp     not_multiboot
> +
> +multiboot1_proto:
> +        /* Get mem_lower from Multiboot information */
> +        testb   $MBI_MEMLIMITS,(%ebx)
> +        jz      trampoline_setup    /* not available? BDA value will be fine */
> +
> +        mov     MB_mem_lower(%ebx),%edx
> +        jmp     trampoline_setup
> +
> +multiboot2_proto:
> +        /* Skip Multiboot2 information fixed part */
> +        lea     MB2_fixed_sizeof(%ebx),%ecx
> +
> +0:
> +        /* Get mem_lower from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> +        jne     1f
> +
> +        mov     MB2_mem_lower(%ecx),%edx
> +        jmp     trampoline_setup
> +
> +1:
> +        /* Is it the end of Multiboot2 information? */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
> +        je      trampoline_setup
> +
> +        /* Go to next Multiboot2 information tag */
> +        add     MB2_tag_size(%ecx),%ecx
> +        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +        jmp     0b
> +
> +trampoline_setup:
>          /* Set up trampoline segment 64k below EBDA */
>          movzwl  0x40e,%ecx          /* EBDA segment */
>          cmp     $0xa000,%ecx        /* sanity check (high) */
> @@ -99,9 +194,6 @@ __start:
>           * Compare the value in the BDA with the information from the
>           * multiboot structure (if available) and use the smallest.
>           */
> -        testb   $MBI_MEMLIMITS,(%ebx)
> -        jz      2f                  /* not available? BDA value will be fine */
> -        mov     MB_mem_lower(%ebx),%edx
>          cmp     $0x100,%edx         /* is the multiboot value too small? */
>          jb      2f                  /* if so, do not use it */
>          shl     $10-4,%edx
> @@ -118,9 +210,9 @@ __start:
>  
>          /* Save the Multiboot info struct (after relocation) for later use. */
>          mov     $sym_phys(cpu0_stack)+1024,%esp
> -        mov     %ecx,%eax
> +        push    %eax                /* Multiboot magic */
>          push    %ebx                /* Multiboot information address */
> -        call    reloc               /* %eax contains trampoline address */
> +        call    reloc               /* %ecx contains trampoline address */
>          mov     %eax,sym_phys(multiboot_ptr)
>  
>          /* Initialize BSS (no nasty surprises!) */
> diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
> index f964cda..4b89838 100644
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -5,19 +5,26 @@
>   * and modules. This is most easily done early with paging disabled.
>   *
>   * Copyright (c) 2009, Citrix Systems, Inc.
> + * Copyright (c) 2013, 2014, 2015 Oracle Corp.
>   *
>   * Authors:
>   *    Keir Fraser <keir@xen.org>
> + *    Daniel Kiper
>   */
>  
> -/* entered with %eax = BOOT_TRAMPOLINE */
> +/*
> + * This entry point is entered from xen/arch/x86/boot/head.S with:
> + *   - %eax = MULTIBOOT_MAGIC,
> + *   - %ebx = MULTIBOOT_INFORMATION_ADDRESS,
> + *   - %ecx = BOOT_TRAMPOLINE.
> + */
>  asm (
>      "    .text                         \n"
>      "    .globl _start                 \n"
>      "_start:                           \n"
>      "    call 1f                       \n"
>      "1:  pop  %ebx                     \n"
> -    "    mov  %eax,alloc-1b(%ebx)      \n"
> +    "    mov  %ecx,alloc-1b(%ebx)      \n"
>      "    jmp  reloc                    \n"
>      );
>  
> @@ -31,7 +38,16 @@ asm (
>      );
>  
>  typedef unsigned int u32;
> +typedef unsigned long long u64;
> +
> +#include "../../../include/xen/compiler.h"
>  #include "../../../include/xen/multiboot.h"
> +#include "../../../include/xen/multiboot2.h"
> +
> +#define ALIGN_UP(addr, align) \
> +                (((addr) + (typeof(addr))(align) - 1) & ~((typeof(addr))(align) - 1))
> +
> +#define get_mb2_data(tag, type, member) (((type *)(tag))->member)
>  
>  static u32 alloc_struct(u32 bytes)
>  {
> @@ -49,6 +65,11 @@ static u32 alloc_struct(u32 bytes)
>      return s;
>  }
>  
> +static void zero_struct(u32 s, u32 bytes)
> +{
> +    asm volatile("rep stosb" : "+D" (s), "+c" (bytes) : "a" (0) : "memory");
> +}
> +
>  static u32 copy_struct(u32 src, u32 bytes)
>  {
>      u32 dst, dst_asm;
> @@ -74,40 +95,153 @@ static u32 copy_string(u32 src)
>      return copy_struct(src, p - (char *)src + 1);
>  }
>  
> -multiboot_info_t *reloc(multiboot_info_t *mbi_old)
> +static multiboot_info_t *mbi_mbi(void *mbi_in)
>  {
> -    multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, sizeof(*mbi));
>      int i;
> +    multiboot_info_t *mbi_out;
>  
> -    if ( mbi->flags & MBI_CMDLINE )
> -        mbi->cmdline = copy_string(mbi->cmdline);
> +    mbi_out = (multiboot_info_t *)copy_struct((u32)mbi_in, sizeof(*mbi_out));
>  
> -    if ( mbi->flags & MBI_MODULES )
> +    if ( mbi_out->flags & MBI_CMDLINE )
> +        mbi_out->cmdline = copy_string(mbi_out->cmdline);
> +
> +    if ( mbi_out->flags & MBI_MODULES )
>      {
>          module_t *mods = (module_t *)copy_struct(
> -            mbi->mods_addr, mbi->mods_count * sizeof(module_t));
> +            mbi_out->mods_addr, mbi_out->mods_count * sizeof(module_t));
>  
> -        mbi->mods_addr = (u32)mods;
> +        mbi_out->mods_addr = (u32)mods;
>  
> -        for ( i = 0; i < mbi->mods_count; i++ )
> +        for ( i = 0; i < mbi_out->mods_count; i++ )
>          {
>              if ( mods[i].string )
>                  mods[i].string = copy_string(mods[i].string);
>          }
>      }
>  
> -    if ( mbi->flags & MBI_MEMMAP )
> -        mbi->mmap_addr = copy_struct(mbi->mmap_addr, mbi->mmap_length);
> +    if ( mbi_out->flags & MBI_MEMMAP )
> +        mbi_out->mmap_addr = copy_struct(mbi_out->mmap_addr, mbi_out->mmap_length);
>  
> -    if ( mbi->flags & MBI_LOADERNAME )
> -        mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
> +    if ( mbi_out->flags & MBI_LOADERNAME )
> +        mbi_out->boot_loader_name = copy_string(mbi_out->boot_loader_name);
>  
>      /* Mask features we don't understand or don't relocate. */
> -    mbi->flags &= (MBI_MEMLIMITS |
> -                   MBI_CMDLINE |
> -                   MBI_MODULES |
> -                   MBI_MEMMAP |
> -                   MBI_LOADERNAME);
> +    mbi_out->flags &= (MBI_MEMLIMITS |
> +                       MBI_CMDLINE |
> +                       MBI_MODULES |
> +                       MBI_MEMMAP |
> +                       MBI_LOADERNAME);
>  
> -    return mbi;
> +    return mbi_out;
> +}
> +
> +static multiboot_info_t *mbi2_mbi(void *mbi_in)
> +{
> +    module_t *mbi_out_mods;
> +    memory_map_t *mmap_dst;
> +    multiboot2_memory_map_t *mmap_src;
> +    multiboot2_tag_t *tag;
> +    multiboot_info_t *mbi_out;
> +    u32 ptr;
> +    unsigned int i, mod_idx = 0;
> +
> +    mbi_out = (multiboot_info_t *)alloc_struct(sizeof(*mbi_out));
> +    zero_struct((u32)mbi_out, sizeof(*mbi_out));
> +
> +    /* Skip Multiboot2 information fixed part. */
> +    tag = mbi_in + sizeof(multiboot2_fixed_t);
> +
> +    for ( ; ; )
> +    {
> +        if ( tag->type == MULTIBOOT2_TAG_TYPE_MODULE )
> +            ++mbi_out->mods_count;
> +        else if ( tag->type == MULTIBOOT2_TAG_TYPE_END )
> +        {
> +            mbi_out->flags = MBI_MODULES;
> +            mbi_out->mods_addr = alloc_struct(mbi_out->mods_count * sizeof(module_t));
> +            mbi_out_mods = (module_t *)mbi_out->mods_addr;
> +            break;
> +        }
> +
> +        /* Go to next Multiboot2 information tag. */
> +        tag = (multiboot2_tag_t *)(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN));
> +    }
> +
> +    /* Skip Multiboot2 information fixed part. */
> +    tag = mbi_in + sizeof(multiboot2_fixed_t);
> +
> +    for ( ; ; )
> +    {
> +        switch ( tag->type )
> +        {
> +        case MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME:
> +            mbi_out->flags |= MBI_LOADERNAME;
> +            ptr = (u32)get_mb2_data(tag, multiboot2_tag_string_t, string);
> +            mbi_out->boot_loader_name = copy_string(ptr);
> +            break;
> +
> +        case MULTIBOOT2_TAG_TYPE_CMDLINE:
> +            mbi_out->flags |= MBI_CMDLINE;
> +            ptr = (u32)get_mb2_data(tag, multiboot2_tag_string_t, string);
> +            mbi_out->cmdline = copy_string(ptr);
> +            break;
> +
> +        case MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO:
> +            mbi_out->flags |= MBI_MEMLIMITS;
> +            mbi_out->mem_lower = get_mb2_data(tag, multiboot2_tag_basic_meminfo_t, mem_lower);
> +            mbi_out->mem_upper = get_mb2_data(tag, multiboot2_tag_basic_meminfo_t, mem_upper);
> +            break;
> +
> +        case MULTIBOOT2_TAG_TYPE_MMAP:
> +            mbi_out->flags |= MBI_MEMMAP;
> +            mbi_out->mmap_length = get_mb2_data(tag, multiboot2_tag_mmap_t, size);
> +            mbi_out->mmap_length -= sizeof(multiboot2_tag_mmap_t);
> +            mbi_out->mmap_length += sizeof(((multiboot2_tag_mmap_t){0}).entries);
> +            mbi_out->mmap_length /= get_mb2_data(tag, multiboot2_tag_mmap_t, entry_size);
> +            mbi_out->mmap_length *= sizeof(memory_map_t);
> +
> +            mbi_out->mmap_addr = alloc_struct(mbi_out->mmap_length);
> +
> +            mmap_src = get_mb2_data(tag, multiboot2_tag_mmap_t, entries);
> +            mmap_dst = (memory_map_t *)mbi_out->mmap_addr;
> +
> +            for ( i = 0; i < mbi_out->mmap_length / sizeof(memory_map_t); ++i )
> +            {
> +                mmap_dst[i].size = sizeof(memory_map_t);
> +                mmap_dst[i].size -= sizeof(((memory_map_t){0}).size);
> +                mmap_dst[i].base_addr_low = (u32)mmap_src[i].addr;
> +                mmap_dst[i].base_addr_high = (u32)(mmap_src[i].addr >> 32);
> +                mmap_dst[i].length_low = (u32)mmap_src[i].len;
> +                mmap_dst[i].length_high = (u32)(mmap_src[i].len >> 32);
> +                mmap_dst[i].type = mmap_src[i].type;
> +            }
> +            break;
> +
> +        case MULTIBOOT2_TAG_TYPE_MODULE:
> +            mbi_out_mods[mod_idx].mod_start = get_mb2_data(tag, multiboot2_tag_module_t, mod_start);
> +            mbi_out_mods[mod_idx].mod_end = get_mb2_data(tag, multiboot2_tag_module_t, mod_end);
> +            ptr = (u32)get_mb2_data(tag, multiboot2_tag_module_t, cmdline);
> +            mbi_out_mods[mod_idx].string = copy_string(ptr);
> +            mbi_out_mods[mod_idx].reserved = 0;
> +            ++mod_idx;
> +            break;
> +
> +        case MULTIBOOT2_TAG_TYPE_END:
> +            return mbi_out;
> +
> +        default:
> +            break;
> +        }
> +
> +        /* Go to next Multiboot2 information tag. */
> +        tag = (multiboot2_tag_t *)(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN));
> +    }
> +}
> +
> +static multiboot_info_t __used *reloc(void *mbi_in, u32 mb_magic)
> +{
> +    if ( mb_magic == MULTIBOOT2_BOOTLOADER_MAGIC )
> +        return mbi2_mbi(mbi_in);
> +    else
> +        return mbi_mbi(mbi_in);
>  }
> diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
> index 447c650..ca3712f 100644
> --- a/xen/arch/x86/x86_64/asm-offsets.c
> +++ b/xen/arch/x86/x86_64/asm-offsets.c
> @@ -13,6 +13,7 @@
>  #include <asm/fixmap.h>
>  #include <asm/hardirq.h>
>  #include <xen/multiboot.h>
> +#include <xen/multiboot2.h>
>  
>  #define DEFINE(_sym, _val)                                                 \
>      asm volatile ("\n.ascii\"==>#define " #_sym " %0 /* " #_val " */<==\"" \
> @@ -166,4 +167,9 @@ void __dummy__(void)
>      OFFSET(MB_flags, multiboot_info_t, flags);
>      OFFSET(MB_cmdline, multiboot_info_t, cmdline);
>      OFFSET(MB_mem_lower, multiboot_info_t, mem_lower);
> +    BLANK();
> +
> +    DEFINE(MB2_fixed_sizeof, sizeof(multiboot2_fixed_t));
> +    OFFSET(MB2_tag_size, multiboot2_tag_t, size);
> +    OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
>  }
> diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
> new file mode 100644
> index 0000000..09ee64e
> --- /dev/null
> +++ b/xen/include/xen/multiboot2.h
> @@ -0,0 +1,169 @@
> +/*
> + *  Copyright (C) 1999,2003,2007,2008,2009,2010  Free Software Foundation, Inc.
> + *
> + *  multiboot2.h - Multiboot 2 header file.
> + *
> + *  Based on grub-2.00/include/multiboot2.h file.
> + *
> + *  Permission is hereby granted, free of charge, to any person obtaining a copy
> + *  of this software and associated documentation files (the "Software"), to
> + *  deal in the Software without restriction, including without limitation the
> + *  rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + *  sell copies of the Software, and to permit persons to whom the Software is
> + *  furnished to do so, subject to the following conditions:
> + *
> + *  The above copyright notice and this permission notice shall be included in
> + *  all copies or substantial portions of the Software.
> + *
> + *  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + *  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + *  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL ANY
> + *  DEVELOPER OR DISTRIBUTOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *  WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR
> + *  IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef __MULTIBOOT2_H__
> +#define __MULTIBOOT2_H__
> +
> +/* The magic field should contain this.  */
> +#define MULTIBOOT2_HEADER_MAGIC			0xe85250d6
> +
> +/* This should be in %eax on x86 architecture.  */
> +#define MULTIBOOT2_BOOTLOADER_MAGIC		0x36d76289
> +
> +/* How many bytes from the start of the file we search for the header.  */
> +#define MULTIBOOT2_SEARCH			32768
> +
> +/* Multiboot 2 header alignment. */
> +#define MULTIBOOT2_HEADER_ALIGN			8
> +
> +/* Alignment of multiboot 2 modules.  */
> +#define MULTIBOOT2_MOD_ALIGN			0x00001000
> +
> +/* Alignment of the multiboot 2 info structure.  */
> +#define MULTIBOOT2_INFO_ALIGN			0x00000008
> +
> +/* Multiboot 2 architectures. */
> +#define MULTIBOOT2_ARCHITECTURE_I386	0
> +#define MULTIBOOT2_ARCHITECTURE_MIPS32	4
> +
> +/* Header tag types. */
> +#define MULTIBOOT2_HEADER_TAG_END			0
> +#define MULTIBOOT2_HEADER_TAG_INFORMATION_REQUEST	1
> +#define MULTIBOOT2_HEADER_TAG_ADDRESS			2
> +#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS		3
> +#define MULTIBOOT2_HEADER_TAG_CONSOLE_FLAGS		4
> +#define MULTIBOOT2_HEADER_TAG_FRAMEBUFFER		5
> +#define MULTIBOOT2_HEADER_TAG_MODULE_ALIGN		6
> +#define MULTIBOOT2_HEADER_TAG_EFI_BS			7
> +#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32	8
> +#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64	9
> +
> +/* Header tag flags. */
> +#define MULTIBOOT2_HEADER_TAG_REQUIRED	0
> +#define MULTIBOOT2_HEADER_TAG_OPTIONAL	1
> +
> +/* Header console tag console_flags. */
> +#define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED	1
> +#define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED	2
> +
> +/* Flags set in the 'flags' member of the multiboot header.  */
> +#define MULTIBOOT2_TAG_TYPE_END			0
> +#define MULTIBOOT2_TAG_TYPE_CMDLINE		1
> +#define MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME	2
> +#define MULTIBOOT2_TAG_TYPE_MODULE		3
> +#define MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO	4
> +#define MULTIBOOT2_TAG_TYPE_BOOTDEV		5
> +#define MULTIBOOT2_TAG_TYPE_MMAP		6
> +#define MULTIBOOT2_TAG_TYPE_VBE			7
> +#define MULTIBOOT2_TAG_TYPE_FRAMEBUFFER		8
> +#define MULTIBOOT2_TAG_TYPE_ELF_SECTIONS	9
> +#define MULTIBOOT2_TAG_TYPE_APM			10
> +#define MULTIBOOT2_TAG_TYPE_EFI32		11
> +#define MULTIBOOT2_TAG_TYPE_EFI64		12
> +#define MULTIBOOT2_TAG_TYPE_SMBIOS		13
> +#define MULTIBOOT2_TAG_TYPE_ACPI_OLD		14
> +#define MULTIBOOT2_TAG_TYPE_ACPI_NEW		15
> +#define MULTIBOOT2_TAG_TYPE_NETWORK		16
> +#define MULTIBOOT2_TAG_TYPE_EFI_MMAP		17
> +#define MULTIBOOT2_TAG_TYPE_EFI_BS		18
> +#define MULTIBOOT2_TAG_TYPE_EFI32_IH		19
> +#define MULTIBOOT2_TAG_TYPE_EFI64_IH		20
> +
> +/* Multiboot 2 tag alignment. */
> +#define MULTIBOOT2_TAG_ALIGN			8
> +
> +/* Memory types. */
> +#define MULTIBOOT2_MEMORY_AVAILABLE		1
> +#define MULTIBOOT2_MEMORY_RESERVED		2
> +#define MULTIBOOT2_MEMORY_ACPI_RECLAIMABLE	3
> +#define MULTIBOOT2_MEMORY_NVS			4
> +#define MULTIBOOT2_MEMORY_BADRAM		5
> +
> +/* Framebuffer types. */
> +#define MULTIBOOT2_FRAMEBUFFER_TYPE_INDEXED	0
> +#define MULTIBOOT2_FRAMEBUFFER_TYPE_RGB		1
> +#define MULTIBOOT2_FRAMEBUFFER_TYPE_EGA_TEXT	2
> +
> +#ifndef __ASSEMBLY__
> +typedef struct {
> +    u32 total_size;
> +    u32 reserved;
> +} multiboot2_fixed_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +} multiboot2_tag_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +    char string[0];
> +} multiboot2_tag_string_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +    u32 mem_lower;
> +    u32 mem_upper;
> +} multiboot2_tag_basic_meminfo_t;
> +
> +typedef struct __packed {
> +    u64 addr;
> +    u64 len;
> +    u32 type;
> +    u32 zero;
> +} multiboot2_memory_map_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +    u32 entry_size;
> +    u32 entry_version;
> +    multiboot2_memory_map_t entries[0];
> +} multiboot2_tag_mmap_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +    u64 pointer;
> +} multiboot2_tag_efi64_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +    u64 pointer;
> +} multiboot2_tag_efi64_ih_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +    u32 mod_start;
> +    u32 mod_end;
> +    char cmdline[0];
> +} multiboot2_tag_module_t;
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* __MULTIBOOT2_H__ */

Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support

[Andrew Cooper]

On 30/01/15 17:54, Daniel Kiper wrote:
> Add multiboot2 protocol support. Alter min memory limit handling as we
> now may not find it from either multiboot (v1) or multiboot2.
>
> This way we are laying the foundation for EFI + GRUB2 + Xen development.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>

I have not reviewed the multiboot2 protocol in detail, but it appears
sane and I presume it is suitably tested and works.

As far as the mb1/mb2 interaction goes, this is looking far better.

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
>  xen/arch/x86/boot/Makefile        |    3 +-
>  xen/arch/x86/boot/head.S          |  104 ++++++++++++++++++++--
>  xen/arch/x86/boot/reloc.c         |  174 ++++++++++++++++++++++++++++++++-----
>  xen/arch/x86/x86_64/asm-offsets.c |    6 ++
>  xen/include/xen/multiboot2.h      |  169 +++++++++++++++++++++++++++++++++++
>  5 files changed, 429 insertions(+), 27 deletions(-)
>  create mode 100644 xen/include/xen/multiboot2.h
>
> diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
> index 5fdb5ae..0efa7d2 100644
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -1,6 +1,7 @@
>  obj-bin-y += head.o
>  
> -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h
> +RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/compiler.h \
> +	     $(BASEDIR)/include/xen/multiboot.h $(BASEDIR)/include/xen/multiboot2.h
>  
>  head.o: reloc.S
>  
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 6180783..7861057 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -1,5 +1,6 @@
>  #include <xen/config.h>
>  #include <xen/multiboot.h>
> +#include <xen/multiboot2.h>
>  #include <public/xen.h>
>  #include <asm/asm_defns.h>
>  #include <asm/desc.h>
> @@ -32,6 +33,59 @@ ENTRY(start)
>          .long   MULTIBOOT_HEADER_FLAGS
>          /* Checksum: must be the negated sum of the first two fields. */
>          .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
> + 
> +/*** MULTIBOOT2 HEADER ****/
> +/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S file. */
> +        .align  MULTIBOOT2_HEADER_ALIGN
> +
> +.Lmultiboot2_header:
> +        /* Magic number indicating a Multiboot2 header. */
> +        .long   MULTIBOOT2_HEADER_MAGIC
> +        /* Architecture: i386. */
> +        .long   MULTIBOOT2_ARCHITECTURE_I386
> +        /* Multiboot2 header length. */
> +        .long   .Lmultiboot2_header_end - .Lmultiboot2_header
> +        /* Multiboot2 header checksum. */
> +        .long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
> +                        (.Lmultiboot2_header_end - .Lmultiboot2_header))
> +
> +        /* Multiboot2 tags... */
> +.Lmultiboot2_info_req:
> +        /* Multiboot2 information request tag. */
> +        .short  MULTIBOOT2_HEADER_TAG_INFORMATION_REQUEST
> +        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
> +        .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
> +        .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
> +        .long   MULTIBOOT2_TAG_TYPE_MMAP
> +.Lmultiboot2_info_req_end:
> +
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_MODULE_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
> +        .long   8 /* Tag size. */
> +
> +        /* Console flags tag. */
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_CONSOLE_FLAGS
> +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> +        .long   12 /* Tag size. */
> +        .long   MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
> +
> +        /* Framebuffer tag. */
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_FRAMEBUFFER
> +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> +        .long   20 /* Tag size. */
> +        .long   0 /* Number of the columns - no preference. */
> +        .long   0 /* Number of the lines - no preference. */
> +        .long   0 /* Number of bits per pixel - no preference. */
> +
> +        /* Multiboot2 header end tag. */
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_END
> +        .short  0
> +        .long   8 /* Tag size. */
> +.Lmultiboot2_header_end:
>  
>          .section .init.rodata, "a", @progbits
>          .align 4
> @@ -81,10 +135,51 @@ __start:
>          mov     %ecx,%es
>          mov     %ecx,%ss
>  
> +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> +        xor     %edx,%edx
> +
>          /* Check for Multiboot bootloader */
>          cmp     $MULTIBOOT_BOOTLOADER_MAGIC,%eax
> -        jne     not_multiboot
> +        je      multiboot1_proto
>  
> +        /* Check for Multiboot2 bootloader */
> +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> +        je      multiboot2_proto
> +
> +        jmp     not_multiboot
> +
> +multiboot1_proto:
> +        /* Get mem_lower from Multiboot information */
> +        testb   $MBI_MEMLIMITS,(%ebx)
> +        jz      trampoline_setup    /* not available? BDA value will be fine */
> +
> +        mov     MB_mem_lower(%ebx),%edx
> +        jmp     trampoline_setup
> +
> +multiboot2_proto:
> +        /* Skip Multiboot2 information fixed part */
> +        lea     MB2_fixed_sizeof(%ebx),%ecx
> +
> +0:
> +        /* Get mem_lower from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> +        jne     1f
> +
> +        mov     MB2_mem_lower(%ecx),%edx
> +        jmp     trampoline_setup
> +
> +1:
> +        /* Is it the end of Multiboot2 information? */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
> +        je      trampoline_setup
> +
> +        /* Go to next Multiboot2 information tag */
> +        add     MB2_tag_size(%ecx),%ecx
> +        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +        jmp     0b
> +
> +trampoline_setup:
>          /* Set up trampoline segment 64k below EBDA */
>          movzwl  0x40e,%ecx          /* EBDA segment */
>          cmp     $0xa000,%ecx        /* sanity check (high) */
> @@ -99,9 +194,6 @@ __start:
>           * Compare the value in the BDA with the information from the
>           * multiboot structure (if available) and use the smallest.
>           */
> -        testb   $MBI_MEMLIMITS,(%ebx)
> -        jz      2f                  /* not available? BDA value will be fine */
> -        mov     MB_mem_lower(%ebx),%edx
>          cmp     $0x100,%edx         /* is the multiboot value too small? */
>          jb      2f                  /* if so, do not use it */
>          shl     $10-4,%edx
> @@ -118,9 +210,9 @@ __start:
>  
>          /* Save the Multiboot info struct (after relocation) for later use. */
>          mov     $sym_phys(cpu0_stack)+1024,%esp
> -        mov     %ecx,%eax
> +        push    %eax                /* Multiboot magic */
>          push    %ebx                /* Multiboot information address */
> -        call    reloc               /* %eax contains trampoline address */
> +        call    reloc               /* %ecx contains trampoline address */
>          mov     %eax,sym_phys(multiboot_ptr)
>  
>          /* Initialize BSS (no nasty surprises!) */
> diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
> index f964cda..4b89838 100644
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -5,19 +5,26 @@
>   * and modules. This is most easily done early with paging disabled.
>   *
>   * Copyright (c) 2009, Citrix Systems, Inc.
> + * Copyright (c) 2013, 2014, 2015 Oracle Corp.
>   *
>   * Authors:
>   *    Keir Fraser <keir@xen.org>
> + *    Daniel Kiper
>   */
>  
> -/* entered with %eax = BOOT_TRAMPOLINE */
> +/*
> + * This entry point is entered from xen/arch/x86/boot/head.S with:
> + *   - %eax = MULTIBOOT_MAGIC,
> + *   - %ebx = MULTIBOOT_INFORMATION_ADDRESS,
> + *   - %ecx = BOOT_TRAMPOLINE.
> + */
>  asm (
>      "    .text                         \n"
>      "    .globl _start                 \n"
>      "_start:                           \n"
>      "    call 1f                       \n"
>      "1:  pop  %ebx                     \n"
> -    "    mov  %eax,alloc-1b(%ebx)      \n"
> +    "    mov  %ecx,alloc-1b(%ebx)      \n"
>      "    jmp  reloc                    \n"
>      );
>  
> @@ -31,7 +38,16 @@ asm (
>      );
>  
>  typedef unsigned int u32;
> +typedef unsigned long long u64;
> +
> +#include "../../../include/xen/compiler.h"
>  #include "../../../include/xen/multiboot.h"
> +#include "../../../include/xen/multiboot2.h"
> +
> +#define ALIGN_UP(addr, align) \
> +                (((addr) + (typeof(addr))(align) - 1) & ~((typeof(addr))(align) - 1))
> +
> +#define get_mb2_data(tag, type, member) (((type *)(tag))->member)
>  
>  static u32 alloc_struct(u32 bytes)
>  {
> @@ -49,6 +65,11 @@ static u32 alloc_struct(u32 bytes)
>      return s;
>  }
>  
> +static void zero_struct(u32 s, u32 bytes)
> +{
> +    asm volatile("rep stosb" : "+D" (s), "+c" (bytes) : "a" (0) : "memory");
> +}
> +
>  static u32 copy_struct(u32 src, u32 bytes)
>  {
>      u32 dst, dst_asm;
> @@ -74,40 +95,153 @@ static u32 copy_string(u32 src)
>      return copy_struct(src, p - (char *)src + 1);
>  }
>  
> -multiboot_info_t *reloc(multiboot_info_t *mbi_old)
> +static multiboot_info_t *mbi_mbi(void *mbi_in)
>  {
> -    multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, sizeof(*mbi));
>      int i;
> +    multiboot_info_t *mbi_out;
>  
> -    if ( mbi->flags & MBI_CMDLINE )
> -        mbi->cmdline = copy_string(mbi->cmdline);
> +    mbi_out = (multiboot_info_t *)copy_struct((u32)mbi_in, sizeof(*mbi_out));
>  
> -    if ( mbi->flags & MBI_MODULES )
> +    if ( mbi_out->flags & MBI_CMDLINE )
> +        mbi_out->cmdline = copy_string(mbi_out->cmdline);
> +
> +    if ( mbi_out->flags & MBI_MODULES )
>      {
>          module_t *mods = (module_t *)copy_struct(
> -            mbi->mods_addr, mbi->mods_count * sizeof(module_t));
> +            mbi_out->mods_addr, mbi_out->mods_count * sizeof(module_t));
>  
> -        mbi->mods_addr = (u32)mods;
> +        mbi_out->mods_addr = (u32)mods;
>  
> -        for ( i = 0; i < mbi->mods_count; i++ )
> +        for ( i = 0; i < mbi_out->mods_count; i++ )
>          {
>              if ( mods[i].string )
>                  mods[i].string = copy_string(mods[i].string);
>          }
>      }
>  
> -    if ( mbi->flags & MBI_MEMMAP )
> -        mbi->mmap_addr = copy_struct(mbi->mmap_addr, mbi->mmap_length);
> +    if ( mbi_out->flags & MBI_MEMMAP )
> +        mbi_out->mmap_addr = copy_struct(mbi_out->mmap_addr, mbi_out->mmap_length);
>  
> -    if ( mbi->flags & MBI_LOADERNAME )
> -        mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
> +    if ( mbi_out->flags & MBI_LOADERNAME )
> +        mbi_out->boot_loader_name = copy_string(mbi_out->boot_loader_name);
>  
>      /* Mask features we don't understand or don't relocate. */
> -    mbi->flags &= (MBI_MEMLIMITS |
> -                   MBI_CMDLINE |
> -                   MBI_MODULES |
> -                   MBI_MEMMAP |
> -                   MBI_LOADERNAME);
> +    mbi_out->flags &= (MBI_MEMLIMITS |
> +                       MBI_CMDLINE |
> +                       MBI_MODULES |
> +                       MBI_MEMMAP |
> +                       MBI_LOADERNAME);
>  
> -    return mbi;
> +    return mbi_out;
> +}
> +
> +static multiboot_info_t *mbi2_mbi(void *mbi_in)
> +{
> +    module_t *mbi_out_mods;
> +    memory_map_t *mmap_dst;
> +    multiboot2_memory_map_t *mmap_src;
> +    multiboot2_tag_t *tag;
> +    multiboot_info_t *mbi_out;
> +    u32 ptr;
> +    unsigned int i, mod_idx = 0;
> +
> +    mbi_out = (multiboot_info_t *)alloc_struct(sizeof(*mbi_out));
> +    zero_struct((u32)mbi_out, sizeof(*mbi_out));
> +
> +    /* Skip Multiboot2 information fixed part. */
> +    tag = mbi_in + sizeof(multiboot2_fixed_t);
> +
> +    for ( ; ; )
> +    {
> +        if ( tag->type == MULTIBOOT2_TAG_TYPE_MODULE )
> +            ++mbi_out->mods_count;
> +        else if ( tag->type == MULTIBOOT2_TAG_TYPE_END )
> +        {
> +            mbi_out->flags = MBI_MODULES;
> +            mbi_out->mods_addr = alloc_struct(mbi_out->mods_count * sizeof(module_t));
> +            mbi_out_mods = (module_t *)mbi_out->mods_addr;
> +            break;
> +        }
> +
> +        /* Go to next Multiboot2 information tag. */
> +        tag = (multiboot2_tag_t *)(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN));
> +    }
> +
> +    /* Skip Multiboot2 information fixed part. */
> +    tag = mbi_in + sizeof(multiboot2_fixed_t);
> +
> +    for ( ; ; )
> +    {
> +        switch ( tag->type )
> +        {
> +        case MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME:
> +            mbi_out->flags |= MBI_LOADERNAME;
> +            ptr = (u32)get_mb2_data(tag, multiboot2_tag_string_t, string);
> +            mbi_out->boot_loader_name = copy_string(ptr);
> +            break;
> +
> +        case MULTIBOOT2_TAG_TYPE_CMDLINE:
> +            mbi_out->flags |= MBI_CMDLINE;
> +            ptr = (u32)get_mb2_data(tag, multiboot2_tag_string_t, string);
> +            mbi_out->cmdline = copy_string(ptr);
> +            break;
> +
> +        case MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO:
> +            mbi_out->flags |= MBI_MEMLIMITS;
> +            mbi_out->mem_lower = get_mb2_data(tag, multiboot2_tag_basic_meminfo_t, mem_lower);
> +            mbi_out->mem_upper = get_mb2_data(tag, multiboot2_tag_basic_meminfo_t, mem_upper);
> +            break;
> +
> +        case MULTIBOOT2_TAG_TYPE_MMAP:
> +            mbi_out->flags |= MBI_MEMMAP;
> +            mbi_out->mmap_length = get_mb2_data(tag, multiboot2_tag_mmap_t, size);
> +            mbi_out->mmap_length -= sizeof(multiboot2_tag_mmap_t);
> +            mbi_out->mmap_length += sizeof(((multiboot2_tag_mmap_t){0}).entries);
> +            mbi_out->mmap_length /= get_mb2_data(tag, multiboot2_tag_mmap_t, entry_size);
> +            mbi_out->mmap_length *= sizeof(memory_map_t);
> +
> +            mbi_out->mmap_addr = alloc_struct(mbi_out->mmap_length);
> +
> +            mmap_src = get_mb2_data(tag, multiboot2_tag_mmap_t, entries);
> +            mmap_dst = (memory_map_t *)mbi_out->mmap_addr;
> +
> +            for ( i = 0; i < mbi_out->mmap_length / sizeof(memory_map_t); ++i )
> +            {
> +                mmap_dst[i].size = sizeof(memory_map_t);
> +                mmap_dst[i].size -= sizeof(((memory_map_t){0}).size);
> +                mmap_dst[i].base_addr_low = (u32)mmap_src[i].addr;
> +                mmap_dst[i].base_addr_high = (u32)(mmap_src[i].addr >> 32);
> +                mmap_dst[i].length_low = (u32)mmap_src[i].len;
> +                mmap_dst[i].length_high = (u32)(mmap_src[i].len >> 32);
> +                mmap_dst[i].type = mmap_src[i].type;
> +            }
> +            break;
> +
> +        case MULTIBOOT2_TAG_TYPE_MODULE:
> +            mbi_out_mods[mod_idx].mod_start = get_mb2_data(tag, multiboot2_tag_module_t, mod_start);
> +            mbi_out_mods[mod_idx].mod_end = get_mb2_data(tag, multiboot2_tag_module_t, mod_end);
> +            ptr = (u32)get_mb2_data(tag, multiboot2_tag_module_t, cmdline);
> +            mbi_out_mods[mod_idx].string = copy_string(ptr);
> +            mbi_out_mods[mod_idx].reserved = 0;
> +            ++mod_idx;
> +            break;
> +
> +        case MULTIBOOT2_TAG_TYPE_END:
> +            return mbi_out;
> +
> +        default:
> +            break;
> +        }
> +
> +        /* Go to next Multiboot2 information tag. */
> +        tag = (multiboot2_tag_t *)(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN));
> +    }
> +}
> +
> +static multiboot_info_t __used *reloc(void *mbi_in, u32 mb_magic)
> +{
> +    if ( mb_magic == MULTIBOOT2_BOOTLOADER_MAGIC )
> +        return mbi2_mbi(mbi_in);
> +    else
> +        return mbi_mbi(mbi_in);
>  }
> diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
> index 447c650..ca3712f 100644
> --- a/xen/arch/x86/x86_64/asm-offsets.c
> +++ b/xen/arch/x86/x86_64/asm-offsets.c
> @@ -13,6 +13,7 @@
>  #include <asm/fixmap.h>
>  #include <asm/hardirq.h>
>  #include <xen/multiboot.h>
> +#include <xen/multiboot2.h>
>  
>  #define DEFINE(_sym, _val)                                                 \
>      asm volatile ("\n.ascii\"==>#define " #_sym " %0 /* " #_val " */<==\"" \
> @@ -166,4 +167,9 @@ void __dummy__(void)
>      OFFSET(MB_flags, multiboot_info_t, flags);
>      OFFSET(MB_cmdline, multiboot_info_t, cmdline);
>      OFFSET(MB_mem_lower, multiboot_info_t, mem_lower);
> +    BLANK();
> +
> +    DEFINE(MB2_fixed_sizeof, sizeof(multiboot2_fixed_t));
> +    OFFSET(MB2_tag_size, multiboot2_tag_t, size);
> +    OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
>  }
> diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
> new file mode 100644
> index 0000000..09ee64e
> --- /dev/null
> +++ b/xen/include/xen/multiboot2.h
> @@ -0,0 +1,169 @@
> +/*
> + *  Copyright (C) 1999,2003,2007,2008,2009,2010  Free Software Foundation, Inc.
> + *
> + *  multiboot2.h - Multiboot 2 header file.
> + *
> + *  Based on grub-2.00/include/multiboot2.h file.
> + *
> + *  Permission is hereby granted, free of charge, to any person obtaining a copy
> + *  of this software and associated documentation files (the "Software"), to
> + *  deal in the Software without restriction, including without limitation the
> + *  rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + *  sell copies of the Software, and to permit persons to whom the Software is
> + *  furnished to do so, subject to the following conditions:
> + *
> + *  The above copyright notice and this permission notice shall be included in
> + *  all copies or substantial portions of the Software.
> + *
> + *  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + *  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + *  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL ANY
> + *  DEVELOPER OR DISTRIBUTOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *  WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR
> + *  IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef __MULTIBOOT2_H__
> +#define __MULTIBOOT2_H__
> +
> +/* The magic field should contain this.  */
> +#define MULTIBOOT2_HEADER_MAGIC			0xe85250d6
> +
> +/* This should be in %eax on x86 architecture.  */
> +#define MULTIBOOT2_BOOTLOADER_MAGIC		0x36d76289
> +
> +/* How many bytes from the start of the file we search for the header.  */
> +#define MULTIBOOT2_SEARCH			32768
> +
> +/* Multiboot 2 header alignment. */
> +#define MULTIBOOT2_HEADER_ALIGN			8
> +
> +/* Alignment of multiboot 2 modules.  */
> +#define MULTIBOOT2_MOD_ALIGN			0x00001000
> +
> +/* Alignment of the multiboot 2 info structure.  */
> +#define MULTIBOOT2_INFO_ALIGN			0x00000008
> +
> +/* Multiboot 2 architectures. */
> +#define MULTIBOOT2_ARCHITECTURE_I386	0
> +#define MULTIBOOT2_ARCHITECTURE_MIPS32	4
> +
> +/* Header tag types. */
> +#define MULTIBOOT2_HEADER_TAG_END			0
> +#define MULTIBOOT2_HEADER_TAG_INFORMATION_REQUEST	1
> +#define MULTIBOOT2_HEADER_TAG_ADDRESS			2
> +#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS		3
> +#define MULTIBOOT2_HEADER_TAG_CONSOLE_FLAGS		4
> +#define MULTIBOOT2_HEADER_TAG_FRAMEBUFFER		5
> +#define MULTIBOOT2_HEADER_TAG_MODULE_ALIGN		6
> +#define MULTIBOOT2_HEADER_TAG_EFI_BS			7
> +#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32	8
> +#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64	9
> +
> +/* Header tag flags. */
> +#define MULTIBOOT2_HEADER_TAG_REQUIRED	0
> +#define MULTIBOOT2_HEADER_TAG_OPTIONAL	1
> +
> +/* Header console tag console_flags. */
> +#define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED	1
> +#define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED	2
> +
> +/* Flags set in the 'flags' member of the multiboot header.  */
> +#define MULTIBOOT2_TAG_TYPE_END			0
> +#define MULTIBOOT2_TAG_TYPE_CMDLINE		1
> +#define MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME	2
> +#define MULTIBOOT2_TAG_TYPE_MODULE		3
> +#define MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO	4
> +#define MULTIBOOT2_TAG_TYPE_BOOTDEV		5
> +#define MULTIBOOT2_TAG_TYPE_MMAP		6
> +#define MULTIBOOT2_TAG_TYPE_VBE			7
> +#define MULTIBOOT2_TAG_TYPE_FRAMEBUFFER		8
> +#define MULTIBOOT2_TAG_TYPE_ELF_SECTIONS	9
> +#define MULTIBOOT2_TAG_TYPE_APM			10
> +#define MULTIBOOT2_TAG_TYPE_EFI32		11
> +#define MULTIBOOT2_TAG_TYPE_EFI64		12
> +#define MULTIBOOT2_TAG_TYPE_SMBIOS		13
> +#define MULTIBOOT2_TAG_TYPE_ACPI_OLD		14
> +#define MULTIBOOT2_TAG_TYPE_ACPI_NEW		15
> +#define MULTIBOOT2_TAG_TYPE_NETWORK		16
> +#define MULTIBOOT2_TAG_TYPE_EFI_MMAP		17
> +#define MULTIBOOT2_TAG_TYPE_EFI_BS		18
> +#define MULTIBOOT2_TAG_TYPE_EFI32_IH		19
> +#define MULTIBOOT2_TAG_TYPE_EFI64_IH		20
> +
> +/* Multiboot 2 tag alignment. */
> +#define MULTIBOOT2_TAG_ALIGN			8
> +
> +/* Memory types. */
> +#define MULTIBOOT2_MEMORY_AVAILABLE		1
> +#define MULTIBOOT2_MEMORY_RESERVED		2
> +#define MULTIBOOT2_MEMORY_ACPI_RECLAIMABLE	3
> +#define MULTIBOOT2_MEMORY_NVS			4
> +#define MULTIBOOT2_MEMORY_BADRAM		5
> +
> +/* Framebuffer types. */
> +#define MULTIBOOT2_FRAMEBUFFER_TYPE_INDEXED	0
> +#define MULTIBOOT2_FRAMEBUFFER_TYPE_RGB		1
> +#define MULTIBOOT2_FRAMEBUFFER_TYPE_EGA_TEXT	2
> +
> +#ifndef __ASSEMBLY__
> +typedef struct {
> +    u32 total_size;
> +    u32 reserved;
> +} multiboot2_fixed_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +} multiboot2_tag_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +    char string[0];
> +} multiboot2_tag_string_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +    u32 mem_lower;
> +    u32 mem_upper;
> +} multiboot2_tag_basic_meminfo_t;
> +
> +typedef struct __packed {
> +    u64 addr;
> +    u64 len;
> +    u32 type;
> +    u32 zero;
> +} multiboot2_memory_map_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +    u32 entry_size;
> +    u32 entry_version;
> +    multiboot2_memory_map_t entries[0];
> +} multiboot2_tag_mmap_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +    u64 pointer;
> +} multiboot2_tag_efi64_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +    u64 pointer;
> +} multiboot2_tag_efi64_ih_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +    u32 mod_start;
> +    u32 mod_end;
> +    char cmdline[0];
> +} multiboot2_tag_module_t;
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* __MULTIBOOT2_H__ */

Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -1,6 +1,7 @@
>  obj-bin-y += head.o
>  
> -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h
> +RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/compiler.h \
> +	     $(BASEDIR)/include/xen/multiboot.h $(BASEDIR)/include/xen/multiboot2.h

Perhaps we should rather have the compiler generate the
dependencies for us when compiling reloc.o?

> @@ -32,6 +33,59 @@ ENTRY(start)
>          .long   MULTIBOOT_HEADER_FLAGS
>          /* Checksum: must be the negated sum of the first two fields. */
>          .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
> + 
> +/*** MULTIBOOT2 HEADER ****/
> +/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S file. */
> +        .align  MULTIBOOT2_HEADER_ALIGN
> +
> +.Lmultiboot2_header:
> +        /* Magic number indicating a Multiboot2 header. */
> +        .long   MULTIBOOT2_HEADER_MAGIC
> +        /* Architecture: i386. */
> +        .long   MULTIBOOT2_ARCHITECTURE_I386
> +        /* Multiboot2 header length. */
> +        .long   .Lmultiboot2_header_end - .Lmultiboot2_header
> +        /* Multiboot2 header checksum. */
> +        .long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
> +                        (.Lmultiboot2_header_end - .Lmultiboot2_header))

So here ...

> +        /* Multiboot2 tags... */
> +.Lmultiboot2_info_req:
> +        /* Multiboot2 information request tag. */
> +        .short  MULTIBOOT2_HEADER_TAG_INFORMATION_REQUEST
> +        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
> +        .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req

.. and here you properly calculate the length, while ...

> +        .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
> +        .long   MULTIBOOT2_TAG_TYPE_MMAP
> +.Lmultiboot2_info_req_end:
> +
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_MODULE_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
> +        .long   8 /* Tag size. */

... here and further down you hard-code it. Please be consistent
(and if you go the calculation route, perhaps introduce some
redundancy reducing macro).

> +
> +        /* Console flags tag. */
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_CONSOLE_FLAGS
> +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> +        .long   12 /* Tag size. */
> +        .long   MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
> +
> +        /* Framebuffer tag. */
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_FRAMEBUFFER
> +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> +        .long   20 /* Tag size. */
> +        .long   0 /* Number of the columns - no preference. */
> +        .long   0 /* Number of the lines - no preference. */
> +        .long   0 /* Number of bits per pixel - no preference. */
> +
> +        /* Multiboot2 header end tag. */
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_END
> +        .short  0
> +        .long   8 /* Tag size. */
> +.Lmultiboot2_header_end:
>  
>          .section .init.rodata, "a", @progbits
>          .align 4
> @@ -81,10 +135,51 @@ __start:
>          mov     %ecx,%es
>          mov     %ecx,%ss
>  
> +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */

Above you meet coding style requirements, but here you stop to do
so (ongoing below)? Even if pre-existing neighboring comments aren't
well formed, please don't make the situation worse.

Also please don't say 12 here - I first even mistook this as an array
index, but you seem to mean 1 or 2. Please use {1,2} instead.

> +        xor     %edx,%edx
> +
>          /* Check for Multiboot bootloader */
>          cmp     $MULTIBOOT_BOOTLOADER_MAGIC,%eax
> -        jne     not_multiboot
> +        je      multiboot1_proto
>  
> +        /* Check for Multiboot2 bootloader */
> +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> +        je      multiboot2_proto
> +
> +        jmp     not_multiboot
> +
> +multiboot1_proto:
> +        /* Get mem_lower from Multiboot information */
> +        testb   $MBI_MEMLIMITS,(%ebx)

MB_flags(%ebx)

> +        jz      trampoline_setup    /* not available? BDA value will be fine */
> +
> +        mov     MB_mem_lower(%ebx),%edx

Please use "cmovnz" or "or" instead of "jz" and "mov".

> +        jmp     trampoline_setup
> +
> +multiboot2_proto:
> +        /* Skip Multiboot2 information fixed part */
> +        lea     MB2_fixed_sizeof(%ebx),%ecx
> +
> +0:
> +        /* Get mem_lower from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> +        jne     1f
> +
> +        mov     MB2_mem_lower(%ecx),%edx
> +        jmp     trampoline_setup
> +
> +1:
> +        /* Is it the end of Multiboot2 information? */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)

This lacks the use a suitable MB2_* definition (even if that ends up
being zero).

> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -5,19 +5,26 @@
>   * and modules. This is most easily done early with paging disabled.
>   *
>   * Copyright (c) 2009, Citrix Systems, Inc.
> + * Copyright (c) 2013, 2014, 2015 Oracle Corp.
>   *
>   * Authors:
>   *    Keir Fraser <keir@xen.org>
> + *    Daniel Kiper

If you add yourself here, then please (following the existing example)
with email address.

> -/* entered with %eax = BOOT_TRAMPOLINE */
> +/*
> + * This entry point is entered from xen/arch/x86/boot/head.S with:
> + *   - %eax = MULTIBOOT_MAGIC,
> + *   - %ebx = MULTIBOOT_INFORMATION_ADDRESS,
> + *   - %ecx = BOOT_TRAMPOLINE.

Then why do you push %eax and %ebx above?

> @@ -31,7 +38,16 @@ asm (
>      );
>  
>  typedef unsigned int u32;
> +typedef unsigned long long u64;
> +
> +#include "../../../include/xen/compiler.h"

Why?

> @@ -74,40 +95,153 @@ static u32 copy_string(u32 src)
>      return copy_struct(src, p - (char *)src + 1);
>  }
>  
> -multiboot_info_t *reloc(multiboot_info_t *mbi_old)
> +static multiboot_info_t *mbi_mbi(void *mbi_in)
>  {
> -    multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, sizeof(*mbi));
>      int i;
> +    multiboot_info_t *mbi_out;
>  
> -    if ( mbi->flags & MBI_CMDLINE )
> -        mbi->cmdline = copy_string(mbi->cmdline);
> +    mbi_out = (multiboot_info_t *)copy_struct((u32)mbi_in, sizeof(*mbi_out));

Why can this not remain the initializer of the variable? Also the
unrelated renaming mbi -> mbi_out and mbi_old ->mbi_in only makes
reading the patch more cumbersome. If you absolutely feel like you
need to rename them, do this in a separate patch.

> +static multiboot_info_t *mbi2_mbi(void *mbi_in)
> +{
> +    module_t *mbi_out_mods;
> +    memory_map_t *mmap_dst;
> +    multiboot2_memory_map_t *mmap_src;
> +    multiboot2_tag_t *tag;
> +    multiboot_info_t *mbi_out;
> +    u32 ptr;
> +    unsigned int i, mod_idx = 0;
> +
> +    mbi_out = (multiboot_info_t *)alloc_struct(sizeof(*mbi_out));
> +    zero_struct((u32)mbi_out, sizeof(*mbi_out));
> +
> +    /* Skip Multiboot2 information fixed part. */
> +    tag = mbi_in + sizeof(multiboot2_fixed_t);
> +
> +    for ( ; ; )
> +    {
> +        if ( tag->type == MULTIBOOT2_TAG_TYPE_MODULE )
> +            ++mbi_out->mods_count;
> +        else if ( tag->type == MULTIBOOT2_TAG_TYPE_END )
> +        {
> +            mbi_out->flags = MBI_MODULES;
> +            mbi_out->mods_addr = alloc_struct(mbi_out->mods_count * sizeof(module_t));
> +            mbi_out_mods = (module_t *)mbi_out->mods_addr;
> +            break;
> +        }
> +
> +        /* Go to next Multiboot2 information tag. */
> +        tag = (multiboot2_tag_t *)(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN));
> +    }

Shouldn't you also break out of the loop when mbi_in->total_size
gets exceeded?

> +#ifndef __ASSEMBLY__
> +typedef struct {
> +    u32 total_size;
> +    u32 reserved;
> +} multiboot2_fixed_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +} multiboot2_tag_t;
> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +    char string[0];
> +} multiboot2_tag_string_t;

Are these _tag_ parts of the name really needed?

> +
> +typedef struct {
> +    u32 type;
> +    u32 size;
> +    u32 mem_lower;
> +    u32 mem_upper;
> +} multiboot2_tag_basic_meminfo_t;
> +
> +typedef struct __packed {

Why __packed when all the others aren't?

Jan

Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support

[Daniel Kiper]

On Fri, Feb 20, 2015 at 04:06:26PM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> > --- a/xen/arch/x86/boot/Makefile
> > +++ b/xen/arch/x86/boot/Makefile
> > @@ -1,6 +1,7 @@
> >  obj-bin-y += head.o
> >
> > -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h
> > +RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/compiler.h \
> > +	     $(BASEDIR)/include/xen/multiboot.h $(BASEDIR)/include/xen/multiboot2.h
>
> Perhaps we should rather have the compiler generate the
> dependencies for us when compiling reloc.o?

Hmmm... I am a bit confused. Here http://lists.xen.org/archives/html/xen-devel/2014-10/msg02094.html
you told a bit different thing and relevant patch was accepted as commit c42070df66c9fcedf477959b8371b85aa4ac4933
(x86/boot: fix reloc.S build dependencies). I can try to do what you suggest, this is not a problem
for me, however, I would like to be sure what is your final decision in that case.

> > @@ -32,6 +33,59 @@ ENTRY(start)
> >          .long   MULTIBOOT_HEADER_FLAGS
> >          /* Checksum: must be the negated sum of the first two fields. */
> >          .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
> > +
> > +/*** MULTIBOOT2 HEADER ****/
> > +/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S file. */
> > +        .align  MULTIBOOT2_HEADER_ALIGN
> > +
> > +.Lmultiboot2_header:
> > +        /* Magic number indicating a Multiboot2 header. */
> > +        .long   MULTIBOOT2_HEADER_MAGIC
> > +        /* Architecture: i386. */
> > +        .long   MULTIBOOT2_ARCHITECTURE_I386
> > +        /* Multiboot2 header length. */
> > +        .long   .Lmultiboot2_header_end - .Lmultiboot2_header
> > +        /* Multiboot2 header checksum. */
> > +        .long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
> > +                        (.Lmultiboot2_header_end - .Lmultiboot2_header))
>
> So here ...
>
> > +        /* Multiboot2 tags... */
> > +.Lmultiboot2_info_req:
> > +        /* Multiboot2 information request tag. */
> > +        .short  MULTIBOOT2_HEADER_TAG_INFORMATION_REQUEST
> > +        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
> > +        .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
>
> .. and here you properly calculate the length, while ...
>
> > +        .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
> > +        .long   MULTIBOOT2_TAG_TYPE_MMAP
> > +.Lmultiboot2_info_req_end:
> > +
> > +        .align  MULTIBOOT2_TAG_ALIGN
> > +        .short  MULTIBOOT2_HEADER_TAG_MODULE_ALIGN
> > +        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
> > +        .long   8 /* Tag size. */
>
> ... here and further down you hard-code it. Please be consistent
> (and if you go the calculation route, perhaps introduce some
> redundancy reducing macro).

I did this deliberately. I calculate size using labels when it is really
needed, e.g. in tags which size depends on number of elements. However,
most tags have strictly defined sizes. So, that is why I dropped labels
and entered simple numbers. Though I agree that it can be improved.
I think that we can define relevant tag structures in multiboot2.h and
generate relevant constants using asm-offsets.c. Is it OK for you?

> > +        /* Console flags tag. */
> > +        .align  MULTIBOOT2_TAG_ALIGN
> > +        .short  MULTIBOOT2_HEADER_TAG_CONSOLE_FLAGS
> > +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> > +        .long   12 /* Tag size. */
> > +        .long   MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
> > +
> > +        /* Framebuffer tag. */
> > +        .align  MULTIBOOT2_TAG_ALIGN
> > +        .short  MULTIBOOT2_HEADER_TAG_FRAMEBUFFER
> > +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> > +        .long   20 /* Tag size. */
> > +        .long   0 /* Number of the columns - no preference. */
> > +        .long   0 /* Number of the lines - no preference. */
> > +        .long   0 /* Number of bits per pixel - no preference. */
> > +
> > +        /* Multiboot2 header end tag. */
> > +        .align  MULTIBOOT2_TAG_ALIGN
> > +        .short  MULTIBOOT2_HEADER_TAG_END
> > +        .short  0
> > +        .long   8 /* Tag size. */
> > +.Lmultiboot2_header_end:
> >
> >          .section .init.rodata, "a", @progbits
> >          .align 4
> > @@ -81,10 +135,51 @@ __start:
> >          mov     %ecx,%es
> >          mov     %ecx,%ss
> >
> > +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
>
> Above you meet coding style requirements, but here you stop to do
> so (ongoing below)? Even if pre-existing neighboring comments aren't
> well formed, please don't make the situation worse.

Do you ask about ending fullstops? Am I right?

> Also please don't say 12 here - I first even mistook this as an array
> index, but you seem to mean 1 or 2. Please use {1,2} instead.

OK.

> > +        xor     %edx,%edx
> > +
> >          /* Check for Multiboot bootloader */
> >          cmp     $MULTIBOOT_BOOTLOADER_MAGIC,%eax
> > -        jne     not_multiboot
> > +        je      multiboot1_proto
> >
> > +        /* Check for Multiboot2 bootloader */
> > +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> > +        je      multiboot2_proto
> > +
> > +        jmp     not_multiboot
> > +
> > +multiboot1_proto:
> > +        /* Get mem_lower from Multiboot information */
> > +        testb   $MBI_MEMLIMITS,(%ebx)
>
> MB_flags(%ebx)
>
> > +        jz      trampoline_setup    /* not available? BDA value will be fine */
> > +
> > +        mov     MB_mem_lower(%ebx),%edx
>
> Please use "cmovnz" or "or" instead of "jz" and "mov".
>
> > +        jmp     trampoline_setup
> > +
> > +multiboot2_proto:
> > +        /* Skip Multiboot2 information fixed part */
> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
> > +
> > +0:
> > +        /* Get mem_lower from Multiboot2 information */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> > +        jne     1f
> > +
> > +        mov     MB2_mem_lower(%ecx),%edx
> > +        jmp     trampoline_setup
> > +
> > +1:
> > +        /* Is it the end of Multiboot2 information? */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
>
> This lacks the use a suitable MB2_* definition (even if that ends up
> being zero).
>
> > --- a/xen/arch/x86/boot/reloc.c
> > +++ b/xen/arch/x86/boot/reloc.c
> > @@ -5,19 +5,26 @@
> >   * and modules. This is most easily done early with paging disabled.
> >   *
> >   * Copyright (c) 2009, Citrix Systems, Inc.
> > + * Copyright (c) 2013, 2014, 2015 Oracle Corp.
> >   *
> >   * Authors:
> >   *    Keir Fraser <keir@xen.org>
> > + *    Daniel Kiper
>
> If you add yourself here, then please (following the existing example)
> with email address.
>
> > -/* entered with %eax = BOOT_TRAMPOLINE */
> > +/*
> > + * This entry point is entered from xen/arch/x86/boot/head.S with:
> > + *   - %eax = MULTIBOOT_MAGIC,
> > + *   - %ebx = MULTIBOOT_INFORMATION_ADDRESS,
> > + *   - %ecx = BOOT_TRAMPOLINE.
>
> Then why do you push %eax and %ebx above?
>
> > @@ -31,7 +38,16 @@ asm (
> >      );
> >
> >  typedef unsigned int u32;
> > +typedef unsigned long long u64;
> > +
> > +#include "../../../include/xen/compiler.h"
>
> Why?

static multiboot_info_t __used *reloc(void *mbi_in, u32 mb_magic)
Because of this ------> ^^^^^^

> > @@ -74,40 +95,153 @@ static u32 copy_string(u32 src)
> >      return copy_struct(src, p - (char *)src + 1);
> >  }
> >
> > -multiboot_info_t *reloc(multiboot_info_t *mbi_old)
> > +static multiboot_info_t *mbi_mbi(void *mbi_in)
> >  {
> > -    multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, sizeof(*mbi));
> >      int i;
> > +    multiboot_info_t *mbi_out;
> >
> > -    if ( mbi->flags & MBI_CMDLINE )
> > -        mbi->cmdline = copy_string(mbi->cmdline);
> > +    mbi_out = (multiboot_info_t *)copy_struct((u32)mbi_in, sizeof(*mbi_out));
>
> Why can this not remain the initializer of the variable? Also the
> unrelated renaming mbi -> mbi_out and mbi_old ->mbi_in only makes
> reading the patch more cumbersome. If you absolutely feel like you
> need to rename them, do this in a separate patch.
>
> > +static multiboot_info_t *mbi2_mbi(void *mbi_in)
> > +{
> > +    module_t *mbi_out_mods;
> > +    memory_map_t *mmap_dst;
> > +    multiboot2_memory_map_t *mmap_src;
> > +    multiboot2_tag_t *tag;
> > +    multiboot_info_t *mbi_out;
> > +    u32 ptr;
> > +    unsigned int i, mod_idx = 0;
> > +
> > +    mbi_out = (multiboot_info_t *)alloc_struct(sizeof(*mbi_out));
> > +    zero_struct((u32)mbi_out, sizeof(*mbi_out));
> > +
> > +    /* Skip Multiboot2 information fixed part. */
> > +    tag = mbi_in + sizeof(multiboot2_fixed_t);
> > +
> > +    for ( ; ; )
> > +    {
> > +        if ( tag->type == MULTIBOOT2_TAG_TYPE_MODULE )
> > +            ++mbi_out->mods_count;
> > +        else if ( tag->type == MULTIBOOT2_TAG_TYPE_END )
> > +        {
> > +            mbi_out->flags = MBI_MODULES;
> > +            mbi_out->mods_addr = alloc_struct(mbi_out->mods_count * sizeof(module_t));
> > +            mbi_out_mods = (module_t *)mbi_out->mods_addr;
> > +            break;
> > +        }
> > +
> > +        /* Go to next Multiboot2 information tag. */
> > +        tag = (multiboot2_tag_t *)(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN));
> > +    }
>
> Shouldn't you also break out of the loop when mbi_in->total_size
> gets exceeded?

Tag MULTIBOOT2_TAG_TYPE_END is always added as the end marker
but we can check also mbi_in->total_size just in case.

> > +#ifndef __ASSEMBLY__
> > +typedef struct {
> > +    u32 total_size;
> > +    u32 reserved;
> > +} multiboot2_fixed_t;
> > +
> > +typedef struct {
> > +    u32 type;
> > +    u32 size;
> > +} multiboot2_tag_t;
> > +
> > +typedef struct {
> > +    u32 type;
> > +    u32 size;
> > +    char string[0];
> > +} multiboot2_tag_string_t;
>
> Are these _tag_ parts of the name really needed?

This is not a must but I tried to mimic things in GRUB2 as much as possible.

> > +
> > +typedef struct {
> > +    u32 type;
> > +    u32 size;
> > +    u32 mem_lower;
> > +    u32 mem_upper;
> > +} multiboot2_tag_basic_meminfo_t;
> > +
> > +typedef struct __packed {
>
> Why __packed when all the others aren't?

Ha! This thing was taken from GRUB2 source.
I was asking this question myself many times.
I have not found real explanation for this
but if you wish I can dive into code and
try to find one (if it exists).

Daniel

Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support

[Jan Beulich]

>>> On 27.03.15 at 11:56, <daniel.kiper@oracle.com> wrote:
> On Fri, Feb 20, 2015 at 04:06:26PM +0000, Jan Beulich wrote:
>> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> > --- a/xen/arch/x86/boot/Makefile
>> > +++ b/xen/arch/x86/boot/Makefile
>> > @@ -1,6 +1,7 @@
>> >  obj-bin-y += head.o
>> >
>> > -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h
>> > +RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/compiler.h \
>> > +	     $(BASEDIR)/include/xen/multiboot.h $(BASEDIR)/include/xen/multiboot2.h
>>
>> Perhaps we should rather have the compiler generate the
>> dependencies for us when compiling reloc.o?
> 
> Hmmm... I am a bit confused. Here 
> http://lists.xen.org/archives/html/xen-devel/2014-10/msg02094.html 
> you told a bit different thing and relevant patch was accepted as commit 
> c42070df66c9fcedf477959b8371b85aa4ac4933
> (x86/boot: fix reloc.S build dependencies). I can try to do what you 
> suggest, this is not a problem
> for me, however, I would like to be sure what is your final decision in that 
> case.

First of all I wasn't anticipating that this list of dependencies would
further grow. And then I didn't say "don't do this", I only pointed
out (albeit maybe a little too implicitly) that this would be a more
complex patch.

>> > +        .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
>> > +        .long   MULTIBOOT2_TAG_TYPE_MMAP
>> > +.Lmultiboot2_info_req_end:
>> > +
>> > +        .align  MULTIBOOT2_TAG_ALIGN
>> > +        .short  MULTIBOOT2_HEADER_TAG_MODULE_ALIGN
>> > +        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
>> > +        .long   8 /* Tag size. */
>>
>> ... here and further down you hard-code it. Please be consistent
>> (and if you go the calculation route, perhaps introduce some
>> redundancy reducing macro).
> 
> I did this deliberately. I calculate size using labels when it is really
> needed, e.g. in tags which size depends on number of elements. However,
> most tags have strictly defined sizes. So, that is why I dropped labels
> and entered simple numbers. Though I agree that it can be improved.
> I think that we can define relevant tag structures in multiboot2.h and
> generate relevant constants using asm-offsets.c. Is it OK for you?

That would mean exposing stuff to other parts of the tree which
doesn't need to be exposed. I don't see why you can't just do
proper size calculations here.

>> > @@ -81,10 +135,51 @@ __start:
>> >          mov     %ecx,%es
>> >          mov     %ecx,%ss
>> >
>> > +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
>>
>> Above you meet coding style requirements, but here you stop to do
>> so (ongoing below)? Even if pre-existing neighboring comments aren't
>> well formed, please don't make the situation worse.
> 
> Do you ask about ending fullstops? Am I right?

Yes.

>> > @@ -31,7 +38,16 @@ asm (
>> >      );
>> >
>> >  typedef unsigned int u32;
>> > +typedef unsigned long long u64;
>> > +
>> > +#include "../../../include/xen/compiler.h"
>>
>> Why?
> 
> static multiboot_info_t __used *reloc(void *mbi_in, u32 mb_magic)
> Because of this ------> ^^^^^^

And what keeps you from leaving out the "static", making the
__used unnecessary?

>> > +
>> > +typedef struct {
>> > +    u32 type;
>> > +    u32 size;
>> > +    u32 mem_lower;
>> > +    u32 mem_upper;
>> > +} multiboot2_tag_basic_meminfo_t;
>> > +
>> > +typedef struct __packed {
>>
>> Why __packed when all the others aren't?
> 
> Ha! This thing was taken from GRUB2 source.
> I was asking this question myself many times.
> I have not found real explanation for this
> but if you wish I can dive into code and
> try to find one (if it exists).

Or even better just drop the __packed.

Jan

Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support

[Daniel Kiper]

On Fri, Mar 27, 2015 at 11:20:10AM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 11:56, <daniel.kiper@oracle.com> wrote:
> > On Fri, Feb 20, 2015 at 04:06:26PM +0000, Jan Beulich wrote:
> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >> > --- a/xen/arch/x86/boot/Makefile
> >> > +++ b/xen/arch/x86/boot/Makefile
> >> > @@ -1,6 +1,7 @@
> >> >  obj-bin-y += head.o
> >> >
> >> > -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h
> >> > +RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/compiler.h \
> >> > +	     $(BASEDIR)/include/xen/multiboot.h $(BASEDIR)/include/xen/multiboot2.h
> >>
> >> Perhaps we should rather have the compiler generate the
> >> dependencies for us when compiling reloc.o?
> >
> > Hmmm... I am a bit confused. Here
> > http://lists.xen.org/archives/html/xen-devel/2014-10/msg02094.html
> > you told a bit different thing and relevant patch was accepted as commit
> > c42070df66c9fcedf477959b8371b85aa4ac4933
> > (x86/boot: fix reloc.S build dependencies). I can try to do what you
> > suggest, this is not a problem
> > for me, however, I would like to be sure what is your final decision in that
> > case.
>
> First of all I wasn't anticipating that this list of dependencies would
> further grow. And then I didn't say "don't do this", I only pointed
> out (albeit maybe a little too implicitly) that this would be a more
> complex patch.

So, I understand this as "Go for it!".

> >> > +        .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
> >> > +        .long   MULTIBOOT2_TAG_TYPE_MMAP
> >> > +.Lmultiboot2_info_req_end:
> >> > +
> >> > +        .align  MULTIBOOT2_TAG_ALIGN
> >> > +        .short  MULTIBOOT2_HEADER_TAG_MODULE_ALIGN
> >> > +        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
> >> > +        .long   8 /* Tag size. */
> >>
> >> ... here and further down you hard-code it. Please be consistent
> >> (and if you go the calculation route, perhaps introduce some
> >> redundancy reducing macro).
> >
> > I did this deliberately. I calculate size using labels when it is really
> > needed, e.g. in tags which size depends on number of elements. However,
> > most tags have strictly defined sizes. So, that is why I dropped labels
> > and entered simple numbers. Though I agree that it can be improved.
> > I think that we can define relevant tag structures in multiboot2.h and
> > generate relevant constants using asm-offsets.c. Is it OK for you?
>
> That would mean exposing stuff to other parts of the tree which
> doesn't need to be exposed. I don't see why you can't just do
> proper size calculations here.

OK, I will do this as you wish.

> >> > @@ -81,10 +135,51 @@ __start:
> >> >          mov     %ecx,%es
> >> >          mov     %ecx,%ss
> >> >
> >> > +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> >>
> >> Above you meet coding style requirements, but here you stop to do
> >> so (ongoing below)? Even if pre-existing neighboring comments aren't
> >> well formed, please don't make the situation worse.
> >
> > Do you ask about ending fullstops? Am I right?
>
> Yes.
>
> >> > @@ -31,7 +38,16 @@ asm (
> >> >      );
> >> >
> >> >  typedef unsigned int u32;
> >> > +typedef unsigned long long u64;
> >> > +
> >> > +#include "../../../include/xen/compiler.h"
> >>
> >> Why?
> >
> > static multiboot_info_t __used *reloc(void *mbi_in, u32 mb_magic)
> > Because of this ------> ^^^^^^
>
> And what keeps you from leaving out the "static", making the
> __used unnecessary?

This func is clearly static. Why do not mark it as is and use __used.
What is wrong with that?

> >> > +
> >> > +typedef struct {
> >> > +    u32 type;
> >> > +    u32 size;
> >> > +    u32 mem_lower;
> >> > +    u32 mem_upper;
> >> > +} multiboot2_tag_basic_meminfo_t;
> >> > +
> >> > +typedef struct __packed {
> >>
> >> Why __packed when all the others aren't?
> >
> > Ha! This thing was taken from GRUB2 source.
> > I was asking this question myself many times.
> > I have not found real explanation for this
> > but if you wish I can dive into code and
> > try to find one (if it exists).
>
> Or even better just drop the __packed.

Should not we be in line with GRUB2 source?
Even it sounds strange. Anyway, I will check
GRUB2 source and maybe we can also remove __packed
from it. This way everything will be OK.

Daniel

Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support

[Jan Beulich]

>>> On 27.03.15 at 13:22, <daniel.kiper@oracle.com> wrote:
> On Fri, Mar 27, 2015 at 11:20:10AM +0000, Jan Beulich wrote:
>> >>> On 27.03.15 at 11:56, <daniel.kiper@oracle.com> wrote:
>> > On Fri, Feb 20, 2015 at 04:06:26PM +0000, Jan Beulich wrote:
>> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> >> > @@ -31,7 +38,16 @@ asm (
>> >> >      );
>> >> >
>> >> >  typedef unsigned int u32;
>> >> > +typedef unsigned long long u64;
>> >> > +
>> >> > +#include "../../../include/xen/compiler.h"
>> >>
>> >> Why?
>> >
>> > static multiboot_info_t __used *reloc(void *mbi_in, u32 mb_magic)
>> > Because of this ------> ^^^^^^
>>
>> And what keeps you from leaving out the "static", making the
>> __used unnecessary?
> 
> This func is clearly static. Why do not mark it as is and use __used.
> What is wrong with that?

#include-s of the above kind generally indicate badness, so we
should try to limit them to the absolute minimum.

>> >> > +
>> >> > +typedef struct {
>> >> > +    u32 type;
>> >> > +    u32 size;
>> >> > +    u32 mem_lower;
>> >> > +    u32 mem_upper;
>> >> > +} multiboot2_tag_basic_meminfo_t;
>> >> > +
>> >> > +typedef struct __packed {
>> >>
>> >> Why __packed when all the others aren't?
>> >
>> > Ha! This thing was taken from GRUB2 source.
>> > I was asking this question myself many times.
>> > I have not found real explanation for this
>> > but if you wish I can dive into code and
>> > try to find one (if it exists).
>>
>> Or even better just drop the __packed.
> 
> Should not we be in line with GRUB2 source?
> Even it sounds strange. Anyway, I will check
> GRUB2 source and maybe we can also remove __packed
> from it. This way everything will be OK.

Now that's the right course of action.

Jan

Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support

[Jan Beulich]

>>> On 27.03.15 at 13:22, <daniel.kiper@oracle.com> wrote:
> On Fri, Mar 27, 2015 at 11:20:10AM +0000, Jan Beulich wrote:
>> >>> On 27.03.15 at 11:56, <daniel.kiper@oracle.com> wrote:
>> > On Fri, Feb 20, 2015 at 04:06:26PM +0000, Jan Beulich wrote:
>> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> >> > @@ -31,7 +38,16 @@ asm (
>> >> >      );
>> >> >
>> >> >  typedef unsigned int u32;
>> >> > +typedef unsigned long long u64;
>> >> > +
>> >> > +#include "../../../include/xen/compiler.h"
>> >>
>> >> Why?
>> >
>> > static multiboot_info_t __used *reloc(void *mbi_in, u32 mb_magic)
>> > Because of this ------> ^^^^^^
>>
>> And what keeps you from leaving out the "static", making the
>> __used unnecessary?
> 
> This func is clearly static. Why do not mark it as is and use __used.
> What is wrong with that?

#include-s of the above kind generally indicate badness, so we
should try to limit them to the absolute minimum.

>> >> > +
>> >> > +typedef struct {
>> >> > +    u32 type;
>> >> > +    u32 size;
>> >> > +    u32 mem_lower;
>> >> > +    u32 mem_upper;
>> >> > +} multiboot2_tag_basic_meminfo_t;
>> >> > +
>> >> > +typedef struct __packed {
>> >>
>> >> Why __packed when all the others aren't?
>> >
>> > Ha! This thing was taken from GRUB2 source.
>> > I was asking this question myself many times.
>> > I have not found real explanation for this
>> > but if you wish I can dive into code and
>> > try to find one (if it exists).
>>
>> Or even better just drop the __packed.
> 
> Should not we be in line with GRUB2 source?
> Even it sounds strange. Anyway, I will check
> GRUB2 source and maybe we can also remove __packed
> from it. This way everything will be OK.

Now that's the right course of action.

Jan

Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support

[Daniel Kiper]

On Fri, Mar 27, 2015 at 11:20:10AM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 11:56, <daniel.kiper@oracle.com> wrote:
> > On Fri, Feb 20, 2015 at 04:06:26PM +0000, Jan Beulich wrote:
> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >> > --- a/xen/arch/x86/boot/Makefile
> >> > +++ b/xen/arch/x86/boot/Makefile
> >> > @@ -1,6 +1,7 @@
> >> >  obj-bin-y += head.o
> >> >
> >> > -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h
> >> > +RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/compiler.h \
> >> > +	     $(BASEDIR)/include/xen/multiboot.h $(BASEDIR)/include/xen/multiboot2.h
> >>
> >> Perhaps we should rather have the compiler generate the
> >> dependencies for us when compiling reloc.o?
> >
> > Hmmm... I am a bit confused. Here
> > http://lists.xen.org/archives/html/xen-devel/2014-10/msg02094.html
> > you told a bit different thing and relevant patch was accepted as commit
> > c42070df66c9fcedf477959b8371b85aa4ac4933
> > (x86/boot: fix reloc.S build dependencies). I can try to do what you
> > suggest, this is not a problem
> > for me, however, I would like to be sure what is your final decision in that
> > case.
>
> First of all I wasn't anticipating that this list of dependencies would
> further grow. And then I didn't say "don't do this", I only pointed
> out (albeit maybe a little too implicitly) that this would be a more
> complex patch.

So, I understand this as "Go for it!".

> >> > +        .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
> >> > +        .long   MULTIBOOT2_TAG_TYPE_MMAP
> >> > +.Lmultiboot2_info_req_end:
> >> > +
> >> > +        .align  MULTIBOOT2_TAG_ALIGN
> >> > +        .short  MULTIBOOT2_HEADER_TAG_MODULE_ALIGN
> >> > +        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
> >> > +        .long   8 /* Tag size. */
> >>
> >> ... here and further down you hard-code it. Please be consistent
> >> (and if you go the calculation route, perhaps introduce some
> >> redundancy reducing macro).
> >
> > I did this deliberately. I calculate size using labels when it is really
> > needed, e.g. in tags which size depends on number of elements. However,
> > most tags have strictly defined sizes. So, that is why I dropped labels
> > and entered simple numbers. Though I agree that it can be improved.
> > I think that we can define relevant tag structures in multiboot2.h and
> > generate relevant constants using asm-offsets.c. Is it OK for you?
>
> That would mean exposing stuff to other parts of the tree which
> doesn't need to be exposed. I don't see why you can't just do
> proper size calculations here.

OK, I will do this as you wish.

> >> > @@ -81,10 +135,51 @@ __start:
> >> >          mov     %ecx,%es
> >> >          mov     %ecx,%ss
> >> >
> >> > +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> >>
> >> Above you meet coding style requirements, but here you stop to do
> >> so (ongoing below)? Even if pre-existing neighboring comments aren't
> >> well formed, please don't make the situation worse.
> >
> > Do you ask about ending fullstops? Am I right?
>
> Yes.
>
> >> > @@ -31,7 +38,16 @@ asm (
> >> >      );
> >> >
> >> >  typedef unsigned int u32;
> >> > +typedef unsigned long long u64;
> >> > +
> >> > +#include "../../../include/xen/compiler.h"
> >>
> >> Why?
> >
> > static multiboot_info_t __used *reloc(void *mbi_in, u32 mb_magic)
> > Because of this ------> ^^^^^^
>
> And what keeps you from leaving out the "static", making the
> __used unnecessary?

This func is clearly static. Why do not mark it as is and use __used.
What is wrong with that?

> >> > +
> >> > +typedef struct {
> >> > +    u32 type;
> >> > +    u32 size;
> >> > +    u32 mem_lower;
> >> > +    u32 mem_upper;
> >> > +} multiboot2_tag_basic_meminfo_t;
> >> > +
> >> > +typedef struct __packed {
> >>
> >> Why __packed when all the others aren't?
> >
> > Ha! This thing was taken from GRUB2 source.
> > I was asking this question myself many times.
> > I have not found real explanation for this
> > but if you wish I can dive into code and
> > try to find one (if it exists).
>
> Or even better just drop the __packed.

Should not we be in line with GRUB2 source?
Even it sounds strange. Anyway, I will check
GRUB2 source and maybe we can also remove __packed
from it. This way everything will be OK.

Daniel

Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support

[Jan Beulich]

>>> On 27.03.15 at 11:56, <daniel.kiper@oracle.com> wrote:
> On Fri, Feb 20, 2015 at 04:06:26PM +0000, Jan Beulich wrote:
>> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> > --- a/xen/arch/x86/boot/Makefile
>> > +++ b/xen/arch/x86/boot/Makefile
>> > @@ -1,6 +1,7 @@
>> >  obj-bin-y += head.o
>> >
>> > -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h
>> > +RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/compiler.h \
>> > +	     $(BASEDIR)/include/xen/multiboot.h $(BASEDIR)/include/xen/multiboot2.h
>>
>> Perhaps we should rather have the compiler generate the
>> dependencies for us when compiling reloc.o?
> 
> Hmmm... I am a bit confused. Here 
> http://lists.xen.org/archives/html/xen-devel/2014-10/msg02094.html 
> you told a bit different thing and relevant patch was accepted as commit 
> c42070df66c9fcedf477959b8371b85aa4ac4933
> (x86/boot: fix reloc.S build dependencies). I can try to do what you 
> suggest, this is not a problem
> for me, however, I would like to be sure what is your final decision in that 
> case.

First of all I wasn't anticipating that this list of dependencies would
further grow. And then I didn't say "don't do this", I only pointed
out (albeit maybe a little too implicitly) that this would be a more
complex patch.

>> > +        .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
>> > +        .long   MULTIBOOT2_TAG_TYPE_MMAP
>> > +.Lmultiboot2_info_req_end:
>> > +
>> > +        .align  MULTIBOOT2_TAG_ALIGN
>> > +        .short  MULTIBOOT2_HEADER_TAG_MODULE_ALIGN
>> > +        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
>> > +        .long   8 /* Tag size. */
>>
>> ... here and further down you hard-code it. Please be consistent
>> (and if you go the calculation route, perhaps introduce some
>> redundancy reducing macro).
> 
> I did this deliberately. I calculate size using labels when it is really
> needed, e.g. in tags which size depends on number of elements. However,
> most tags have strictly defined sizes. So, that is why I dropped labels
> and entered simple numbers. Though I agree that it can be improved.
> I think that we can define relevant tag structures in multiboot2.h and
> generate relevant constants using asm-offsets.c. Is it OK for you?

That would mean exposing stuff to other parts of the tree which
doesn't need to be exposed. I don't see why you can't just do
proper size calculations here.

>> > @@ -81,10 +135,51 @@ __start:
>> >          mov     %ecx,%es
>> >          mov     %ecx,%ss
>> >
>> > +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
>>
>> Above you meet coding style requirements, but here you stop to do
>> so (ongoing below)? Even if pre-existing neighboring comments aren't
>> well formed, please don't make the situation worse.
> 
> Do you ask about ending fullstops? Am I right?

Yes.

>> > @@ -31,7 +38,16 @@ asm (
>> >      );
>> >
>> >  typedef unsigned int u32;
>> > +typedef unsigned long long u64;
>> > +
>> > +#include "../../../include/xen/compiler.h"
>>
>> Why?
> 
> static multiboot_info_t __used *reloc(void *mbi_in, u32 mb_magic)
> Because of this ------> ^^^^^^

And what keeps you from leaving out the "static", making the
__used unnecessary?

>> > +
>> > +typedef struct {
>> > +    u32 type;
>> > +    u32 size;
>> > +    u32 mem_lower;
>> > +    u32 mem_upper;
>> > +} multiboot2_tag_basic_meminfo_t;
>> > +
>> > +typedef struct __packed {
>>
>> Why __packed when all the others aren't?
> 
> Ha! This thing was taken from GRUB2 source.
> I was asking this question myself many times.
> I have not found real explanation for this
> but if you wish I can dive into code and
> try to find one (if it exists).

Or even better just drop the __packed.

Jan

Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support

[Daniel Kiper]

On Fri, Feb 20, 2015 at 04:06:26PM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> > --- a/xen/arch/x86/boot/Makefile
> > +++ b/xen/arch/x86/boot/Makefile
> > @@ -1,6 +1,7 @@
> >  obj-bin-y += head.o
> >
> > -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h
> > +RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/compiler.h \
> > +	     $(BASEDIR)/include/xen/multiboot.h $(BASEDIR)/include/xen/multiboot2.h
>
> Perhaps we should rather have the compiler generate the
> dependencies for us when compiling reloc.o?

Hmmm... I am a bit confused. Here http://lists.xen.org/archives/html/xen-devel/2014-10/msg02094.html
you told a bit different thing and relevant patch was accepted as commit c42070df66c9fcedf477959b8371b85aa4ac4933
(x86/boot: fix reloc.S build dependencies). I can try to do what you suggest, this is not a problem
for me, however, I would like to be sure what is your final decision in that case.

> > @@ -32,6 +33,59 @@ ENTRY(start)
> >          .long   MULTIBOOT_HEADER_FLAGS
> >          /* Checksum: must be the negated sum of the first two fields. */
> >          .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
> > +
> > +/*** MULTIBOOT2 HEADER ****/
> > +/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S file. */
> > +        .align  MULTIBOOT2_HEADER_ALIGN
> > +
> > +.Lmultiboot2_header:
> > +        /* Magic number indicating a Multiboot2 header. */
> > +        .long   MULTIBOOT2_HEADER_MAGIC
> > +        /* Architecture: i386. */
> > +        .long   MULTIBOOT2_ARCHITECTURE_I386
> > +        /* Multiboot2 header length. */
> > +        .long   .Lmultiboot2_header_end - .Lmultiboot2_header
> > +        /* Multiboot2 header checksum. */
> > +        .long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
> > +                        (.Lmultiboot2_header_end - .Lmultiboot2_header))
>
> So here ...
>
> > +        /* Multiboot2 tags... */
> > +.Lmultiboot2_info_req:
> > +        /* Multiboot2 information request tag. */
> > +        .short  MULTIBOOT2_HEADER_TAG_INFORMATION_REQUEST
> > +        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
> > +        .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
>
> .. and here you properly calculate the length, while ...
>
> > +        .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
> > +        .long   MULTIBOOT2_TAG_TYPE_MMAP
> > +.Lmultiboot2_info_req_end:
> > +
> > +        .align  MULTIBOOT2_TAG_ALIGN
> > +        .short  MULTIBOOT2_HEADER_TAG_MODULE_ALIGN
> > +        .short  MULTIBOOT2_HEADER_TAG_REQUIRED
> > +        .long   8 /* Tag size. */
>
> ... here and further down you hard-code it. Please be consistent
> (and if you go the calculation route, perhaps introduce some
> redundancy reducing macro).

I did this deliberately. I calculate size using labels when it is really
needed, e.g. in tags which size depends on number of elements. However,
most tags have strictly defined sizes. So, that is why I dropped labels
and entered simple numbers. Though I agree that it can be improved.
I think that we can define relevant tag structures in multiboot2.h and
generate relevant constants using asm-offsets.c. Is it OK for you?

> > +        /* Console flags tag. */
> > +        .align  MULTIBOOT2_TAG_ALIGN
> > +        .short  MULTIBOOT2_HEADER_TAG_CONSOLE_FLAGS
> > +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> > +        .long   12 /* Tag size. */
> > +        .long   MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
> > +
> > +        /* Framebuffer tag. */
> > +        .align  MULTIBOOT2_TAG_ALIGN
> > +        .short  MULTIBOOT2_HEADER_TAG_FRAMEBUFFER
> > +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> > +        .long   20 /* Tag size. */
> > +        .long   0 /* Number of the columns - no preference. */
> > +        .long   0 /* Number of the lines - no preference. */
> > +        .long   0 /* Number of bits per pixel - no preference. */
> > +
> > +        /* Multiboot2 header end tag. */
> > +        .align  MULTIBOOT2_TAG_ALIGN
> > +        .short  MULTIBOOT2_HEADER_TAG_END
> > +        .short  0
> > +        .long   8 /* Tag size. */
> > +.Lmultiboot2_header_end:
> >
> >          .section .init.rodata, "a", @progbits
> >          .align 4
> > @@ -81,10 +135,51 @@ __start:
> >          mov     %ecx,%es
> >          mov     %ecx,%ss
> >
> > +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
>
> Above you meet coding style requirements, but here you stop to do
> so (ongoing below)? Even if pre-existing neighboring comments aren't
> well formed, please don't make the situation worse.

Do you ask about ending fullstops? Am I right?

> Also please don't say 12 here - I first even mistook this as an array
> index, but you seem to mean 1 or 2. Please use {1,2} instead.

OK.

> > +        xor     %edx,%edx
> > +
> >          /* Check for Multiboot bootloader */
> >          cmp     $MULTIBOOT_BOOTLOADER_MAGIC,%eax
> > -        jne     not_multiboot
> > +        je      multiboot1_proto
> >
> > +        /* Check for Multiboot2 bootloader */
> > +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> > +        je      multiboot2_proto
> > +
> > +        jmp     not_multiboot
> > +
> > +multiboot1_proto:
> > +        /* Get mem_lower from Multiboot information */
> > +        testb   $MBI_MEMLIMITS,(%ebx)
>
> MB_flags(%ebx)
>
> > +        jz      trampoline_setup    /* not available? BDA value will be fine */
> > +
> > +        mov     MB_mem_lower(%ebx),%edx
>
> Please use "cmovnz" or "or" instead of "jz" and "mov".
>
> > +        jmp     trampoline_setup
> > +
> > +multiboot2_proto:
> > +        /* Skip Multiboot2 information fixed part */
> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
> > +
> > +0:
> > +        /* Get mem_lower from Multiboot2 information */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> > +        jne     1f
> > +
> > +        mov     MB2_mem_lower(%ecx),%edx
> > +        jmp     trampoline_setup
> > +
> > +1:
> > +        /* Is it the end of Multiboot2 information? */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
>
> This lacks the use a suitable MB2_* definition (even if that ends up
> being zero).
>
> > --- a/xen/arch/x86/boot/reloc.c
> > +++ b/xen/arch/x86/boot/reloc.c
> > @@ -5,19 +5,26 @@
> >   * and modules. This is most easily done early with paging disabled.
> >   *
> >   * Copyright (c) 2009, Citrix Systems, Inc.
> > + * Copyright (c) 2013, 2014, 2015 Oracle Corp.
> >   *
> >   * Authors:
> >   *    Keir Fraser <keir@xen.org>
> > + *    Daniel Kiper
>
> If you add yourself here, then please (following the existing example)
> with email address.
>
> > -/* entered with %eax = BOOT_TRAMPOLINE */
> > +/*
> > + * This entry point is entered from xen/arch/x86/boot/head.S with:
> > + *   - %eax = MULTIBOOT_MAGIC,
> > + *   - %ebx = MULTIBOOT_INFORMATION_ADDRESS,
> > + *   - %ecx = BOOT_TRAMPOLINE.
>
> Then why do you push %eax and %ebx above?
>
> > @@ -31,7 +38,16 @@ asm (
> >      );
> >
> >  typedef unsigned int u32;
> > +typedef unsigned long long u64;
> > +
> > +#include "../../../include/xen/compiler.h"
>
> Why?

static multiboot_info_t __used *reloc(void *mbi_in, u32 mb_magic)
Because of this ------> ^^^^^^

> > @@ -74,40 +95,153 @@ static u32 copy_string(u32 src)
> >      return copy_struct(src, p - (char *)src + 1);
> >  }
> >
> > -multiboot_info_t *reloc(multiboot_info_t *mbi_old)
> > +static multiboot_info_t *mbi_mbi(void *mbi_in)
> >  {
> > -    multiboot_info_t *mbi = (multiboot_info_t *)copy_struct((u32)mbi_old, sizeof(*mbi));
> >      int i;
> > +    multiboot_info_t *mbi_out;
> >
> > -    if ( mbi->flags & MBI_CMDLINE )
> > -        mbi->cmdline = copy_string(mbi->cmdline);
> > +    mbi_out = (multiboot_info_t *)copy_struct((u32)mbi_in, sizeof(*mbi_out));
>
> Why can this not remain the initializer of the variable? Also the
> unrelated renaming mbi -> mbi_out and mbi_old ->mbi_in only makes
> reading the patch more cumbersome. If you absolutely feel like you
> need to rename them, do this in a separate patch.
>
> > +static multiboot_info_t *mbi2_mbi(void *mbi_in)
> > +{
> > +    module_t *mbi_out_mods;
> > +    memory_map_t *mmap_dst;
> > +    multiboot2_memory_map_t *mmap_src;
> > +    multiboot2_tag_t *tag;
> > +    multiboot_info_t *mbi_out;
> > +    u32 ptr;
> > +    unsigned int i, mod_idx = 0;
> > +
> > +    mbi_out = (multiboot_info_t *)alloc_struct(sizeof(*mbi_out));
> > +    zero_struct((u32)mbi_out, sizeof(*mbi_out));
> > +
> > +    /* Skip Multiboot2 information fixed part. */
> > +    tag = mbi_in + sizeof(multiboot2_fixed_t);
> > +
> > +    for ( ; ; )
> > +    {
> > +        if ( tag->type == MULTIBOOT2_TAG_TYPE_MODULE )
> > +            ++mbi_out->mods_count;
> > +        else if ( tag->type == MULTIBOOT2_TAG_TYPE_END )
> > +        {
> > +            mbi_out->flags = MBI_MODULES;
> > +            mbi_out->mods_addr = alloc_struct(mbi_out->mods_count * sizeof(module_t));
> > +            mbi_out_mods = (module_t *)mbi_out->mods_addr;
> > +            break;
> > +        }
> > +
> > +        /* Go to next Multiboot2 information tag. */
> > +        tag = (multiboot2_tag_t *)(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN));
> > +    }
>
> Shouldn't you also break out of the loop when mbi_in->total_size
> gets exceeded?

Tag MULTIBOOT2_TAG_TYPE_END is always added as the end marker
but we can check also mbi_in->total_size just in case.

> > +#ifndef __ASSEMBLY__
> > +typedef struct {
> > +    u32 total_size;
> > +    u32 reserved;
> > +} multiboot2_fixed_t;
> > +
> > +typedef struct {
> > +    u32 type;
> > +    u32 size;
> > +} multiboot2_tag_t;
> > +
> > +typedef struct {
> > +    u32 type;
> > +    u32 size;
> > +    char string[0];
> > +} multiboot2_tag_string_t;
>
> Are these _tag_ parts of the name really needed?

This is not a must but I tried to mimic things in GRUB2 as much as possible.

> > +
> > +typedef struct {
> > +    u32 type;
> > +    u32 size;
> > +    u32 mem_lower;
> > +    u32 mem_upper;
> > +} multiboot2_tag_basic_meminfo_t;
> > +
> > +typedef struct __packed {
>
> Why __packed when all the others aren't?

Ha! This thing was taken from GRUB2 source.
I was asking this question myself many times.
I have not found real explanation for this
but if you wish I can dive into code and
try to find one (if it exists).

Daniel

[PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Daniel Kiper]

We need more fine grained knowledge about EFI environment and check
for EFI platform and EFI loader separately to properly support
multiboot2 protocol. In general Xen loaded by this protocol uses
memory mappings and loaded modules in simliar way to Xen loaded
by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
and efi_loader.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/arch/x86/dmi_scan.c    |    4 ++--
 xen/arch/x86/domain_page.c |    2 +-
 xen/arch/x86/efi/stub.c    |    5 +++--
 xen/arch/x86/mpparse.c     |    4 ++--
 xen/arch/x86/setup.c       |    8 ++++----
 xen/arch/x86/time.c        |    2 +-
 xen/common/efi/boot.c      |    5 +++++
 xen/common/efi/runtime.c   |    5 +++--
 xen/drivers/acpi/osl.c     |    2 +-
 xen/include/xen/efi.h      |    6 +++++-
 10 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
index 500133a..63b976c 100644
--- a/xen/arch/x86/dmi_scan.c
+++ b/xen/arch/x86/dmi_scan.c
@@ -150,7 +150,7 @@ int __init dmi_get_table(u32 *base, u32 *len)
 	struct dmi_eps eps;
 	char __iomem *p, *q;
 
-	if (efi_enabled) {
+	if (efi_platform) {
 		if (!efi_dmi_size)
 			return -1;
 		*base = efi_dmi_address;
@@ -516,7 +516,7 @@ static void __init dmi_decode(struct dmi_header *dm)
 
 void __init dmi_scan_machine(void)
 {
-	if ((!efi_enabled ? dmi_iterate(dmi_decode) :
+	if ((!efi_platform ? dmi_iterate(dmi_decode) :
 	                    dmi_efi_iterate(dmi_decode)) == 0)
  		dmi_check_system(dmi_blacklist);
 	else
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 158a164..5d4564c 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -45,7 +45,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
             sync_local_execstate();
         /* We must now be running on the idle page table. */
         ASSERT((cr3 = read_cr3()) == __pa(idle_pg_table) ||
-               (efi_enabled && cr3 == efi_rs_page_table()));
+               (efi_platform && cr3 == efi_rs_page_table()));
     }
 
     return v;
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
index b8f49f8..5060e6f 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -3,8 +3,9 @@
 #include <xen/init.h>
 #include <xen/lib.h>
 
-#ifndef efi_enabled
-const bool_t efi_enabled = 0;
+#ifndef efi_platform
+bool_t efi_platform = 0;
+bool_t efi_loader = 0;
 #endif
 
 void __init efi_init_memory(void) { }
diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
index a38e016..c4e3041 100644
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -540,7 +540,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
 
 static __init void efi_unmap_mpf(void)
 {
-	if (efi_enabled)
+	if (efi_platform)
 		__set_fixmap(FIX_EFI_MPF, 0, 0);
 }
 
@@ -698,7 +698,7 @@ void __init find_smp_config (void)
 {
 	unsigned int address;
 
-	if (efi_enabled) {
+	if (efi_platform) {
 		efi_check_config();
 		return;
 	}
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index c27c49c..711fdb0 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -431,7 +431,7 @@ static void __init parse_video_info(void)
     struct boot_video_info *bvi = &bootsym(boot_vid_info);
 
     /* The EFI loader fills vga_console_info directly. */
-    if ( efi_enabled )
+    if ( efi_platform )
         return;
 
     if ( (bvi->orig_video_isVGA == 1) && (bvi->orig_video_mode == 3) )
@@ -663,7 +663,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
         panic("Misaligned CPU0 stack.");
 
-    if ( efi_enabled )
+    if ( efi_loader )
     {
         set_pdx_range(xen_phys_start >> PAGE_SHIFT,
                       (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
@@ -774,7 +774,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
      * we can relocate the dom0 kernel and other multiboot modules. Also, on
      * x86/64, we relocate Xen to higher memory.
      */
-    for ( i = 0; !efi_enabled && i < mbi->mods_count; i++ )
+    for ( i = 0; !efi_loader && i < mbi->mods_count; i++ )
     {
         if ( mod[i].mod_start & (PAGE_SIZE - 1) )
             panic("Bootloader didn't honor module alignment request.");
@@ -962,7 +962,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
     if ( !xen_phys_start )
         panic("Not enough memory to relocate Xen.");
-    reserve_e820_ram(&boot_e820, efi_enabled ? mbi->mem_upper : __pa(&_start),
+    reserve_e820_ram(&boot_e820, efi_loader ? mbi->mem_upper : __pa(&_start),
                      __pa(&_end));
 
     /* Late kexec reservation (dynamic start address). */
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 74c01e3..cdd17cb 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -689,7 +689,7 @@ static unsigned long get_cmos_time(void)
     static bool_t __read_mostly cmos_rtc_probe;
     boolean_param("cmos-rtc-probe", cmos_rtc_probe);
 
-    if ( efi_enabled )
+    if ( efi_platform )
     {
         res = efi_get_time();
         if ( res )
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index ac6881e..8aafcfd 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -708,6 +708,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     char *option_str;
     bool_t use_cfg_file;
 
+#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
+    efi_platform = 1;
+    efi_loader = 1;
+#endif
+
     efi_ih = ImageHandle;
     efi_bs = SystemTable->BootServices;
     efi_rs = SystemTable->RuntimeServices;
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index c840e08..b229c69 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -11,13 +11,14 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
 #ifndef COMPAT
 
 #ifdef CONFIG_ARM  /* Disabled until runtime services implemented */
-const bool_t efi_enabled = 0;
+const bool_t efi_platform = 0;
 #else
 # include <asm/i387.h>
 # include <asm/xstate.h>
 # include <public/platform.h>
 
-const bool_t efi_enabled = 1;
+bool_t efi_platform = 0;
+bool_t efi_loader = 0;
 #endif
 
 unsigned int __read_mostly efi_num_ct;
diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index 93c983c..b066459 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list args)
 
 acpi_physical_address __init acpi_os_get_root_pointer(void)
 {
-	if (efi_enabled) {
+	if (efi_platform) {
 		if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
 			return efi.acpi20;
 		else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index 5e02724..54cd390 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -5,7 +5,11 @@
 #include <xen/types.h>
 #endif
 
-extern const bool_t efi_enabled;
+/* If true then Xen runs on EFI platform. */
+extern bool_t efi_platform;
+
+/* If true then Xen was loaded by native EFI loader as PE application. */
+extern bool_t efi_loader;
 
 #define EFI_INVALID_TABLE_ADDR (~0UL)
 
-- 
1.7.10.4

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> We need more fine grained knowledge about EFI environment and check
> for EFI platform and EFI loader separately to properly support
> multiboot2 protocol.

... because of ... (i.e. I can't see from the description what the
separation is good for). Looking at the comments you placed
aside the variables doesn't help me either.

> In general Xen loaded by this protocol uses
> memory mappings and loaded modules in simliar way to Xen loaded
> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
> and efi_loader.

And if I'm guessing things right, then introducing efi_loader but
leaving efi_enabled alone (only converting where needed) would
seem the right approach.

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -431,7 +431,7 @@ static void __init parse_video_info(void)
>      struct boot_video_info *bvi = &bootsym(boot_vid_info);
>  
>      /* The EFI loader fills vga_console_info directly. */
> -    if ( efi_enabled )
> +    if ( efi_platform )

This looks wrong considering the comment.

> @@ -663,7 +663,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>      if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
>          panic("Misaligned CPU0 stack.");
>  
> -    if ( efi_enabled )
> +    if ( efi_loader )
>      {
>          set_pdx_range(xen_phys_start >> PAGE_SHIFT,
>                        (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
> @@ -774,7 +774,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>       * we can relocate the dom0 kernel and other multiboot modules. Also, on
>       * x86/64, we relocate Xen to higher memory.
>       */
> -    for ( i = 0; !efi_enabled && i < mbi->mods_count; i++ )
> +    for ( i = 0; !efi_loader && i < mbi->mods_count; i++ )
>      {
>          if ( mod[i].mod_start & (PAGE_SIZE - 1) )
>              panic("Bootloader didn't honor module alignment request.");
> @@ -962,7 +962,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>      if ( !xen_phys_start )
>          panic("Not enough memory to relocate Xen.");
> -    reserve_e820_ram(&boot_e820, efi_enabled ? mbi->mem_upper : __pa(&_start),
> +    reserve_e820_ram(&boot_e820, efi_loader ? mbi->mem_upper : __pa(&_start),

For all of these it's really hard to tell whether they're right without
knowing which parts of the current EFI loading code you intend to
re-use. Perhaps switching these would better be done along with
adding the re-using code (or splitting out the not re-used parts)?

> --- a/xen/include/xen/efi.h
> +++ b/xen/include/xen/efi.h
> @@ -5,7 +5,11 @@
>  #include <xen/types.h>
>  #endif
>  
> -extern const bool_t efi_enabled;
> +/* If true then Xen runs on EFI platform. */
> +extern bool_t efi_platform;
> +
> +/* If true then Xen was loaded by native EFI loader as PE application. */
> +extern bool_t efi_loader;

I don't see why you're losing the constness.

Jan

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> We need more fine grained knowledge about EFI environment and check
> for EFI platform and EFI loader separately to properly support
> multiboot2 protocol.

... because of ... (i.e. I can't see from the description what the
separation is good for). Looking at the comments you placed
aside the variables doesn't help me either.

> In general Xen loaded by this protocol uses
> memory mappings and loaded modules in simliar way to Xen loaded
> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
> and efi_loader.

And if I'm guessing things right, then introducing efi_loader but
leaving efi_enabled alone (only converting where needed) would
seem the right approach.

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -431,7 +431,7 @@ static void __init parse_video_info(void)
>      struct boot_video_info *bvi = &bootsym(boot_vid_info);
>  
>      /* The EFI loader fills vga_console_info directly. */
> -    if ( efi_enabled )
> +    if ( efi_platform )

This looks wrong considering the comment.

> @@ -663,7 +663,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>      if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
>          panic("Misaligned CPU0 stack.");
>  
> -    if ( efi_enabled )
> +    if ( efi_loader )
>      {
>          set_pdx_range(xen_phys_start >> PAGE_SHIFT,
>                        (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
> @@ -774,7 +774,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>       * we can relocate the dom0 kernel and other multiboot modules. Also, on
>       * x86/64, we relocate Xen to higher memory.
>       */
> -    for ( i = 0; !efi_enabled && i < mbi->mods_count; i++ )
> +    for ( i = 0; !efi_loader && i < mbi->mods_count; i++ )
>      {
>          if ( mod[i].mod_start & (PAGE_SIZE - 1) )
>              panic("Bootloader didn't honor module alignment request.");
> @@ -962,7 +962,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>      if ( !xen_phys_start )
>          panic("Not enough memory to relocate Xen.");
> -    reserve_e820_ram(&boot_e820, efi_enabled ? mbi->mem_upper : __pa(&_start),
> +    reserve_e820_ram(&boot_e820, efi_loader ? mbi->mem_upper : __pa(&_start),

For all of these it's really hard to tell whether they're right without
knowing which parts of the current EFI loading code you intend to
re-use. Perhaps switching these would better be done along with
adding the re-using code (or splitting out the not re-used parts)?

> --- a/xen/include/xen/efi.h
> +++ b/xen/include/xen/efi.h
> @@ -5,7 +5,11 @@
>  #include <xen/types.h>
>  #endif
>  
> -extern const bool_t efi_enabled;
> +/* If true then Xen runs on EFI platform. */
> +extern bool_t efi_platform;
> +
> +/* If true then Xen was loaded by native EFI loader as PE application. */
> +extern bool_t efi_loader;

I don't see why you're losing the constness.

Jan

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Daniel Kiper]

On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> > We need more fine grained knowledge about EFI environment and check
> > for EFI platform and EFI loader separately to properly support
> > multiboot2 protocol.
>
> ... because of ... (i.e. I can't see from the description what the
> separation is good for). Looking at the comments you placed
> aside the variables doesn't help me either.
>
> > In general Xen loaded by this protocol uses
> > memory mappings and loaded modules in simliar way to Xen loaded
> > by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
> > and efi_loader.
>
> And if I'm guessing things right, then introducing efi_loader but
> leaving efi_enabled alone (only converting where needed) would

efi_enabled is not fortunate name for new usage. Currently it means
that Xen binary have or does not have EFI support build in. However,
if we build in multiboot2 protocol into xen.gz then it means that
it can ran on legacy BIOS or EFI platform. So, I think that we
should rename efi_enabled to efi_platform because it will mean
that Xen runs on EFI platform or not.

efi_loader is used to differentiate between EFI native loader
and multiboot2 protocol.

> seem the right approach.

[...]

> > --- a/xen/include/xen/efi.h
> > +++ b/xen/include/xen/efi.h
> > @@ -5,7 +5,11 @@
> >  #include <xen/types.h>
> >  #endif
> >
> > -extern const bool_t efi_enabled;
> > +/* If true then Xen runs on EFI platform. */
> > +extern bool_t efi_platform;
> > +
> > +/* If true then Xen was loaded by native EFI loader as PE application. */
> > +extern bool_t efi_loader;
>
> I don't see why you're losing the constness.

Both of them could be set during runtime. Please look above
for more details.

Daniel

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Daniel Kiper]

On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> > We need more fine grained knowledge about EFI environment and check
> > for EFI platform and EFI loader separately to properly support
> > multiboot2 protocol.
>
> ... because of ... (i.e. I can't see from the description what the
> separation is good for). Looking at the comments you placed
> aside the variables doesn't help me either.
>
> > In general Xen loaded by this protocol uses
> > memory mappings and loaded modules in simliar way to Xen loaded
> > by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
> > and efi_loader.
>
> And if I'm guessing things right, then introducing efi_loader but
> leaving efi_enabled alone (only converting where needed) would

efi_enabled is not fortunate name for new usage. Currently it means
that Xen binary have or does not have EFI support build in. However,
if we build in multiboot2 protocol into xen.gz then it means that
it can ran on legacy BIOS or EFI platform. So, I think that we
should rename efi_enabled to efi_platform because it will mean
that Xen runs on EFI platform or not.

efi_loader is used to differentiate between EFI native loader
and multiboot2 protocol.

> seem the right approach.

[...]

> > --- a/xen/include/xen/efi.h
> > +++ b/xen/include/xen/efi.h
> > @@ -5,7 +5,11 @@
> >  #include <xen/types.h>
> >  #endif
> >
> > -extern const bool_t efi_enabled;
> > +/* If true then Xen runs on EFI platform. */
> > +extern bool_t efi_platform;
> > +
> > +/* If true then Xen was loaded by native EFI loader as PE application. */
> > +extern bool_t efi_loader;
>
> I don't see why you're losing the constness.

Both of them could be set during runtime. Please look above
for more details.

Daniel

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Jan Beulich]

>>> On 27.03.15 at 14:32, <daniel.kiper@oracle.com> wrote:
> On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
>> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> > We need more fine grained knowledge about EFI environment and check
>> > for EFI platform and EFI loader separately to properly support
>> > multiboot2 protocol.
>>
>> ... because of ... (i.e. I can't see from the description what the
>> separation is good for). Looking at the comments you placed
>> aside the variables doesn't help me either.
>>
>> > In general Xen loaded by this protocol uses
>> > memory mappings and loaded modules in simliar way to Xen loaded
>> > by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
>> > and efi_loader.
>>
>> And if I'm guessing things right, then introducing efi_loader but
>> leaving efi_enabled alone (only converting where needed) would
> 
> efi_enabled is not fortunate name for new usage. Currently it means
> that Xen binary have or does not have EFI support build in. However,
> if we build in multiboot2 protocol into xen.gz then it means that
> it can ran on legacy BIOS or EFI platform. So, I think that we
> should rename efi_enabled to efi_platform because it will mean
> that Xen runs on EFI platform or not.

I disagree here.

> efi_loader is used to differentiate between EFI native loader
> and multiboot2 protocol.

And I agree here.

Jan

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Jan Beulich]

>>> On 27.03.15 at 14:32, <daniel.kiper@oracle.com> wrote:
> On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
>> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> > We need more fine grained knowledge about EFI environment and check
>> > for EFI platform and EFI loader separately to properly support
>> > multiboot2 protocol.
>>
>> ... because of ... (i.e. I can't see from the description what the
>> separation is good for). Looking at the comments you placed
>> aside the variables doesn't help me either.
>>
>> > In general Xen loaded by this protocol uses
>> > memory mappings and loaded modules in simliar way to Xen loaded
>> > by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
>> > and efi_loader.
>>
>> And if I'm guessing things right, then introducing efi_loader but
>> leaving efi_enabled alone (only converting where needed) would
> 
> efi_enabled is not fortunate name for new usage. Currently it means
> that Xen binary have or does not have EFI support build in. However,
> if we build in multiboot2 protocol into xen.gz then it means that
> it can ran on legacy BIOS or EFI platform. So, I think that we
> should rename efi_enabled to efi_platform because it will mean
> that Xen runs on EFI platform or not.

I disagree here.

> efi_loader is used to differentiate between EFI native loader
> and multiboot2 protocol.

And I agree here.

Jan

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Andrew Cooper]

On 27/03/15 13:43, Jan Beulich wrote:
>>>> On 27.03.15 at 14:32, <daniel.kiper@oracle.com> wrote:
>> On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>>> We need more fine grained knowledge about EFI environment and check
>>>> for EFI platform and EFI loader separately to properly support
>>>> multiboot2 protocol.
>>> ... because of ... (i.e. I can't see from the description what the
>>> separation is good for). Looking at the comments you placed
>>> aside the variables doesn't help me either.
>>>
>>>> In general Xen loaded by this protocol uses
>>>> memory mappings and loaded modules in simliar way to Xen loaded
>>>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
>>>> and efi_loader.
>>> And if I'm guessing things right, then introducing efi_loader but
>>> leaving efi_enabled alone (only converting where needed) would
>> efi_enabled is not fortunate name for new usage. Currently it means
>> that Xen binary have or does not have EFI support build in. However,
>> if we build in multiboot2 protocol into xen.gz then it means that
>> it can ran on legacy BIOS or EFI platform. So, I think that we
>> should rename efi_enabled to efi_platform because it will mean
>> that Xen runs on EFI platform or not.
> I disagree here.
>
>> efi_loader is used to differentiate between EFI native loader
>> and multiboot2 protocol.
> And I agree here.

I suppose "built with efi support" is known because of CONFIG_EFI or 
not, and doesn't need a variable.

However, "booted legacy" vs "booted EFI" does need distinguishing at 
runtime, as either is possible.

~Andrew

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Andrew Cooper]

On 27/03/15 13:43, Jan Beulich wrote:
>>>> On 27.03.15 at 14:32, <daniel.kiper@oracle.com> wrote:
>> On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>>> We need more fine grained knowledge about EFI environment and check
>>>> for EFI platform and EFI loader separately to properly support
>>>> multiboot2 protocol.
>>> ... because of ... (i.e. I can't see from the description what the
>>> separation is good for). Looking at the comments you placed
>>> aside the variables doesn't help me either.
>>>
>>>> In general Xen loaded by this protocol uses
>>>> memory mappings and loaded modules in simliar way to Xen loaded
>>>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
>>>> and efi_loader.
>>> And if I'm guessing things right, then introducing efi_loader but
>>> leaving efi_enabled alone (only converting where needed) would
>> efi_enabled is not fortunate name for new usage. Currently it means
>> that Xen binary have or does not have EFI support build in. However,
>> if we build in multiboot2 protocol into xen.gz then it means that
>> it can ran on legacy BIOS or EFI platform. So, I think that we
>> should rename efi_enabled to efi_platform because it will mean
>> that Xen runs on EFI platform or not.
> I disagree here.
>
>> efi_loader is used to differentiate between EFI native loader
>> and multiboot2 protocol.
> And I agree here.

I suppose "built with efi support" is known because of CONFIG_EFI or 
not, and doesn't need a variable.

However, "booted legacy" vs "booted EFI" does need distinguishing at 
runtime, as either is possible.

~Andrew

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Jan Beulich]

>>> On 27.03.15 at 14:53, <andrew.cooper3@citrix.com> wrote:
> On 27/03/15 13:43, Jan Beulich wrote:
>>>>> On 27.03.15 at 14:32, <daniel.kiper@oracle.com> wrote:
>>> On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
>>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>>>> We need more fine grained knowledge about EFI environment and check
>>>>> for EFI platform and EFI loader separately to properly support
>>>>> multiboot2 protocol.
>>>> ... because of ... (i.e. I can't see from the description what the
>>>> separation is good for). Looking at the comments you placed
>>>> aside the variables doesn't help me either.
>>>>
>>>>> In general Xen loaded by this protocol uses
>>>>> memory mappings and loaded modules in simliar way to Xen loaded
>>>>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
>>>>> and efi_loader.
>>>> And if I'm guessing things right, then introducing efi_loader but
>>>> leaving efi_enabled alone (only converting where needed) would
>>> efi_enabled is not fortunate name for new usage. Currently it means
>>> that Xen binary have or does not have EFI support build in. However,
>>> if we build in multiboot2 protocol into xen.gz then it means that
>>> it can ran on legacy BIOS or EFI platform. So, I think that we
>>> should rename efi_enabled to efi_platform because it will mean
>>> that Xen runs on EFI platform or not.
>> I disagree here.
>>
>>> efi_loader is used to differentiate between EFI native loader
>>> and multiboot2 protocol.
>> And I agree here.
> 
> I suppose "built with efi support" is known because of CONFIG_EFI or 
> not, and doesn't need a variable.
> 
> However, "booted legacy" vs "booted EFI" does need distinguishing at 
> runtime, as either is possible.

Right, but that's what efi_enabled is supposed to express after
the change; there's no need to express "built with EFI support".
It just so happens that right now, without all these changes,
built-with-EFI-support == runs-on-EFI.

Jan

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Lennart Sorensen]

On Fri, Mar 27, 2015 at 02:04:22PM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 14:53, <andrew.cooper3@citrix.com> wrote:
> > On 27/03/15 13:43, Jan Beulich wrote:
> >>>>> On 27.03.15 at 14:32, <daniel.kiper@oracle.com> wrote:
> >>> On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
> >>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >>>>> We need more fine grained knowledge about EFI environment and check
> >>>>> for EFI platform and EFI loader separately to properly support
> >>>>> multiboot2 protocol.
> >>>> ... because of ... (i.e. I can't see from the description what the
> >>>> separation is good for). Looking at the comments you placed
> >>>> aside the variables doesn't help me either.
> >>>>
> >>>>> In general Xen loaded by this protocol uses
> >>>>> memory mappings and loaded modules in simliar way to Xen loaded
> >>>>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
> >>>>> and efi_loader.
> >>>> And if I'm guessing things right, then introducing efi_loader but
> >>>> leaving efi_enabled alone (only converting where needed) would
> >>> efi_enabled is not fortunate name for new usage. Currently it means
> >>> that Xen binary have or does not have EFI support build in. However,
> >>> if we build in multiboot2 protocol into xen.gz then it means that
> >>> it can ran on legacy BIOS or EFI platform. So, I think that we
> >>> should rename efi_enabled to efi_platform because it will mean
> >>> that Xen runs on EFI platform or not.
> >> I disagree here.
> >>
> >>> efi_loader is used to differentiate between EFI native loader
> >>> and multiboot2 protocol.
> >> And I agree here.
> > 
> > I suppose "built with efi support" is known because of CONFIG_EFI or 
> > not, and doesn't need a variable.
> > 
> > However, "booted legacy" vs "booted EFI" does need distinguishing at 
> > runtime, as either is possible.
> 
> Right, but that's what efi_enabled is supposed to express after
> the change; there's no need to express "built with EFI support".
> It just so happens that right now, without all these changes,
> built-with-EFI-support == runs-on-EFI.

Then how about 'efi_booted' as the variable name.

-- 
Len Sorensen

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Lennart Sorensen]

On Fri, Mar 27, 2015 at 02:04:22PM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 14:53, <andrew.cooper3@citrix.com> wrote:
> > On 27/03/15 13:43, Jan Beulich wrote:
> >>>>> On 27.03.15 at 14:32, <daniel.kiper@oracle.com> wrote:
> >>> On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
> >>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >>>>> We need more fine grained knowledge about EFI environment and check
> >>>>> for EFI platform and EFI loader separately to properly support
> >>>>> multiboot2 protocol.
> >>>> ... because of ... (i.e. I can't see from the description what the
> >>>> separation is good for). Looking at the comments you placed
> >>>> aside the variables doesn't help me either.
> >>>>
> >>>>> In general Xen loaded by this protocol uses
> >>>>> memory mappings and loaded modules in simliar way to Xen loaded
> >>>>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
> >>>>> and efi_loader.
> >>>> And if I'm guessing things right, then introducing efi_loader but
> >>>> leaving efi_enabled alone (only converting where needed) would
> >>> efi_enabled is not fortunate name for new usage. Currently it means
> >>> that Xen binary have or does not have EFI support build in. However,
> >>> if we build in multiboot2 protocol into xen.gz then it means that
> >>> it can ran on legacy BIOS or EFI platform. So, I think that we
> >>> should rename efi_enabled to efi_platform because it will mean
> >>> that Xen runs on EFI platform or not.
> >> I disagree here.
> >>
> >>> efi_loader is used to differentiate between EFI native loader
> >>> and multiboot2 protocol.
> >> And I agree here.
> > 
> > I suppose "built with efi support" is known because of CONFIG_EFI or 
> > not, and doesn't need a variable.
> > 
> > However, "booted legacy" vs "booted EFI" does need distinguishing at 
> > runtime, as either is possible.
> 
> Right, but that's what efi_enabled is supposed to express after
> the change; there's no need to express "built with EFI support".
> It just so happens that right now, without all these changes,
> built-with-EFI-support == runs-on-EFI.

Then how about 'efi_booted' as the variable name.

-- 
Len Sorensen

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Jan Beulich]

>>> On 27.03.15 at 15:09, <lsorense@csclub.uwaterloo.ca> wrote:
> On Fri, Mar 27, 2015 at 02:04:22PM +0000, Jan Beulich wrote:
>> >>> On 27.03.15 at 14:53, <andrew.cooper3@citrix.com> wrote:
>> > On 27/03/15 13:43, Jan Beulich wrote:
>> >>>>> On 27.03.15 at 14:32, <daniel.kiper@oracle.com> wrote:
>> >>> On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
>> >>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> >>>>> We need more fine grained knowledge about EFI environment and check
>> >>>>> for EFI platform and EFI loader separately to properly support
>> >>>>> multiboot2 protocol.
>> >>>> ... because of ... (i.e. I can't see from the description what the
>> >>>> separation is good for). Looking at the comments you placed
>> >>>> aside the variables doesn't help me either.
>> >>>>
>> >>>>> In general Xen loaded by this protocol uses
>> >>>>> memory mappings and loaded modules in simliar way to Xen loaded
>> >>>>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
>> >>>>> and efi_loader.
>> >>>> And if I'm guessing things right, then introducing efi_loader but
>> >>>> leaving efi_enabled alone (only converting where needed) would
>> >>> efi_enabled is not fortunate name for new usage. Currently it means
>> >>> that Xen binary have or does not have EFI support build in. However,
>> >>> if we build in multiboot2 protocol into xen.gz then it means that
>> >>> it can ran on legacy BIOS or EFI platform. So, I think that we
>> >>> should rename efi_enabled to efi_platform because it will mean
>> >>> that Xen runs on EFI platform or not.
>> >> I disagree here.
>> >>
>> >>> efi_loader is used to differentiate between EFI native loader
>> >>> and multiboot2 protocol.
>> >> And I agree here.
>> > 
>> > I suppose "built with efi support" is known because of CONFIG_EFI or 
>> > not, and doesn't need a variable.
>> > 
>> > However, "booted legacy" vs "booted EFI" does need distinguishing at 
>> > runtime, as either is possible.
>> 
>> Right, but that's what efi_enabled is supposed to express after
>> the change; there's no need to express "built with EFI support".
>> It just so happens that right now, without all these changes,
>> built-with-EFI-support == runs-on-EFI.
> 
> Then how about 'efi_booted' as the variable name.

Why should we rename a variable that's perfectly suitable for the
purposes we have? Even more so that we don't just want to
express that we were booted from EFI, but also that we're running
in a respective environment, including using tables coming from
EFI and using runtime services (unless specifically disabled). If
anything we could follow Linux and make efi_enabled a bit mask.

Jan

Re: [Xen-devel] [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Jan Beulich]

>>> On 27.03.15 at 15:09, <lsorense@csclub.uwaterloo.ca> wrote:
> On Fri, Mar 27, 2015 at 02:04:22PM +0000, Jan Beulich wrote:
>> >>> On 27.03.15 at 14:53, <andrew.cooper3@citrix.com> wrote:
>> > On 27/03/15 13:43, Jan Beulich wrote:
>> >>>>> On 27.03.15 at 14:32, <daniel.kiper@oracle.com> wrote:
>> >>> On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
>> >>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> >>>>> We need more fine grained knowledge about EFI environment and check
>> >>>>> for EFI platform and EFI loader separately to properly support
>> >>>>> multiboot2 protocol.
>> >>>> ... because of ... (i.e. I can't see from the description what the
>> >>>> separation is good for). Looking at the comments you placed
>> >>>> aside the variables doesn't help me either.
>> >>>>
>> >>>>> In general Xen loaded by this protocol uses
>> >>>>> memory mappings and loaded modules in simliar way to Xen loaded
>> >>>>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
>> >>>>> and efi_loader.
>> >>>> And if I'm guessing things right, then introducing efi_loader but
>> >>>> leaving efi_enabled alone (only converting where needed) would
>> >>> efi_enabled is not fortunate name for new usage. Currently it means
>> >>> that Xen binary have or does not have EFI support build in. However,
>> >>> if we build in multiboot2 protocol into xen.gz then it means that
>> >>> it can ran on legacy BIOS or EFI platform. So, I think that we
>> >>> should rename efi_enabled to efi_platform because it will mean
>> >>> that Xen runs on EFI platform or not.
>> >> I disagree here.
>> >>
>> >>> efi_loader is used to differentiate between EFI native loader
>> >>> and multiboot2 protocol.
>> >> And I agree here.
>> > 
>> > I suppose "built with efi support" is known because of CONFIG_EFI or 
>> > not, and doesn't need a variable.
>> > 
>> > However, "booted legacy" vs "booted EFI" does need distinguishing at 
>> > runtime, as either is possible.
>> 
>> Right, but that's what efi_enabled is supposed to express after
>> the change; there's no need to express "built with EFI support".
>> It just so happens that right now, without all these changes,
>> built-with-EFI-support == runs-on-EFI.
> 
> Then how about 'efi_booted' as the variable name.

Why should we rename a variable that's perfectly suitable for the
purposes we have? Even more so that we don't just want to
express that we were booted from EFI, but also that we're running
in a respective environment, including using tables coming from
EFI and using runtime services (unless specifically disabled). If
anything we could follow Linux and make efi_enabled a bit mask.

Jan

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Lennart Sorensen]

On Fri, Mar 27, 2015 at 02:19:44PM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 15:09, <lsorense@csclub.uwaterloo.ca> wrote:
> > On Fri, Mar 27, 2015 at 02:04:22PM +0000, Jan Beulich wrote:
> >> >>> On 27.03.15 at 14:53, <andrew.cooper3@citrix.com> wrote:
> >> > On 27/03/15 13:43, Jan Beulich wrote:
> >> >>>>> On 27.03.15 at 14:32, <daniel.kiper@oracle.com> wrote:
> >> >>> On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
> >> >>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >> >>>>> We need more fine grained knowledge about EFI environment and check
> >> >>>>> for EFI platform and EFI loader separately to properly support
> >> >>>>> multiboot2 protocol.
> >> >>>> ... because of ... (i.e. I can't see from the description what the
> >> >>>> separation is good for). Looking at the comments you placed
> >> >>>> aside the variables doesn't help me either.
> >> >>>>
> >> >>>>> In general Xen loaded by this protocol uses
> >> >>>>> memory mappings and loaded modules in simliar way to Xen loaded
> >> >>>>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
> >> >>>>> and efi_loader.
> >> >>>> And if I'm guessing things right, then introducing efi_loader but
> >> >>>> leaving efi_enabled alone (only converting where needed) would
> >> >>> efi_enabled is not fortunate name for new usage. Currently it means
> >> >>> that Xen binary have or does not have EFI support build in. However,
> >> >>> if we build in multiboot2 protocol into xen.gz then it means that
> >> >>> it can ran on legacy BIOS or EFI platform. So, I think that we
> >> >>> should rename efi_enabled to efi_platform because it will mean
> >> >>> that Xen runs on EFI platform or not.
> >> >> I disagree here.
> >> >>
> >> >>> efi_loader is used to differentiate between EFI native loader
> >> >>> and multiboot2 protocol.
> >> >> And I agree here.
> >> > 
> >> > I suppose "built with efi support" is known because of CONFIG_EFI or 
> >> > not, and doesn't need a variable.
> >> > 
> >> > However, "booted legacy" vs "booted EFI" does need distinguishing at 
> >> > runtime, as either is possible.
> >> 
> >> Right, but that's what efi_enabled is supposed to express after
> >> the change; there's no need to express "built with EFI support".
> >> It just so happens that right now, without all these changes,
> >> built-with-EFI-support == runs-on-EFI.
> > 
> > Then how about 'efi_booted' as the variable name.
> 
> Why should we rename a variable that's perfectly suitable for the
> purposes we have? Even more so that we don't just want to
> express that we were booted from EFI, but also that we're running
> in a respective environment, including using tables coming from
> EFI and using runtime services (unless specifically disabled). If
> anything we could follow Linux and make efi_enabled a bit mask.

OK, so it isn't just to tell that you booted from EFI.

-- 
Len Sorensen

Re: [Xen-devel] [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Lennart Sorensen]

On Fri, Mar 27, 2015 at 02:19:44PM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 15:09, <lsorense@csclub.uwaterloo.ca> wrote:
> > On Fri, Mar 27, 2015 at 02:04:22PM +0000, Jan Beulich wrote:
> >> >>> On 27.03.15 at 14:53, <andrew.cooper3@citrix.com> wrote:
> >> > On 27/03/15 13:43, Jan Beulich wrote:
> >> >>>>> On 27.03.15 at 14:32, <daniel.kiper@oracle.com> wrote:
> >> >>> On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
> >> >>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >> >>>>> We need more fine grained knowledge about EFI environment and check
> >> >>>>> for EFI platform and EFI loader separately to properly support
> >> >>>>> multiboot2 protocol.
> >> >>>> ... because of ... (i.e. I can't see from the description what the
> >> >>>> separation is good for). Looking at the comments you placed
> >> >>>> aside the variables doesn't help me either.
> >> >>>>
> >> >>>>> In general Xen loaded by this protocol uses
> >> >>>>> memory mappings and loaded modules in simliar way to Xen loaded
> >> >>>>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
> >> >>>>> and efi_loader.
> >> >>>> And if I'm guessing things right, then introducing efi_loader but
> >> >>>> leaving efi_enabled alone (only converting where needed) would
> >> >>> efi_enabled is not fortunate name for new usage. Currently it means
> >> >>> that Xen binary have or does not have EFI support build in. However,
> >> >>> if we build in multiboot2 protocol into xen.gz then it means that
> >> >>> it can ran on legacy BIOS or EFI platform. So, I think that we
> >> >>> should rename efi_enabled to efi_platform because it will mean
> >> >>> that Xen runs on EFI platform or not.
> >> >> I disagree here.
> >> >>
> >> >>> efi_loader is used to differentiate between EFI native loader
> >> >>> and multiboot2 protocol.
> >> >> And I agree here.
> >> > 
> >> > I suppose "built with efi support" is known because of CONFIG_EFI or 
> >> > not, and doesn't need a variable.
> >> > 
> >> > However, "booted legacy" vs "booted EFI" does need distinguishing at 
> >> > runtime, as either is possible.
> >> 
> >> Right, but that's what efi_enabled is supposed to express after
> >> the change; there's no need to express "built with EFI support".
> >> It just so happens that right now, without all these changes,
> >> built-with-EFI-support == runs-on-EFI.
> > 
> > Then how about 'efi_booted' as the variable name.
> 
> Why should we rename a variable that's perfectly suitable for the
> purposes we have? Even more so that we don't just want to
> express that we were booted from EFI, but also that we're running
> in a respective environment, including using tables coming from
> EFI and using runtime services (unless specifically disabled). If
> anything we could follow Linux and make efi_enabled a bit mask.

OK, so it isn't just to tell that you booted from EFI.

-- 
Len Sorensen

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Jan Beulich]

>>> On 27.03.15 at 14:53, <andrew.cooper3@citrix.com> wrote:
> On 27/03/15 13:43, Jan Beulich wrote:
>>>>> On 27.03.15 at 14:32, <daniel.kiper@oracle.com> wrote:
>>> On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
>>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>>>> We need more fine grained knowledge about EFI environment and check
>>>>> for EFI platform and EFI loader separately to properly support
>>>>> multiboot2 protocol.
>>>> ... because of ... (i.e. I can't see from the description what the
>>>> separation is good for). Looking at the comments you placed
>>>> aside the variables doesn't help me either.
>>>>
>>>>> In general Xen loaded by this protocol uses
>>>>> memory mappings and loaded modules in simliar way to Xen loaded
>>>>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
>>>>> and efi_loader.
>>>> And if I'm guessing things right, then introducing efi_loader but
>>>> leaving efi_enabled alone (only converting where needed) would
>>> efi_enabled is not fortunate name for new usage. Currently it means
>>> that Xen binary have or does not have EFI support build in. However,
>>> if we build in multiboot2 protocol into xen.gz then it means that
>>> it can ran on legacy BIOS or EFI platform. So, I think that we
>>> should rename efi_enabled to efi_platform because it will mean
>>> that Xen runs on EFI platform or not.
>> I disagree here.
>>
>>> efi_loader is used to differentiate between EFI native loader
>>> and multiboot2 protocol.
>> And I agree here.
> 
> I suppose "built with efi support" is known because of CONFIG_EFI or 
> not, and doesn't need a variable.
> 
> However, "booted legacy" vs "booted EFI" does need distinguishing at 
> runtime, as either is possible.

Right, but that's what efi_enabled is supposed to express after
the change; there's no need to express "built with EFI support".
It just so happens that right now, without all these changes,
built-with-EFI-support == runs-on-EFI.

Jan

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Stefano Stabellini]

On Fri, 30 Jan 2015, Daniel Kiper wrote:
> We need more fine grained knowledge about EFI environment and check
> for EFI platform and EFI loader separately to properly support
> multiboot2 protocol. In general Xen loaded by this protocol uses
> memory mappings and loaded modules in simliar way to Xen loaded
> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
> and efi_loader.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  xen/arch/x86/dmi_scan.c    |    4 ++--
>  xen/arch/x86/domain_page.c |    2 +-
>  xen/arch/x86/efi/stub.c    |    5 +++--
>  xen/arch/x86/mpparse.c     |    4 ++--
>  xen/arch/x86/setup.c       |    8 ++++----
>  xen/arch/x86/time.c        |    2 +-
>  xen/common/efi/boot.c      |    5 +++++
>  xen/common/efi/runtime.c   |    5 +++--
>  xen/drivers/acpi/osl.c     |    2 +-
>  xen/include/xen/efi.h      |    6 +++++-
>  10 files changed, 27 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
> index 500133a..63b976c 100644
> --- a/xen/arch/x86/dmi_scan.c
> +++ b/xen/arch/x86/dmi_scan.c
> @@ -150,7 +150,7 @@ int __init dmi_get_table(u32 *base, u32 *len)
>  	struct dmi_eps eps;
>  	char __iomem *p, *q;
>  
> -	if (efi_enabled) {
> +	if (efi_platform) {
>  		if (!efi_dmi_size)
>  			return -1;
>  		*base = efi_dmi_address;
> @@ -516,7 +516,7 @@ static void __init dmi_decode(struct dmi_header *dm)
>  
>  void __init dmi_scan_machine(void)
>  {
> -	if ((!efi_enabled ? dmi_iterate(dmi_decode) :
> +	if ((!efi_platform ? dmi_iterate(dmi_decode) :
>  	                    dmi_efi_iterate(dmi_decode)) == 0)
>   		dmi_check_system(dmi_blacklist);
>  	else
> diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
> index 158a164..5d4564c 100644
> --- a/xen/arch/x86/domain_page.c
> +++ b/xen/arch/x86/domain_page.c
> @@ -45,7 +45,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
>              sync_local_execstate();
>          /* We must now be running on the idle page table. */
>          ASSERT((cr3 = read_cr3()) == __pa(idle_pg_table) ||
> -               (efi_enabled && cr3 == efi_rs_page_table()));
> +               (efi_platform && cr3 == efi_rs_page_table()));
>      }
>  
>      return v;
> diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
> index b8f49f8..5060e6f 100644
> --- a/xen/arch/x86/efi/stub.c
> +++ b/xen/arch/x86/efi/stub.c
> @@ -3,8 +3,9 @@
>  #include <xen/init.h>
>  #include <xen/lib.h>
>  
> -#ifndef efi_enabled
> -const bool_t efi_enabled = 0;
> +#ifndef efi_platform
> +bool_t efi_platform = 0;
> +bool_t efi_loader = 0;
>  #endif
>  
>  void __init efi_init_memory(void) { }
> diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
> index a38e016..c4e3041 100644
> --- a/xen/arch/x86/mpparse.c
> +++ b/xen/arch/x86/mpparse.c
> @@ -540,7 +540,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
>  
>  static __init void efi_unmap_mpf(void)
>  {
> -	if (efi_enabled)
> +	if (efi_platform)
>  		__set_fixmap(FIX_EFI_MPF, 0, 0);
>  }
>  
> @@ -698,7 +698,7 @@ void __init find_smp_config (void)
>  {
>  	unsigned int address;
>  
> -	if (efi_enabled) {
> +	if (efi_platform) {
>  		efi_check_config();
>  		return;
>  	}
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index c27c49c..711fdb0 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -431,7 +431,7 @@ static void __init parse_video_info(void)
>      struct boot_video_info *bvi = &bootsym(boot_vid_info);
>  
>      /* The EFI loader fills vga_console_info directly. */
> -    if ( efi_enabled )
> +    if ( efi_platform )
>          return;
>  
>      if ( (bvi->orig_video_isVGA == 1) && (bvi->orig_video_mode == 3) )
> @@ -663,7 +663,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>      if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
>          panic("Misaligned CPU0 stack.");
>  
> -    if ( efi_enabled )
> +    if ( efi_loader )
>      {
>          set_pdx_range(xen_phys_start >> PAGE_SHIFT,
>                        (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
> @@ -774,7 +774,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>       * we can relocate the dom0 kernel and other multiboot modules. Also, on
>       * x86/64, we relocate Xen to higher memory.
>       */
> -    for ( i = 0; !efi_enabled && i < mbi->mods_count; i++ )
> +    for ( i = 0; !efi_loader && i < mbi->mods_count; i++ )
>      {
>          if ( mod[i].mod_start & (PAGE_SIZE - 1) )
>              panic("Bootloader didn't honor module alignment request.");
> @@ -962,7 +962,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>      if ( !xen_phys_start )
>          panic("Not enough memory to relocate Xen.");
> -    reserve_e820_ram(&boot_e820, efi_enabled ? mbi->mem_upper : __pa(&_start),
> +    reserve_e820_ram(&boot_e820, efi_loader ? mbi->mem_upper : __pa(&_start),
>                       __pa(&_end));
>  
>      /* Late kexec reservation (dynamic start address). */
> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> index 74c01e3..cdd17cb 100644
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -689,7 +689,7 @@ static unsigned long get_cmos_time(void)
>      static bool_t __read_mostly cmos_rtc_probe;
>      boolean_param("cmos-rtc-probe", cmos_rtc_probe);
>  
> -    if ( efi_enabled )
> +    if ( efi_platform )
>      {
>          res = efi_get_time();
>          if ( res )
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index ac6881e..8aafcfd 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -708,6 +708,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
>      char *option_str;
>      bool_t use_cfg_file;
>  
> +#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
> +    efi_platform = 1;
> +    efi_loader = 1;
> +#endif

What exactly needs to be implemented on ARM?  I thought that EFI ARM
support for Xen is pretty much complete.


>      efi_ih = ImageHandle;
>      efi_bs = SystemTable->BootServices;
>      efi_rs = SystemTable->RuntimeServices;
> diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
> index c840e08..b229c69 100644
> --- a/xen/common/efi/runtime.c
> +++ b/xen/common/efi/runtime.c
> @@ -11,13 +11,14 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
>  #ifndef COMPAT
>  
>  #ifdef CONFIG_ARM  /* Disabled until runtime services implemented */
> -const bool_t efi_enabled = 0;
> +const bool_t efi_platform = 0;
>  #else
>  # include <asm/i387.h>
>  # include <asm/xstate.h>
>  # include <public/platform.h>
>  
> -const bool_t efi_enabled = 1;
> +bool_t efi_platform = 0;
> +bool_t efi_loader = 0;
>  #endif
>  
>  unsigned int __read_mostly efi_num_ct;
> diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
> index 93c983c..b066459 100644
> --- a/xen/drivers/acpi/osl.c
> +++ b/xen/drivers/acpi/osl.c
> @@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list args)
>  
>  acpi_physical_address __init acpi_os_get_root_pointer(void)
>  {
> -	if (efi_enabled) {
> +	if (efi_platform) {
>  		if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
>  			return efi.acpi20;
>  		else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
> diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
> index 5e02724..54cd390 100644
> --- a/xen/include/xen/efi.h
> +++ b/xen/include/xen/efi.h
> @@ -5,7 +5,11 @@
>  #include <xen/types.h>
>  #endif
>  
> -extern const bool_t efi_enabled;
> +/* If true then Xen runs on EFI platform. */
> +extern bool_t efi_platform;
> +
> +/* If true then Xen was loaded by native EFI loader as PE application. */
> +extern bool_t efi_loader;
>  
>  #define EFI_INVALID_TABLE_ADDR (~0UL)
>  
> -- 
> 1.7.10.4
> 

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Stefano Stabellini]

On Fri, 30 Jan 2015, Daniel Kiper wrote:
> We need more fine grained knowledge about EFI environment and check
> for EFI platform and EFI loader separately to properly support
> multiboot2 protocol. In general Xen loaded by this protocol uses
> memory mappings and loaded modules in simliar way to Xen loaded
> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
> and efi_loader.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  xen/arch/x86/dmi_scan.c    |    4 ++--
>  xen/arch/x86/domain_page.c |    2 +-
>  xen/arch/x86/efi/stub.c    |    5 +++--
>  xen/arch/x86/mpparse.c     |    4 ++--
>  xen/arch/x86/setup.c       |    8 ++++----
>  xen/arch/x86/time.c        |    2 +-
>  xen/common/efi/boot.c      |    5 +++++
>  xen/common/efi/runtime.c   |    5 +++--
>  xen/drivers/acpi/osl.c     |    2 +-
>  xen/include/xen/efi.h      |    6 +++++-
>  10 files changed, 27 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
> index 500133a..63b976c 100644
> --- a/xen/arch/x86/dmi_scan.c
> +++ b/xen/arch/x86/dmi_scan.c
> @@ -150,7 +150,7 @@ int __init dmi_get_table(u32 *base, u32 *len)
>  	struct dmi_eps eps;
>  	char __iomem *p, *q;
>  
> -	if (efi_enabled) {
> +	if (efi_platform) {
>  		if (!efi_dmi_size)
>  			return -1;
>  		*base = efi_dmi_address;
> @@ -516,7 +516,7 @@ static void __init dmi_decode(struct dmi_header *dm)
>  
>  void __init dmi_scan_machine(void)
>  {
> -	if ((!efi_enabled ? dmi_iterate(dmi_decode) :
> +	if ((!efi_platform ? dmi_iterate(dmi_decode) :
>  	                    dmi_efi_iterate(dmi_decode)) == 0)
>   		dmi_check_system(dmi_blacklist);
>  	else
> diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
> index 158a164..5d4564c 100644
> --- a/xen/arch/x86/domain_page.c
> +++ b/xen/arch/x86/domain_page.c
> @@ -45,7 +45,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
>              sync_local_execstate();
>          /* We must now be running on the idle page table. */
>          ASSERT((cr3 = read_cr3()) == __pa(idle_pg_table) ||
> -               (efi_enabled && cr3 == efi_rs_page_table()));
> +               (efi_platform && cr3 == efi_rs_page_table()));
>      }
>  
>      return v;
> diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
> index b8f49f8..5060e6f 100644
> --- a/xen/arch/x86/efi/stub.c
> +++ b/xen/arch/x86/efi/stub.c
> @@ -3,8 +3,9 @@
>  #include <xen/init.h>
>  #include <xen/lib.h>
>  
> -#ifndef efi_enabled
> -const bool_t efi_enabled = 0;
> +#ifndef efi_platform
> +bool_t efi_platform = 0;
> +bool_t efi_loader = 0;
>  #endif
>  
>  void __init efi_init_memory(void) { }
> diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
> index a38e016..c4e3041 100644
> --- a/xen/arch/x86/mpparse.c
> +++ b/xen/arch/x86/mpparse.c
> @@ -540,7 +540,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
>  
>  static __init void efi_unmap_mpf(void)
>  {
> -	if (efi_enabled)
> +	if (efi_platform)
>  		__set_fixmap(FIX_EFI_MPF, 0, 0);
>  }
>  
> @@ -698,7 +698,7 @@ void __init find_smp_config (void)
>  {
>  	unsigned int address;
>  
> -	if (efi_enabled) {
> +	if (efi_platform) {
>  		efi_check_config();
>  		return;
>  	}
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index c27c49c..711fdb0 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -431,7 +431,7 @@ static void __init parse_video_info(void)
>      struct boot_video_info *bvi = &bootsym(boot_vid_info);
>  
>      /* The EFI loader fills vga_console_info directly. */
> -    if ( efi_enabled )
> +    if ( efi_platform )
>          return;
>  
>      if ( (bvi->orig_video_isVGA == 1) && (bvi->orig_video_mode == 3) )
> @@ -663,7 +663,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>      if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
>          panic("Misaligned CPU0 stack.");
>  
> -    if ( efi_enabled )
> +    if ( efi_loader )
>      {
>          set_pdx_range(xen_phys_start >> PAGE_SHIFT,
>                        (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
> @@ -774,7 +774,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>       * we can relocate the dom0 kernel and other multiboot modules. Also, on
>       * x86/64, we relocate Xen to higher memory.
>       */
> -    for ( i = 0; !efi_enabled && i < mbi->mods_count; i++ )
> +    for ( i = 0; !efi_loader && i < mbi->mods_count; i++ )
>      {
>          if ( mod[i].mod_start & (PAGE_SIZE - 1) )
>              panic("Bootloader didn't honor module alignment request.");
> @@ -962,7 +962,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>      if ( !xen_phys_start )
>          panic("Not enough memory to relocate Xen.");
> -    reserve_e820_ram(&boot_e820, efi_enabled ? mbi->mem_upper : __pa(&_start),
> +    reserve_e820_ram(&boot_e820, efi_loader ? mbi->mem_upper : __pa(&_start),
>                       __pa(&_end));
>  
>      /* Late kexec reservation (dynamic start address). */
> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> index 74c01e3..cdd17cb 100644
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -689,7 +689,7 @@ static unsigned long get_cmos_time(void)
>      static bool_t __read_mostly cmos_rtc_probe;
>      boolean_param("cmos-rtc-probe", cmos_rtc_probe);
>  
> -    if ( efi_enabled )
> +    if ( efi_platform )
>      {
>          res = efi_get_time();
>          if ( res )
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index ac6881e..8aafcfd 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -708,6 +708,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
>      char *option_str;
>      bool_t use_cfg_file;
>  
> +#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
> +    efi_platform = 1;
> +    efi_loader = 1;
> +#endif

What exactly needs to be implemented on ARM?  I thought that EFI ARM
support for Xen is pretty much complete.


>      efi_ih = ImageHandle;
>      efi_bs = SystemTable->BootServices;
>      efi_rs = SystemTable->RuntimeServices;
> diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
> index c840e08..b229c69 100644
> --- a/xen/common/efi/runtime.c
> +++ b/xen/common/efi/runtime.c
> @@ -11,13 +11,14 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
>  #ifndef COMPAT
>  
>  #ifdef CONFIG_ARM  /* Disabled until runtime services implemented */
> -const bool_t efi_enabled = 0;
> +const bool_t efi_platform = 0;
>  #else
>  # include <asm/i387.h>
>  # include <asm/xstate.h>
>  # include <public/platform.h>
>  
> -const bool_t efi_enabled = 1;
> +bool_t efi_platform = 0;
> +bool_t efi_loader = 0;
>  #endif
>  
>  unsigned int __read_mostly efi_num_ct;
> diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
> index 93c983c..b066459 100644
> --- a/xen/drivers/acpi/osl.c
> +++ b/xen/drivers/acpi/osl.c
> @@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list args)
>  
>  acpi_physical_address __init acpi_os_get_root_pointer(void)
>  {
> -	if (efi_enabled) {
> +	if (efi_platform) {
>  		if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
>  			return efi.acpi20;
>  		else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
> diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
> index 5e02724..54cd390 100644
> --- a/xen/include/xen/efi.h
> +++ b/xen/include/xen/efi.h
> @@ -5,7 +5,11 @@
>  #include <xen/types.h>
>  #endif
>  
> -extern const bool_t efi_enabled;
> +/* If true then Xen runs on EFI platform. */
> +extern bool_t efi_platform;
> +
> +/* If true then Xen was loaded by native EFI loader as PE application. */
> +extern bool_t efi_loader;
>  
>  #define EFI_INVALID_TABLE_ADDR (~0UL)
>  
> -- 
> 1.7.10.4
> 

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Roy Franz]

On Mon, Mar 2, 2015 at 9:21 AM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 30 Jan 2015, Daniel Kiper wrote:
>> We need more fine grained knowledge about EFI environment and check
>> for EFI platform and EFI loader separately to properly support
>> multiboot2 protocol. In general Xen loaded by this protocol uses
>> memory mappings and loaded modules in simliar way to Xen loaded
>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
>> and efi_loader.
>>
>> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>> ---
>>  xen/arch/x86/dmi_scan.c    |    4 ++--
>>  xen/arch/x86/domain_page.c |    2 +-
>>  xen/arch/x86/efi/stub.c    |    5 +++--
>>  xen/arch/x86/mpparse.c     |    4 ++--
>>  xen/arch/x86/setup.c       |    8 ++++----
>>  xen/arch/x86/time.c        |    2 +-
>>  xen/common/efi/boot.c      |    5 +++++
>>  xen/common/efi/runtime.c   |    5 +++--
>>  xen/drivers/acpi/osl.c     |    2 +-
>>  xen/include/xen/efi.h      |    6 +++++-
>>  10 files changed, 27 insertions(+), 16 deletions(-)
>>
>> diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
>> index 500133a..63b976c 100644
>> --- a/xen/arch/x86/dmi_scan.c
>> +++ b/xen/arch/x86/dmi_scan.c
>> @@ -150,7 +150,7 @@ int __init dmi_get_table(u32 *base, u32 *len)
>>       struct dmi_eps eps;
>>       char __iomem *p, *q;
>>
>> -     if (efi_enabled) {
>> +     if (efi_platform) {
>>               if (!efi_dmi_size)
>>                       return -1;
>>               *base = efi_dmi_address;
>> @@ -516,7 +516,7 @@ static void __init dmi_decode(struct dmi_header *dm)
>>
>>  void __init dmi_scan_machine(void)
>>  {
>> -     if ((!efi_enabled ? dmi_iterate(dmi_decode) :
>> +     if ((!efi_platform ? dmi_iterate(dmi_decode) :
>>                           dmi_efi_iterate(dmi_decode)) == 0)
>>               dmi_check_system(dmi_blacklist);
>>       else
>> diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
>> index 158a164..5d4564c 100644
>> --- a/xen/arch/x86/domain_page.c
>> +++ b/xen/arch/x86/domain_page.c
>> @@ -45,7 +45,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
>>              sync_local_execstate();
>>          /* We must now be running on the idle page table. */
>>          ASSERT((cr3 = read_cr3()) == __pa(idle_pg_table) ||
>> -               (efi_enabled && cr3 == efi_rs_page_table()));
>> +               (efi_platform && cr3 == efi_rs_page_table()));
>>      }
>>
>>      return v;
>> diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
>> index b8f49f8..5060e6f 100644
>> --- a/xen/arch/x86/efi/stub.c
>> +++ b/xen/arch/x86/efi/stub.c
>> @@ -3,8 +3,9 @@
>>  #include <xen/init.h>
>>  #include <xen/lib.h>
>>
>> -#ifndef efi_enabled
>> -const bool_t efi_enabled = 0;
>> +#ifndef efi_platform
>> +bool_t efi_platform = 0;
>> +bool_t efi_loader = 0;
>>  #endif
>>
>>  void __init efi_init_memory(void) { }
>> diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
>> index a38e016..c4e3041 100644
>> --- a/xen/arch/x86/mpparse.c
>> +++ b/xen/arch/x86/mpparse.c
>> @@ -540,7 +540,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
>>
>>  static __init void efi_unmap_mpf(void)
>>  {
>> -     if (efi_enabled)
>> +     if (efi_platform)
>>               __set_fixmap(FIX_EFI_MPF, 0, 0);
>>  }
>>
>> @@ -698,7 +698,7 @@ void __init find_smp_config (void)
>>  {
>>       unsigned int address;
>>
>> -     if (efi_enabled) {
>> +     if (efi_platform) {
>>               efi_check_config();
>>               return;
>>       }
>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>> index c27c49c..711fdb0 100644
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -431,7 +431,7 @@ static void __init parse_video_info(void)
>>      struct boot_video_info *bvi = &bootsym(boot_vid_info);
>>
>>      /* The EFI loader fills vga_console_info directly. */
>> -    if ( efi_enabled )
>> +    if ( efi_platform )
>>          return;
>>
>>      if ( (bvi->orig_video_isVGA == 1) && (bvi->orig_video_mode == 3) )
>> @@ -663,7 +663,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>      if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
>>          panic("Misaligned CPU0 stack.");
>>
>> -    if ( efi_enabled )
>> +    if ( efi_loader )
>>      {
>>          set_pdx_range(xen_phys_start >> PAGE_SHIFT,
>>                        (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
>> @@ -774,7 +774,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>       * we can relocate the dom0 kernel and other multiboot modules. Also, on
>>       * x86/64, we relocate Xen to higher memory.
>>       */
>> -    for ( i = 0; !efi_enabled && i < mbi->mods_count; i++ )
>> +    for ( i = 0; !efi_loader && i < mbi->mods_count; i++ )
>>      {
>>          if ( mod[i].mod_start & (PAGE_SIZE - 1) )
>>              panic("Bootloader didn't honor module alignment request.");
>> @@ -962,7 +962,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>
>>      if ( !xen_phys_start )
>>          panic("Not enough memory to relocate Xen.");
>> -    reserve_e820_ram(&boot_e820, efi_enabled ? mbi->mem_upper : __pa(&_start),
>> +    reserve_e820_ram(&boot_e820, efi_loader ? mbi->mem_upper : __pa(&_start),
>>                       __pa(&_end));
>>
>>      /* Late kexec reservation (dynamic start address). */
>> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
>> index 74c01e3..cdd17cb 100644
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -689,7 +689,7 @@ static unsigned long get_cmos_time(void)
>>      static bool_t __read_mostly cmos_rtc_probe;
>>      boolean_param("cmos-rtc-probe", cmos_rtc_probe);
>>
>> -    if ( efi_enabled )
>> +    if ( efi_platform )
>>      {
>>          res = efi_get_time();
>>          if ( res )
>> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
>> index ac6881e..8aafcfd 100644
>> --- a/xen/common/efi/boot.c
>> +++ b/xen/common/efi/boot.c
>> @@ -708,6 +708,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
>>      char *option_str;
>>      bool_t use_cfg_file;
>>
>> +#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
>> +    efi_platform = 1;
>> +    efi_loader = 1;
>> +#endif
>
> What exactly needs to be implemented on ARM?  I thought that EFI ARM
> support for Xen is pretty much complete.
>
EFI runtime services support has not been implemented for ARM.
I'll have to look to see how efi_platform and efi_loader relate to
that, I don't know off hand.

>
>>      efi_ih = ImageHandle;
>>      efi_bs = SystemTable->BootServices;
>>      efi_rs = SystemTable->RuntimeServices;
>> diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
>> index c840e08..b229c69 100644
>> --- a/xen/common/efi/runtime.c
>> +++ b/xen/common/efi/runtime.c
>> @@ -11,13 +11,14 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
>>  #ifndef COMPAT
>>
>>  #ifdef CONFIG_ARM  /* Disabled until runtime services implemented */
>> -const bool_t efi_enabled = 0;
>> +const bool_t efi_platform = 0;
>>  #else
>>  # include <asm/i387.h>
>>  # include <asm/xstate.h>
>>  # include <public/platform.h>
>>
>> -const bool_t efi_enabled = 1;
>> +bool_t efi_platform = 0;
>> +bool_t efi_loader = 0;
>>  #endif
>>
>>  unsigned int __read_mostly efi_num_ct;
>> diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
>> index 93c983c..b066459 100644
>> --- a/xen/drivers/acpi/osl.c
>> +++ b/xen/drivers/acpi/osl.c
>> @@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list args)
>>
>>  acpi_physical_address __init acpi_os_get_root_pointer(void)
>>  {
>> -     if (efi_enabled) {
>> +     if (efi_platform) {
>>               if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
>>                       return efi.acpi20;
>>               else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
>> diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
>> index 5e02724..54cd390 100644
>> --- a/xen/include/xen/efi.h
>> +++ b/xen/include/xen/efi.h
>> @@ -5,7 +5,11 @@
>>  #include <xen/types.h>
>>  #endif
>>
>> -extern const bool_t efi_enabled;
>> +/* If true then Xen runs on EFI platform. */
>> +extern bool_t efi_platform;
>> +
>> +/* If true then Xen was loaded by native EFI loader as PE application. */
>> +extern bool_t efi_loader;
>>
>>  #define EFI_INVALID_TABLE_ADDR (~0UL)
>>
>> --
>> 1.7.10.4
>>

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Roy Franz]

On Mon, Mar 2, 2015 at 10:43 AM, Roy Franz <roy.franz@linaro.org> wrote:
> On Mon, Mar 2, 2015 at 9:21 AM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Fri, 30 Jan 2015, Daniel Kiper wrote:
>>> We need more fine grained knowledge about EFI environment and check
>>> for EFI platform and EFI loader separately to properly support
>>> multiboot2 protocol. In general Xen loaded by this protocol uses
>>> memory mappings and loaded modules in simliar way to Xen loaded
>>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
>>> and efi_loader.
>>>
>>> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>>> ---
>>>  xen/arch/x86/dmi_scan.c    |    4 ++--
>>>  xen/arch/x86/domain_page.c |    2 +-
>>>  xen/arch/x86/efi/stub.c    |    5 +++--
>>>  xen/arch/x86/mpparse.c     |    4 ++--
>>>  xen/arch/x86/setup.c       |    8 ++++----
>>>  xen/arch/x86/time.c        |    2 +-
>>>  xen/common/efi/boot.c      |    5 +++++
>>>  xen/common/efi/runtime.c   |    5 +++--
>>>  xen/drivers/acpi/osl.c     |    2 +-
>>>  xen/include/xen/efi.h      |    6 +++++-
>>>  10 files changed, 27 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
>>> index 500133a..63b976c 100644
>>> --- a/xen/arch/x86/dmi_scan.c
>>> +++ b/xen/arch/x86/dmi_scan.c
>>> @@ -150,7 +150,7 @@ int __init dmi_get_table(u32 *base, u32 *len)
>>>       struct dmi_eps eps;
>>>       char __iomem *p, *q;
>>>
>>> -     if (efi_enabled) {
>>> +     if (efi_platform) {
>>>               if (!efi_dmi_size)
>>>                       return -1;
>>>               *base = efi_dmi_address;
>>> @@ -516,7 +516,7 @@ static void __init dmi_decode(struct dmi_header *dm)
>>>
>>>  void __init dmi_scan_machine(void)
>>>  {
>>> -     if ((!efi_enabled ? dmi_iterate(dmi_decode) :
>>> +     if ((!efi_platform ? dmi_iterate(dmi_decode) :
>>>                           dmi_efi_iterate(dmi_decode)) == 0)
>>>               dmi_check_system(dmi_blacklist);
>>>       else
>>> diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
>>> index 158a164..5d4564c 100644
>>> --- a/xen/arch/x86/domain_page.c
>>> +++ b/xen/arch/x86/domain_page.c
>>> @@ -45,7 +45,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
>>>              sync_local_execstate();
>>>          /* We must now be running on the idle page table. */
>>>          ASSERT((cr3 = read_cr3()) == __pa(idle_pg_table) ||
>>> -               (efi_enabled && cr3 == efi_rs_page_table()));
>>> +               (efi_platform && cr3 == efi_rs_page_table()));
>>>      }
>>>
>>>      return v;
>>> diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
>>> index b8f49f8..5060e6f 100644
>>> --- a/xen/arch/x86/efi/stub.c
>>> +++ b/xen/arch/x86/efi/stub.c
>>> @@ -3,8 +3,9 @@
>>>  #include <xen/init.h>
>>>  #include <xen/lib.h>
>>>
>>> -#ifndef efi_enabled
>>> -const bool_t efi_enabled = 0;
>>> +#ifndef efi_platform
>>> +bool_t efi_platform = 0;
>>> +bool_t efi_loader = 0;
>>>  #endif
>>>
>>>  void __init efi_init_memory(void) { }
>>> diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
>>> index a38e016..c4e3041 100644
>>> --- a/xen/arch/x86/mpparse.c
>>> +++ b/xen/arch/x86/mpparse.c
>>> @@ -540,7 +540,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
>>>
>>>  static __init void efi_unmap_mpf(void)
>>>  {
>>> -     if (efi_enabled)
>>> +     if (efi_platform)
>>>               __set_fixmap(FIX_EFI_MPF, 0, 0);
>>>  }
>>>
>>> @@ -698,7 +698,7 @@ void __init find_smp_config (void)
>>>  {
>>>       unsigned int address;
>>>
>>> -     if (efi_enabled) {
>>> +     if (efi_platform) {
>>>               efi_check_config();
>>>               return;
>>>       }
>>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>>> index c27c49c..711fdb0 100644
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -431,7 +431,7 @@ static void __init parse_video_info(void)
>>>      struct boot_video_info *bvi = &bootsym(boot_vid_info);
>>>
>>>      /* The EFI loader fills vga_console_info directly. */
>>> -    if ( efi_enabled )
>>> +    if ( efi_platform )
>>>          return;
>>>
>>>      if ( (bvi->orig_video_isVGA == 1) && (bvi->orig_video_mode == 3) )
>>> @@ -663,7 +663,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>>      if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
>>>          panic("Misaligned CPU0 stack.");
>>>
>>> -    if ( efi_enabled )
>>> +    if ( efi_loader )
>>>      {
>>>          set_pdx_range(xen_phys_start >> PAGE_SHIFT,
>>>                        (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
>>> @@ -774,7 +774,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>>       * we can relocate the dom0 kernel and other multiboot modules. Also, on
>>>       * x86/64, we relocate Xen to higher memory.
>>>       */
>>> -    for ( i = 0; !efi_enabled && i < mbi->mods_count; i++ )
>>> +    for ( i = 0; !efi_loader && i < mbi->mods_count; i++ )
>>>      {
>>>          if ( mod[i].mod_start & (PAGE_SIZE - 1) )
>>>              panic("Bootloader didn't honor module alignment request.");
>>> @@ -962,7 +962,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>>
>>>      if ( !xen_phys_start )
>>>          panic("Not enough memory to relocate Xen.");
>>> -    reserve_e820_ram(&boot_e820, efi_enabled ? mbi->mem_upper : __pa(&_start),
>>> +    reserve_e820_ram(&boot_e820, efi_loader ? mbi->mem_upper : __pa(&_start),
>>>                       __pa(&_end));
>>>
>>>      /* Late kexec reservation (dynamic start address). */
>>> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
>>> index 74c01e3..cdd17cb 100644
>>> --- a/xen/arch/x86/time.c
>>> +++ b/xen/arch/x86/time.c
>>> @@ -689,7 +689,7 @@ static unsigned long get_cmos_time(void)
>>>      static bool_t __read_mostly cmos_rtc_probe;
>>>      boolean_param("cmos-rtc-probe", cmos_rtc_probe);
>>>
>>> -    if ( efi_enabled )
>>> +    if ( efi_platform )
>>>      {
>>>          res = efi_get_time();
>>>          if ( res )
>>> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
>>> index ac6881e..8aafcfd 100644
>>> --- a/xen/common/efi/boot.c
>>> +++ b/xen/common/efi/boot.c
>>> @@ -708,6 +708,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
>>>      char *option_str;
>>>      bool_t use_cfg_file;
>>>
>>> +#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
>>> +    efi_platform = 1;
>>> +    efi_loader = 1;
>>> +#endif
>>
>> What exactly needs to be implemented on ARM?  I thought that EFI ARM
>> support for Xen is pretty much complete.
>>
> EFI runtime services support has not been implemented for ARM.
> I'll have to look to see how efi_platform and efi_loader relate to
> that, I don't know off hand.
>
Reviewing the #ifndef CONFIG_ARM in EFI code, and the efi_enabled
usage elsewhere,
the remaining EFI tasks on ARM look like:
* Support for SetVirtualAddressMap
* Runtime service support - looks like just time function used by x86
in get_cmos_time()
Not strictly EFI, but related:
* Lookup of ACPI tables
* Lookup of SMBIOS tables

Roy

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Roy Franz]

On Mon, Mar 2, 2015 at 10:43 AM, Roy Franz <roy.franz@linaro.org> wrote:
> On Mon, Mar 2, 2015 at 9:21 AM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
>> On Fri, 30 Jan 2015, Daniel Kiper wrote:
>>> We need more fine grained knowledge about EFI environment and check
>>> for EFI platform and EFI loader separately to properly support
>>> multiboot2 protocol. In general Xen loaded by this protocol uses
>>> memory mappings and loaded modules in simliar way to Xen loaded
>>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
>>> and efi_loader.
>>>
>>> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>>> ---
>>>  xen/arch/x86/dmi_scan.c    |    4 ++--
>>>  xen/arch/x86/domain_page.c |    2 +-
>>>  xen/arch/x86/efi/stub.c    |    5 +++--
>>>  xen/arch/x86/mpparse.c     |    4 ++--
>>>  xen/arch/x86/setup.c       |    8 ++++----
>>>  xen/arch/x86/time.c        |    2 +-
>>>  xen/common/efi/boot.c      |    5 +++++
>>>  xen/common/efi/runtime.c   |    5 +++--
>>>  xen/drivers/acpi/osl.c     |    2 +-
>>>  xen/include/xen/efi.h      |    6 +++++-
>>>  10 files changed, 27 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
>>> index 500133a..63b976c 100644
>>> --- a/xen/arch/x86/dmi_scan.c
>>> +++ b/xen/arch/x86/dmi_scan.c
>>> @@ -150,7 +150,7 @@ int __init dmi_get_table(u32 *base, u32 *len)
>>>       struct dmi_eps eps;
>>>       char __iomem *p, *q;
>>>
>>> -     if (efi_enabled) {
>>> +     if (efi_platform) {
>>>               if (!efi_dmi_size)
>>>                       return -1;
>>>               *base = efi_dmi_address;
>>> @@ -516,7 +516,7 @@ static void __init dmi_decode(struct dmi_header *dm)
>>>
>>>  void __init dmi_scan_machine(void)
>>>  {
>>> -     if ((!efi_enabled ? dmi_iterate(dmi_decode) :
>>> +     if ((!efi_platform ? dmi_iterate(dmi_decode) :
>>>                           dmi_efi_iterate(dmi_decode)) == 0)
>>>               dmi_check_system(dmi_blacklist);
>>>       else
>>> diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
>>> index 158a164..5d4564c 100644
>>> --- a/xen/arch/x86/domain_page.c
>>> +++ b/xen/arch/x86/domain_page.c
>>> @@ -45,7 +45,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
>>>              sync_local_execstate();
>>>          /* We must now be running on the idle page table. */
>>>          ASSERT((cr3 = read_cr3()) == __pa(idle_pg_table) ||
>>> -               (efi_enabled && cr3 == efi_rs_page_table()));
>>> +               (efi_platform && cr3 == efi_rs_page_table()));
>>>      }
>>>
>>>      return v;
>>> diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
>>> index b8f49f8..5060e6f 100644
>>> --- a/xen/arch/x86/efi/stub.c
>>> +++ b/xen/arch/x86/efi/stub.c
>>> @@ -3,8 +3,9 @@
>>>  #include <xen/init.h>
>>>  #include <xen/lib.h>
>>>
>>> -#ifndef efi_enabled
>>> -const bool_t efi_enabled = 0;
>>> +#ifndef efi_platform
>>> +bool_t efi_platform = 0;
>>> +bool_t efi_loader = 0;
>>>  #endif
>>>
>>>  void __init efi_init_memory(void) { }
>>> diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
>>> index a38e016..c4e3041 100644
>>> --- a/xen/arch/x86/mpparse.c
>>> +++ b/xen/arch/x86/mpparse.c
>>> @@ -540,7 +540,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
>>>
>>>  static __init void efi_unmap_mpf(void)
>>>  {
>>> -     if (efi_enabled)
>>> +     if (efi_platform)
>>>               __set_fixmap(FIX_EFI_MPF, 0, 0);
>>>  }
>>>
>>> @@ -698,7 +698,7 @@ void __init find_smp_config (void)
>>>  {
>>>       unsigned int address;
>>>
>>> -     if (efi_enabled) {
>>> +     if (efi_platform) {
>>>               efi_check_config();
>>>               return;
>>>       }
>>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>>> index c27c49c..711fdb0 100644
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -431,7 +431,7 @@ static void __init parse_video_info(void)
>>>      struct boot_video_info *bvi = &bootsym(boot_vid_info);
>>>
>>>      /* The EFI loader fills vga_console_info directly. */
>>> -    if ( efi_enabled )
>>> +    if ( efi_platform )
>>>          return;
>>>
>>>      if ( (bvi->orig_video_isVGA == 1) && (bvi->orig_video_mode == 3) )
>>> @@ -663,7 +663,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>>      if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
>>>          panic("Misaligned CPU0 stack.");
>>>
>>> -    if ( efi_enabled )
>>> +    if ( efi_loader )
>>>      {
>>>          set_pdx_range(xen_phys_start >> PAGE_SHIFT,
>>>                        (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
>>> @@ -774,7 +774,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>>       * we can relocate the dom0 kernel and other multiboot modules. Also, on
>>>       * x86/64, we relocate Xen to higher memory.
>>>       */
>>> -    for ( i = 0; !efi_enabled && i < mbi->mods_count; i++ )
>>> +    for ( i = 0; !efi_loader && i < mbi->mods_count; i++ )
>>>      {
>>>          if ( mod[i].mod_start & (PAGE_SIZE - 1) )
>>>              panic("Bootloader didn't honor module alignment request.");
>>> @@ -962,7 +962,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>>
>>>      if ( !xen_phys_start )
>>>          panic("Not enough memory to relocate Xen.");
>>> -    reserve_e820_ram(&boot_e820, efi_enabled ? mbi->mem_upper : __pa(&_start),
>>> +    reserve_e820_ram(&boot_e820, efi_loader ? mbi->mem_upper : __pa(&_start),
>>>                       __pa(&_end));
>>>
>>>      /* Late kexec reservation (dynamic start address). */
>>> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
>>> index 74c01e3..cdd17cb 100644
>>> --- a/xen/arch/x86/time.c
>>> +++ b/xen/arch/x86/time.c
>>> @@ -689,7 +689,7 @@ static unsigned long get_cmos_time(void)
>>>      static bool_t __read_mostly cmos_rtc_probe;
>>>      boolean_param("cmos-rtc-probe", cmos_rtc_probe);
>>>
>>> -    if ( efi_enabled )
>>> +    if ( efi_platform )
>>>      {
>>>          res = efi_get_time();
>>>          if ( res )
>>> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
>>> index ac6881e..8aafcfd 100644
>>> --- a/xen/common/efi/boot.c
>>> +++ b/xen/common/efi/boot.c
>>> @@ -708,6 +708,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
>>>      char *option_str;
>>>      bool_t use_cfg_file;
>>>
>>> +#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
>>> +    efi_platform = 1;
>>> +    efi_loader = 1;
>>> +#endif
>>
>> What exactly needs to be implemented on ARM?  I thought that EFI ARM
>> support for Xen is pretty much complete.
>>
> EFI runtime services support has not been implemented for ARM.
> I'll have to look to see how efi_platform and efi_loader relate to
> that, I don't know off hand.
>
Reviewing the #ifndef CONFIG_ARM in EFI code, and the efi_enabled
usage elsewhere,
the remaining EFI tasks on ARM look like:
* Support for SetVirtualAddressMap
* Runtime service support - looks like just time function used by x86
in get_cmos_time()
Not strictly EFI, but related:
* Lookup of ACPI tables
* Lookup of SMBIOS tables

Roy

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Jan Beulich]

>>> On 03.03.15 at 00:40, <roy.franz@linaro.org> wrote:
> Reviewing the #ifndef CONFIG_ARM in EFI code, and the efi_enabled
> usage elsewhere,
> the remaining EFI tasks on ARM look like:
> * Support for SetVirtualAddressMap
> * Runtime service support - looks like just time function used by x86
> in get_cmos_time()

* Provide runtime service access for Dom0

Jan

> Not strictly EFI, but related:
> * Lookup of ACPI tables
> * Lookup of SMBIOS tables
> 
> Roy

Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Jan Beulich]

>>> On 03.03.15 at 00:40, <roy.franz@linaro.org> wrote:
> Reviewing the #ifndef CONFIG_ARM in EFI code, and the efi_enabled
> usage elsewhere,
> the remaining EFI tasks on ARM look like:
> * Support for SetVirtualAddressMap
> * Runtime service support - looks like just time function used by x86
> in get_cmos_time()

* Provide runtime service access for Dom0

Jan

> Not strictly EFI, but related:
> * Lookup of ACPI tables
> * Lookup of SMBIOS tables
> 
> Roy

[PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Daniel Kiper]

We need more fine grained knowledge about EFI environment and check
for EFI platform and EFI loader separately to properly support
multiboot2 protocol. In general Xen loaded by this protocol uses
memory mappings and loaded modules in simliar way to Xen loaded
by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
and efi_loader.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/arch/x86/dmi_scan.c    |    4 ++--
 xen/arch/x86/domain_page.c |    2 +-
 xen/arch/x86/efi/stub.c    |    5 +++--
 xen/arch/x86/mpparse.c     |    4 ++--
 xen/arch/x86/setup.c       |    8 ++++----
 xen/arch/x86/time.c        |    2 +-
 xen/common/efi/boot.c      |    5 +++++
 xen/common/efi/runtime.c   |    5 +++--
 xen/drivers/acpi/osl.c     |    2 +-
 xen/include/xen/efi.h      |    6 +++++-
 10 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
index 500133a..63b976c 100644
--- a/xen/arch/x86/dmi_scan.c
+++ b/xen/arch/x86/dmi_scan.c
@@ -150,7 +150,7 @@ int __init dmi_get_table(u32 *base, u32 *len)
 	struct dmi_eps eps;
 	char __iomem *p, *q;
 
-	if (efi_enabled) {
+	if (efi_platform) {
 		if (!efi_dmi_size)
 			return -1;
 		*base = efi_dmi_address;
@@ -516,7 +516,7 @@ static void __init dmi_decode(struct dmi_header *dm)
 
 void __init dmi_scan_machine(void)
 {
-	if ((!efi_enabled ? dmi_iterate(dmi_decode) :
+	if ((!efi_platform ? dmi_iterate(dmi_decode) :
 	                    dmi_efi_iterate(dmi_decode)) == 0)
  		dmi_check_system(dmi_blacklist);
 	else
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 158a164..5d4564c 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -45,7 +45,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
             sync_local_execstate();
         /* We must now be running on the idle page table. */
         ASSERT((cr3 = read_cr3()) == __pa(idle_pg_table) ||
-               (efi_enabled && cr3 == efi_rs_page_table()));
+               (efi_platform && cr3 == efi_rs_page_table()));
     }
 
     return v;
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
index b8f49f8..5060e6f 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -3,8 +3,9 @@
 #include <xen/init.h>
 #include <xen/lib.h>
 
-#ifndef efi_enabled
-const bool_t efi_enabled = 0;
+#ifndef efi_platform
+bool_t efi_platform = 0;
+bool_t efi_loader = 0;
 #endif
 
 void __init efi_init_memory(void) { }
diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
index a38e016..c4e3041 100644
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -540,7 +540,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
 
 static __init void efi_unmap_mpf(void)
 {
-	if (efi_enabled)
+	if (efi_platform)
 		__set_fixmap(FIX_EFI_MPF, 0, 0);
 }
 
@@ -698,7 +698,7 @@ void __init find_smp_config (void)
 {
 	unsigned int address;
 
-	if (efi_enabled) {
+	if (efi_platform) {
 		efi_check_config();
 		return;
 	}
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index c27c49c..711fdb0 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -431,7 +431,7 @@ static void __init parse_video_info(void)
     struct boot_video_info *bvi = &bootsym(boot_vid_info);
 
     /* The EFI loader fills vga_console_info directly. */
-    if ( efi_enabled )
+    if ( efi_platform )
         return;
 
     if ( (bvi->orig_video_isVGA == 1) && (bvi->orig_video_mode == 3) )
@@ -663,7 +663,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
         panic("Misaligned CPU0 stack.");
 
-    if ( efi_enabled )
+    if ( efi_loader )
     {
         set_pdx_range(xen_phys_start >> PAGE_SHIFT,
                       (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
@@ -774,7 +774,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
      * we can relocate the dom0 kernel and other multiboot modules. Also, on
      * x86/64, we relocate Xen to higher memory.
      */
-    for ( i = 0; !efi_enabled && i < mbi->mods_count; i++ )
+    for ( i = 0; !efi_loader && i < mbi->mods_count; i++ )
     {
         if ( mod[i].mod_start & (PAGE_SIZE - 1) )
             panic("Bootloader didn't honor module alignment request.");
@@ -962,7 +962,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
     if ( !xen_phys_start )
         panic("Not enough memory to relocate Xen.");
-    reserve_e820_ram(&boot_e820, efi_enabled ? mbi->mem_upper : __pa(&_start),
+    reserve_e820_ram(&boot_e820, efi_loader ? mbi->mem_upper : __pa(&_start),
                      __pa(&_end));
 
     /* Late kexec reservation (dynamic start address). */
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 74c01e3..cdd17cb 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -689,7 +689,7 @@ static unsigned long get_cmos_time(void)
     static bool_t __read_mostly cmos_rtc_probe;
     boolean_param("cmos-rtc-probe", cmos_rtc_probe);
 
-    if ( efi_enabled )
+    if ( efi_platform )
     {
         res = efi_get_time();
         if ( res )
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index ac6881e..8aafcfd 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -708,6 +708,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     char *option_str;
     bool_t use_cfg_file;
 
+#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
+    efi_platform = 1;
+    efi_loader = 1;
+#endif
+
     efi_ih = ImageHandle;
     efi_bs = SystemTable->BootServices;
     efi_rs = SystemTable->RuntimeServices;
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index c840e08..b229c69 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -11,13 +11,14 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
 #ifndef COMPAT
 
 #ifdef CONFIG_ARM  /* Disabled until runtime services implemented */
-const bool_t efi_enabled = 0;
+const bool_t efi_platform = 0;
 #else
 # include <asm/i387.h>
 # include <asm/xstate.h>
 # include <public/platform.h>
 
-const bool_t efi_enabled = 1;
+bool_t efi_platform = 0;
+bool_t efi_loader = 0;
 #endif
 
 unsigned int __read_mostly efi_num_ct;
diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index 93c983c..b066459 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list args)
 
 acpi_physical_address __init acpi_os_get_root_pointer(void)
 {
-	if (efi_enabled) {
+	if (efi_platform) {
 		if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
 			return efi.acpi20;
 		else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index 5e02724..54cd390 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -5,7 +5,11 @@
 #include <xen/types.h>
 #endif
 
-extern const bool_t efi_enabled;
+/* If true then Xen runs on EFI platform. */
+extern bool_t efi_platform;
+
+/* If true then Xen was loaded by native EFI loader as PE application. */
+extern bool_t efi_loader;
 
 #define EFI_INVALID_TABLE_ADDR (~0UL)
 
-- 
1.7.10.4

[PATCH 06/18] x86: remove commented out stale references to efi_enabled

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/arch/x86/e820.c |   29 ++++++++++-------------------
 1 file changed, 10 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index bf84bae..47920a3 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -74,20 +74,18 @@ static void __init add_memory_region(unsigned long long start,
 {
     int x;
 
-    /*if (!efi_enabled)*/ {
-        x = e820.nr_map;
+    x = e820.nr_map;
 
-        if (x == E820MAX) {
-            printk(KERN_ERR "Ooops! Too many entries in the memory map!\n");
-            return;
-        }
-
-        e820.map[x].addr = start;
-        e820.map[x].size = size;
-        e820.map[x].type = type;
-        e820.nr_map++;
+    if (x == E820MAX) {
+        printk(KERN_ERR "Ooops! Too many entries in the memory map!\n");
+        return;
     }
-} /* add_memory_region */
+
+    e820.map[x].addr = start;
+    e820.map[x].size = size;
+    e820.map[x].type = type;
+    e820.nr_map++;
+}
 
 static void __init print_e820_memory_map(struct e820entry *map, unsigned int entries)
 {
@@ -349,13 +347,6 @@ static unsigned long __init find_max_pfn(void)
     int i;
     unsigned long max_pfn = 0;
 
-#if 0
-    if (efi_enabled) {
-        efi_memmap_walk(efi_find_max_pfn, &max_pfn);
-        return;
-    }
-#endif
-
     for (i = 0; i < e820.nr_map; i++) {
         unsigned long start, end;
         /* RAM? */
-- 
1.7.10.4

[PATCH 07/18] efi: run EFI specific code on EFI platform only

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/arch/x86/shutdown.c  |    3 ++-
 xen/common/efi/boot.c    |    5 +++++
 xen/common/efi/runtime.c |    6 ++++++
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
index 21f6cf5..1c8336f 100644
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -504,7 +504,8 @@ void machine_restart(unsigned int delay_millisecs)
         tboot_shutdown(TB_SHUTDOWN_REBOOT);
     }
 
-    efi_reset_system(reboot_mode != 0);
+    if ( efi_platform )
+        efi_reset_system(reboot_mode != 0);
 
     /* Rebooting needs to touch the page at absolute address 0. */
     *((unsigned short *)__va(0x472)) = reboot_mode;
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 8aafcfd..89d081d 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1154,6 +1154,11 @@ void __init efi_init_memory(void)
     } *extra, *extra_head = NULL;
 #endif
 
+#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
+    if ( !efi_platform )
+        return;
+#endif
+
     printk(XENLOG_INFO "EFI memory map:\n");
     for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size )
     {
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index b229c69..7c767e4 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -164,6 +164,9 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
 {
     unsigned int i, n;
 
+    if ( !efi_platform )
+        return -ENOSYS;
+
     switch ( idx )
     {
     case XEN_FW_EFI_VERSION:
@@ -298,6 +301,9 @@ int efi_runtime_call(struct xenpf_efi_runtime_call *op)
     EFI_STATUS status = EFI_NOT_STARTED;
     int rc = 0;
 
+    if ( !efi_platform )
+        return -ENOSYS;
+
     switch ( op->function )
     {
     case XEN_EFI_get_time:
-- 
1.7.10.4

Re: [PATCH 07/18] efi: run EFI specific code on EFI platform only

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> --- a/xen/arch/x86/shutdown.c
> +++ b/xen/arch/x86/shutdown.c
> @@ -504,7 +504,8 @@ void machine_restart(unsigned int delay_millisecs)
>          tboot_shutdown(TB_SHUTDOWN_REBOOT);
>      }
>  
> -    efi_reset_system(reboot_mode != 0);
> +    if ( efi_platform )
> +        efi_reset_system(reboot_mode != 0);

Please sync with Konrad on this one - it's supposed to get moved
and conditionalized anyway.

> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1154,6 +1154,11 @@ void __init efi_init_memory(void)
>      } *extra, *extra_head = NULL;
>  #endif
>  
> +#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
> +    if ( !efi_platform )
> +        return;
> +#endif

At least for this one I'd rather see the call site to have the
conditional.

> --- a/xen/common/efi/runtime.c
> +++ b/xen/common/efi/runtime.c
> @@ -164,6 +164,9 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
>  {
>      unsigned int i, n;
>  
> +    if ( !efi_platform )
> +        return -ENOSYS;
> +
>      switch ( idx )
>      {
>      case XEN_FW_EFI_VERSION:
> @@ -298,6 +301,9 @@ int efi_runtime_call(struct xenpf_efi_runtime_call *op)
>      EFI_STATUS status = EFI_NOT_STARTED;
>      int rc = 0;
>  
> +    if ( !efi_platform )
> +        return -ENOSYS;

EOPNOTSUPP in both cases please, consistent with when runtime
service use is disabled.

Jan

Re: [PATCH 07/18] efi: run EFI specific code on EFI platform only

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> --- a/xen/arch/x86/shutdown.c
> +++ b/xen/arch/x86/shutdown.c
> @@ -504,7 +504,8 @@ void machine_restart(unsigned int delay_millisecs)
>          tboot_shutdown(TB_SHUTDOWN_REBOOT);
>      }
>  
> -    efi_reset_system(reboot_mode != 0);
> +    if ( efi_platform )
> +        efi_reset_system(reboot_mode != 0);

Please sync with Konrad on this one - it's supposed to get moved
and conditionalized anyway.

> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1154,6 +1154,11 @@ void __init efi_init_memory(void)
>      } *extra, *extra_head = NULL;
>  #endif
>  
> +#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
> +    if ( !efi_platform )
> +        return;
> +#endif

At least for this one I'd rather see the call site to have the
conditional.

> --- a/xen/common/efi/runtime.c
> +++ b/xen/common/efi/runtime.c
> @@ -164,6 +164,9 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
>  {
>      unsigned int i, n;
>  
> +    if ( !efi_platform )
> +        return -ENOSYS;
> +
>      switch ( idx )
>      {
>      case XEN_FW_EFI_VERSION:
> @@ -298,6 +301,9 @@ int efi_runtime_call(struct xenpf_efi_runtime_call *op)
>      EFI_STATUS status = EFI_NOT_STARTED;
>      int rc = 0;
>  
> +    if ( !efi_platform )
> +        return -ENOSYS;

EOPNOTSUPP in both cases please, consistent with when runtime
service use is disabled.

Jan

[PATCH 08/18] efi: build xen.gz with EFI code

[Daniel Kiper]

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
it must contain "linear" (or "flat") representation of code and data.
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
xen.efi further diverge from xen ELF file (in terms of contents and
build method). ELF have 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 finaly we
can generate xen.efi directly from xen ELF using just simple objcopy.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/arch/x86/Makefile     |   17 +++++++----------
 xen/arch/x86/efi/Makefile |   12 ++++++------
 xen/arch/x86/efi/stub.c   |   42 ------------------------------------------
 xen/arch/x86/xen.lds.S    |    2 --
 4 files changed, 13 insertions(+), 60 deletions(-)
 delete mode 100644 xen/arch/x86/efi/stub.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 86ca5f8..5d63a1f 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -88,29 +88,29 @@ prelink-efi_lto.o: $(ALL_OBJS) efi/runtime.o efi/compat.o
 prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
 	$(LD) $(LDFLAGS) -r -o $@ $^
 
-prelink-efi.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink-efi_lto.o efi/boot.init.o
+prelink-efi.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink-efi_lto.o
 	$(guard) $(LD) $(LDFLAGS) -r -o $@ $^
 else
 prelink.o: $(ALL_OBJS)
 	$(LD) $(LDFLAGS) -r -o $@ $^
 
-prelink-efi.o: $(ALL_OBJS) efi/boot.init.o efi/runtime.o efi/compat.o
-	$(guard) $(LD) $(LDFLAGS) -r -o $@ $(filter-out %/efi/built_in.o,$^)
+prelink-efi.o: $(ALL_OBJS)
+	$(guard) $(LD) $(LDFLAGS) -r -o $@ $^
 endif
 
 $(BASEDIR)/common/symbols-dummy.o:
 	$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
 
-$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
-	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o efi/relocs-dummy.o
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o efi/relocs-dummy.o \
 	    $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
 	$(NM) -n $(@D)/.$(@F).0 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).0.S
 	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
-	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o efi/relocs-dummy.o \
 	    $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
 	$(NM) -n $(@D)/.$(@F).1 | $(BASEDIR)/tools/symbols >$(@D)/.$(@F).1.S
 	$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
-	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+	$(LD) $(LDFLAGS) -T xen.lds -N prelink.o efi/relocs-dummy.o \
 	    $(@D)/.$(@F).1.o -o $@
 	rm -f $(@D)/.$(@F).[0-9]*
 
@@ -144,9 +144,6 @@ $(TARGET).efi: prelink-efi.o efi.lds efi/relocs-dummy.o $(BASEDIR)/common/symbol
 	if $(guard) false; then rm -f $@; echo 'EFI support disabled'; fi
 	rm -f $(@D)/.$(@F).[0-9]*
 
-efi/boot.init.o efi/runtime.o efi/compat.o: $(BASEDIR)/arch/x86/efi/built_in.o
-efi/boot.init.o efi/runtime.o efi/compat.o: ;
-
 asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
 	$(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
 
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 1daa7ac..13e59dc 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,14 +1,14 @@
 CFLAGS += -fshort-wchar
 
-obj-y += stub.o
+obj-y += boot.o
+obj-y += compat.o
+obj-y += runtime.o
+
+extra-y += relocs-dummy.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)))
-
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o
-
-stub.o: $(extra-y)
+efi := $(if $(efi),$(shell rm disabled)y)
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
deleted file mode 100644
index 5060e6f..0000000
--- a/xen/arch/x86/efi/stub.c
+++ /dev/null
@@ -1,42 +0,0 @@
-#include <xen/efi.h>
-#include <xen/errno.h>
-#include <xen/init.h>
-#include <xen/lib.h>
-
-#ifndef efi_platform
-bool_t efi_platform = 0;
-bool_t efi_loader = 0;
-#endif
-
-void __init efi_init_memory(void) { }
-
-paddr_t efi_rs_page_table(void)
-{
-    BUG();
-    return 0;
-}
-
-unsigned long efi_get_time(void)
-{
-    BUG();
-    return 0;
-}
-
-void efi_halt_system(void) { }
-void efi_reset_system(bool_t warm) { }
-
-int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
-{
-    return -ENOSYS;
-}
-
-int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *)
-    __attribute__((__alias__("efi_get_info")));
-
-int efi_runtime_call(struct xenpf_efi_runtime_call *op)
-{
-    return -ENOSYS;
-}
-
-int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *)
-    __attribute__((__alias__("efi_runtime_call")));
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d4b1f1a..8e4b144 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -188,8 +188,6 @@ SECTIONS
   .pad : {
     . = ALIGN(0x1000000);
   } :text
-#else
-  efi = .;
 #endif
 
   /* Sections to be discarded */
-- 
1.7.10.4

Re: [PATCH 08/18] efi: build xen.gz with EFI code

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> --- a/xen/arch/x86/efi/Makefile
> +++ b/xen/arch/x86/efi/Makefile
> @@ -1,14 +1,14 @@
>  CFLAGS += -fshort-wchar
>  
> -obj-y += stub.o
> +obj-y += boot.o
> +obj-y += compat.o
> +obj-y += runtime.o

So how is this going to work with a compiler not new enough to
support the MS ABI (via function attribute)?

Jan

Re: [PATCH 08/18] efi: build xen.gz with EFI code

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> --- a/xen/arch/x86/efi/Makefile
> +++ b/xen/arch/x86/efi/Makefile
> @@ -1,14 +1,14 @@
>  CFLAGS += -fshort-wchar
>  
> -obj-y += stub.o
> +obj-y += boot.o
> +obj-y += compat.o
> +obj-y += runtime.o

So how is this going to work with a compiler not new enough to
support the MS ABI (via function attribute)?

Jan

Re: [PATCH 08/18] efi: build xen.gz with EFI code

[Daniel Kiper]

On Mon, Mar 02, 2015 at 04:14:22PM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> > --- a/xen/arch/x86/efi/Makefile
> > +++ b/xen/arch/x86/efi/Makefile
> > @@ -1,14 +1,14 @@
> >  CFLAGS += -fshort-wchar
> >
> > -obj-y += stub.o
> > +obj-y += boot.o
> > +obj-y += compat.o
> > +obj-y += runtime.o
>
> So how is this going to work with a compiler not new enough to
> support the MS ABI (via function attribute)?

README says:

First, there are a number of prerequisites for building a Xen source
release. Make sure you have all the following installed, either by
visiting the project webpage or installing a pre-built package
provided by your OS distributor:
    * GCC v4.1 or later

IIRC, MS ABI is supported starting from GCC v4.0. Should we care
about people using compilers older than we require? Though another
question arises. Is it possible to build GCC v4.0 and newer with MS ABI
disabled? If yes then we should take into account that thing.

Daniel

Re: [PATCH 08/18] efi: build xen.gz with EFI code

[Jan Beulich]

>>> On 27.03.15 at 12:14, <daniel.kiper@oracle.com> wrote:
> IIRC, MS ABI is supported starting from GCC v4.0.

Where did you find that? From all I know __attribute__((__ms_abi__))
is being supported only by 4.5 and newer. The mere support of the
MS ABI via command line option doesn't help us, as we need to be
able to mix ABIs within a single source file.

Jan

Re: [PATCH 08/18] efi: build xen.gz with EFI code

[Jan Beulich]

>>> On 27.03.15 at 12:14, <daniel.kiper@oracle.com> wrote:
> IIRC, MS ABI is supported starting from GCC v4.0.

Where did you find that? From all I know __attribute__((__ms_abi__))
is being supported only by 4.5 and newer. The mere support of the
MS ABI via command line option doesn't help us, as we need to be
able to mix ABIs within a single source file.

Jan

Re: [PATCH 08/18] efi: build xen.gz with EFI code

[Andrew Cooper]

On 27/03/15 11:46, Jan Beulich wrote:
>>>> On 27.03.15 at 12:14, <daniel.kiper@oracle.com> wrote:
>> IIRC, MS ABI is supported starting from GCC v4.0.
> Where did you find that? From all I know __attribute__((__ms_abi__))
> is being supported only by 4.5 and newer. The mere support of the
> MS ABI via command line option doesn't help us, as we need to be
> able to mix ABIs within a single source file.
>
> Jan
>

As I have indicated elsewhere (but can't seem to locate - it was a while 
ago), I think it is perfectly reasonable to have a CONFIG_EFI which is 
only enabled if the makefile detects GCC >= 4.5

That way, older build environments don't get EFI support, while newer 
ones do, and newer systems can safely use __attribute__((__ms_abi__)) to 
make a mixed abi binary.

~Andrew

Re: [PATCH 08/18] efi: build xen.gz with EFI code

[Andrew Cooper]

On 27/03/15 11:46, Jan Beulich wrote:
>>>> On 27.03.15 at 12:14, <daniel.kiper@oracle.com> wrote:
>> IIRC, MS ABI is supported starting from GCC v4.0.
> Where did you find that? From all I know __attribute__((__ms_abi__))
> is being supported only by 4.5 and newer. The mere support of the
> MS ABI via command line option doesn't help us, as we need to be
> able to mix ABIs within a single source file.
>
> Jan
>

As I have indicated elsewhere (but can't seem to locate - it was a while 
ago), I think it is perfectly reasonable to have a CONFIG_EFI which is 
only enabled if the makefile detects GCC >= 4.5

That way, older build environments don't get EFI support, while newer 
ones do, and newer systems can safely use __attribute__((__ms_abi__)) to 
make a mixed abi binary.

~Andrew

Re: [PATCH 08/18] efi: build xen.gz with EFI code

[Daniel Kiper]

On Mon, Mar 02, 2015 at 04:14:22PM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> > --- a/xen/arch/x86/efi/Makefile
> > +++ b/xen/arch/x86/efi/Makefile
> > @@ -1,14 +1,14 @@
> >  CFLAGS += -fshort-wchar
> >
> > -obj-y += stub.o
> > +obj-y += boot.o
> > +obj-y += compat.o
> > +obj-y += runtime.o
>
> So how is this going to work with a compiler not new enough to
> support the MS ABI (via function attribute)?

README says:

First, there are a number of prerequisites for building a Xen source
release. Make sure you have all the following installed, either by
visiting the project webpage or installing a pre-built package
provided by your OS distributor:
    * GCC v4.1 or later

IIRC, MS ABI is supported starting from GCC v4.0. Should we care
about people using compilers older than we require? Though another
question arises. Is it possible to build GCC v4.0 and newer with MS ABI
disabled? If yes then we should take into account that thing.

Daniel

[PATCH 09/18] efi: create efi_init()

[Daniel Kiper]

..which initializes basic EFI variables. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/common/efi/boot.c |   26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 89d081d..1bf88e4 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -586,6 +586,21 @@ static char *__init get_value(const struct file *cfg, const char *section,
     return NULL;
 }
 
+static void __init efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
+{
+    efi_ih = ImageHandle;
+    efi_bs = SystemTable->BootServices;
+    efi_rs = SystemTable->RuntimeServices;
+    efi_ct = SystemTable->ConfigurationTable;
+    efi_num_ct = SystemTable->NumberOfTableEntries;
+    efi_version = SystemTable->Hdr.Revision;
+    efi_fw_vendor = SystemTable->FirmwareVendor;
+    efi_fw_revision = SystemTable->FirmwareRevision;
+
+    StdOut = SystemTable->ConOut;
+    StdErr = SystemTable->StdErr ?: StdOut;
+}
+
 static void __init setup_efi_pci(void)
 {
     EFI_STATUS status;
@@ -713,17 +728,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     efi_loader = 1;
 #endif
 
-    efi_ih = ImageHandle;
-    efi_bs = SystemTable->BootServices;
-    efi_rs = SystemTable->RuntimeServices;
-    efi_ct = SystemTable->ConfigurationTable;
-    efi_num_ct = SystemTable->NumberOfTableEntries;
-    efi_version = SystemTable->Hdr.Revision;
-    efi_fw_vendor = SystemTable->FirmwareVendor;
-    efi_fw_revision = SystemTable->FirmwareRevision;
+    efi_init(ImageHandle, SystemTable);
 
-    StdOut = SystemTable->ConOut;
-    StdErr = SystemTable->StdErr ?: StdOut;
     use_cfg_file = efi_arch_use_config_file(SystemTable);
 
     status = efi_bs->HandleProtocol(ImageHandle, &loaded_image_guid,
-- 
1.7.10.4

[PATCH 10/18] efi: create efi_console_set_mode()

[Daniel Kiper]

..which sets console mode. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/common/efi/boot.c |   37 ++++++++++++++++++++-----------------
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 1bf88e4..9ce8a25 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -601,6 +601,25 @@ static void __init efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTabl
     StdErr = SystemTable->StdErr ?: StdOut;
 }
 
+static void __init efi_console_set_mode(void)
+{
+    UINTN cols, rows, size;
+    unsigned int best, i;
+
+    for ( i = 0, size = 0, best = StdOut->Mode->Mode;
+          i < StdOut->Mode->MaxMode; ++i )
+    {
+        if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
+             cols * rows > size )
+        {
+            size = cols * rows;
+            best = i;
+        }
+    }
+    if ( best != StdOut->Mode->Mode )
+        StdOut->SetMode(StdOut, best);
+}
+
 static void __init setup_efi_pci(void)
 {
     EFI_STATUS status;
@@ -787,23 +806,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
         }
 
         if ( !base_video )
-        {
-            unsigned int best;
-            UINTN cols, rows, size;
-
-            for ( i = 0, size = 0, best = StdOut->Mode->Mode;
-                  i < StdOut->Mode->MaxMode; ++i )
-            {
-                if ( StdOut->QueryMode(StdOut, i, &cols, &rows) == EFI_SUCCESS &&
-                     cols * rows > size )
-                {
-                    size = cols * rows;
-                    best = i;
-                }
-            }
-            if ( best != StdOut->Mode->Mode )
-                StdOut->SetMode(StdOut, best);
-        }
+            efi_console_set_mode();
     }
 
     PrintStr(L"Xen " __stringify(XEN_VERSION) "." __stringify(XEN_SUBVERSION)
-- 
1.7.10.4

[PATCH 11/18] efi: create efi_get_gop()

[Daniel Kiper]

..which gets pointer to GOP device. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/common/efi/boot.c |   59 ++++++++++++++++++++++++++++++-------------------
 1 file changed, 36 insertions(+), 23 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 9ce8a25..6bbcb3b 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -620,6 +620,41 @@ static void __init efi_console_set_mode(void)
         StdOut->SetMode(StdOut, best);
 }
 
+static EFI_GRAPHICS_OUTPUT_PROTOCOL __init *efi_get_gop(void)
+{
+    EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
+    EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
+    EFI_HANDLE *handles;
+    EFI_STATUS status;
+    UINTN info_size, size = 0;
+    static EFI_GUID __initdata gop_guid = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
+    unsigned int i;
+
+    status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
+    if ( status == EFI_BUFFER_TOO_SMALL )
+        status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
+    if ( !EFI_ERROR(status) )
+        status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
+                                      handles);
+    if ( EFI_ERROR(status) )
+        size = 0;
+    for ( i = 0; i < size / sizeof(*handles); ++i )
+    {
+        status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
+        if ( EFI_ERROR(status) )
+            continue;
+        status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
+        if ( !EFI_ERROR(status) )
+            break;
+    }
+    if ( handles )
+        efi_bs->FreePool(handles);
+    if ( EFI_ERROR(status) )
+        gop = NULL;
+
+    return gop;
+}
+
 static void __init setup_efi_pci(void)
 {
     EFI_STATUS status;
@@ -726,14 +761,12 @@ void EFIAPI __init noreturn
 efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 {
     static EFI_GUID __initdata loaded_image_guid = LOADED_IMAGE_PROTOCOL;
-    static EFI_GUID __initdata gop_guid = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
     static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
     EFI_LOADED_IMAGE *loaded_image;
     EFI_STATUS status;
     unsigned int i, argc;
     CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
     UINTN map_key, info_size, gop_mode = ~0;
-    EFI_HANDLE *handles = NULL;
     EFI_SHIM_LOCK_PROTOCOL *shim_lock;
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
     EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
@@ -825,27 +858,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
                                &cols, &rows) == EFI_SUCCESS )
             efi_arch_console_init(cols, rows);
 
-        status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size, NULL);
-        if ( status == EFI_BUFFER_TOO_SMALL )
-            status = efi_bs->AllocatePool(EfiLoaderData, size, (void **)&handles);
-        if ( !EFI_ERROR(status) )
-            status = efi_bs->LocateHandle(ByProtocol, &gop_guid, NULL, &size,
-                                          handles);
-        if ( EFI_ERROR(status) )
-            size = 0;
-        for ( i = 0; i < size / sizeof(*handles); ++i )
-        {
-            status = efi_bs->HandleProtocol(handles[i], &gop_guid, (void **)&gop);
-            if ( EFI_ERROR(status) )
-                continue;
-            status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
-            if ( !EFI_ERROR(status) )
-                break;
-        }
-        if ( handles )
-            efi_bs->FreePool(handles);
-        if ( EFI_ERROR(status) )
-            gop = NULL;
+        gop = efi_get_gop();
 
         /* Get the file system interface. */
         dir_handle = get_parent_handle(loaded_image, &file_name);
-- 
1.7.10.4

[PATCH 12/18] efi: create efi_find_gop_mode()

[Daniel Kiper]

..which finds suitable GOP mode. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/common/efi/boot.c |   94 ++++++++++++++++++++++++++++---------------------
 1 file changed, 54 insertions(+), 40 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 6bbcb3b..114019e 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -655,6 +655,58 @@ static EFI_GRAPHICS_OUTPUT_PROTOCOL __init *efi_get_gop(void)
     return gop;
 }
 
+static UINTN __init efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
+                                      UINTN cols, UINTN rows, UINTN depth)
+{
+    EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
+    EFI_STATUS status;
+    UINTN gop_mode = ~0, info_size, size;
+    unsigned int i;
+
+    if ( !gop )
+        return gop_mode;
+
+    for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
+    {
+        unsigned int bpp = 0;
+
+        status = gop->QueryMode(gop, i, &info_size, &mode_info);
+        if ( EFI_ERROR(status) )
+            continue;
+        switch ( mode_info->PixelFormat )
+        {
+        case PixelBitMask:
+            bpp = hweight32(mode_info->PixelInformation.RedMask |
+                            mode_info->PixelInformation.GreenMask |
+                            mode_info->PixelInformation.BlueMask);
+            break;
+        case PixelRedGreenBlueReserved8BitPerColor:
+        case PixelBlueGreenRedReserved8BitPerColor:
+            bpp = 24;
+            break;
+        default:
+            continue;
+        }
+        if ( cols == mode_info->HorizontalResolution &&
+             rows == mode_info->VerticalResolution &&
+             (!depth || bpp == depth) )
+        {
+            gop_mode = i;
+            break;
+        }
+        if ( !cols && !rows &&
+             mode_info->HorizontalResolution *
+             mode_info->VerticalResolution > size )
+        {
+            size = mode_info->HorizontalResolution *
+                   mode_info->VerticalResolution;
+            gop_mode = i;
+        }
+    }
+
+    return gop_mode;
+}
+
 static void __init setup_efi_pci(void)
 {
     EFI_STATUS status;
@@ -966,46 +1018,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
         dir_handle->Close(dir_handle);
 
-        if ( gop && !base_video )
-        {
-            for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
-            {
-                unsigned int bpp = 0;
-
-                status = gop->QueryMode(gop, i, &info_size, &mode_info);
-                if ( EFI_ERROR(status) )
-                    continue;
-                switch ( mode_info->PixelFormat )
-                {
-                case PixelBitMask:
-                    bpp = hweight32(mode_info->PixelInformation.RedMask |
-                                    mode_info->PixelInformation.GreenMask |
-                                    mode_info->PixelInformation.BlueMask);
-                    break;
-                case PixelRedGreenBlueReserved8BitPerColor:
-                case PixelBlueGreenRedReserved8BitPerColor:
-                    bpp = 24;
-                    break;
-                default:
-                    continue;
-                }
-                if ( cols == mode_info->HorizontalResolution &&
-                     rows == mode_info->VerticalResolution &&
-                     (!depth || bpp == depth) )
-                {
-                    gop_mode = i;
-                    break;
-                }
-                if ( !cols && !rows &&
-                     mode_info->HorizontalResolution *
-                     mode_info->VerticalResolution > size )
-                {
-                    size = mode_info->HorizontalResolution *
-                           mode_info->VerticalResolution;
-                    gop_mode = i;
-                }
-            }
-        }
+        if ( !base_video )
+            gop_mode = efi_find_gop_mode(gop, cols, rows, depth);
     }
 
     efi_arch_edd();
-- 
1.7.10.4

[PATCH 12/18] efi: create efi_find_gop_mode()

[Daniel Kiper]

..which finds suitable GOP mode. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/common/efi/boot.c |   94 ++++++++++++++++++++++++++++---------------------
 1 file changed, 54 insertions(+), 40 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 6bbcb3b..114019e 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -655,6 +655,58 @@ static EFI_GRAPHICS_OUTPUT_PROTOCOL __init *efi_get_gop(void)
     return gop;
 }
 
+static UINTN __init efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
+                                      UINTN cols, UINTN rows, UINTN depth)
+{
+    EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
+    EFI_STATUS status;
+    UINTN gop_mode = ~0, info_size, size;
+    unsigned int i;
+
+    if ( !gop )
+        return gop_mode;
+
+    for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
+    {
+        unsigned int bpp = 0;
+
+        status = gop->QueryMode(gop, i, &info_size, &mode_info);
+        if ( EFI_ERROR(status) )
+            continue;
+        switch ( mode_info->PixelFormat )
+        {
+        case PixelBitMask:
+            bpp = hweight32(mode_info->PixelInformation.RedMask |
+                            mode_info->PixelInformation.GreenMask |
+                            mode_info->PixelInformation.BlueMask);
+            break;
+        case PixelRedGreenBlueReserved8BitPerColor:
+        case PixelBlueGreenRedReserved8BitPerColor:
+            bpp = 24;
+            break;
+        default:
+            continue;
+        }
+        if ( cols == mode_info->HorizontalResolution &&
+             rows == mode_info->VerticalResolution &&
+             (!depth || bpp == depth) )
+        {
+            gop_mode = i;
+            break;
+        }
+        if ( !cols && !rows &&
+             mode_info->HorizontalResolution *
+             mode_info->VerticalResolution > size )
+        {
+            size = mode_info->HorizontalResolution *
+                   mode_info->VerticalResolution;
+            gop_mode = i;
+        }
+    }
+
+    return gop_mode;
+}
+
 static void __init setup_efi_pci(void)
 {
     EFI_STATUS status;
@@ -966,46 +1018,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
         dir_handle->Close(dir_handle);
 
-        if ( gop && !base_video )
-        {
-            for ( i = size = 0; i < gop->Mode->MaxMode; ++i )
-            {
-                unsigned int bpp = 0;
-
-                status = gop->QueryMode(gop, i, &info_size, &mode_info);
-                if ( EFI_ERROR(status) )
-                    continue;
-                switch ( mode_info->PixelFormat )
-                {
-                case PixelBitMask:
-                    bpp = hweight32(mode_info->PixelInformation.RedMask |
-                                    mode_info->PixelInformation.GreenMask |
-                                    mode_info->PixelInformation.BlueMask);
-                    break;
-                case PixelRedGreenBlueReserved8BitPerColor:
-                case PixelBlueGreenRedReserved8BitPerColor:
-                    bpp = 24;
-                    break;
-                default:
-                    continue;
-                }
-                if ( cols == mode_info->HorizontalResolution &&
-                     rows == mode_info->VerticalResolution &&
-                     (!depth || bpp == depth) )
-                {
-                    gop_mode = i;
-                    break;
-                }
-                if ( !cols && !rows &&
-                     mode_info->HorizontalResolution *
-                     mode_info->VerticalResolution > size )
-                {
-                    size = mode_info->HorizontalResolution *
-                           mode_info->VerticalResolution;
-                    gop_mode = i;
-                }
-            }
-        }
+        if ( !base_video )
+            gop_mode = efi_find_gop_mode(gop, cols, rows, depth);
     }
 
     efi_arch_edd();
-- 
1.7.10.4

[PATCH 13/18] efi: create efi_tables()

[Daniel Kiper]

..which collects system tables data. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/common/efi/boot.c |   51 ++++++++++++++++++++++++++++---------------------
 1 file changed, 29 insertions(+), 22 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 114019e..cf0fbc2 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -707,6 +707,34 @@ static UINTN __init efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
     return gop_mode;
 }
 
+static void __init efi_tables(void)
+{
+    unsigned int i;
+
+    /* Obtain basic table pointers. */
+    for ( i = 0; i < efi_num_ct; ++i )
+    {
+        static EFI_GUID __initdata acpi2_guid = ACPI_20_TABLE_GUID;
+        static EFI_GUID __initdata acpi_guid = ACPI_TABLE_GUID;
+        static EFI_GUID __initdata mps_guid = MPS_TABLE_GUID;
+        static EFI_GUID __initdata smbios_guid = SMBIOS_TABLE_GUID;
+
+        if ( match_guid(&acpi2_guid, &efi_ct[i].VendorGuid) )
+	       efi.acpi20 = (long)efi_ct[i].VendorTable;
+        if ( match_guid(&acpi_guid, &efi_ct[i].VendorGuid) )
+	       efi.acpi = (long)efi_ct[i].VendorTable;
+        if ( match_guid(&mps_guid, &efi_ct[i].VendorGuid) )
+	       efi.mps = (long)efi_ct[i].VendorTable;
+        if ( match_guid(&smbios_guid, &efi_ct[i].VendorGuid) )
+	       efi.smbios = (long)efi_ct[i].VendorTable;
+    }
+
+#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
+    if (efi.smbios != EFI_INVALID_TABLE_ADDR)
+        dmi_efi_get_table((void *)(long)efi.smbios);
+#endif
+}
+
 static void __init setup_efi_pci(void)
 {
     EFI_STATUS status;
@@ -1027,28 +1055,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     /* XXX Collect EDID info. */
     efi_arch_cpu();
 
-    /* Obtain basic table pointers. */
-    for ( i = 0; i < efi_num_ct; ++i )
-    {
-        static EFI_GUID __initdata acpi2_guid = ACPI_20_TABLE_GUID;
-        static EFI_GUID __initdata acpi_guid = ACPI_TABLE_GUID;
-        static EFI_GUID __initdata mps_guid = MPS_TABLE_GUID;
-        static EFI_GUID __initdata smbios_guid = SMBIOS_TABLE_GUID;
-
-        if ( match_guid(&acpi2_guid, &efi_ct[i].VendorGuid) )
-	       efi.acpi20 = (long)efi_ct[i].VendorTable;
-        if ( match_guid(&acpi_guid, &efi_ct[i].VendorGuid) )
-	       efi.acpi = (long)efi_ct[i].VendorTable;
-        if ( match_guid(&mps_guid, &efi_ct[i].VendorGuid) )
-	       efi.mps = (long)efi_ct[i].VendorTable;
-        if ( match_guid(&smbios_guid, &efi_ct[i].VendorGuid) )
-	       efi.smbios = (long)efi_ct[i].VendorTable;
-    }
-
-#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
-    if (efi.smbios != EFI_INVALID_TABLE_ADDR)
-        dmi_efi_get_table((void *)(long)efi.smbios);
-#endif
+    efi_tables();
 
     /* Collect PCI ROM contents. */
     setup_efi_pci();
-- 
1.7.10.4

[PATCH 14/18] efi: create efi_variables()

[Daniel Kiper]

..which collects variable store parameters. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/common/efi/boot.c |   41 ++++++++++++++++++++++++-----------------
 1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index cf0fbc2..2379022 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -822,6 +822,29 @@ static void __init setup_efi_pci(void)
     efi_bs->FreePool(handles);
 }
 
+static void __init efi_variables(void)
+{
+    EFI_STATUS status;
+
+    status = (efi_rs->Hdr.Revision >> 16) >= 2 ?
+             efi_rs->QueryVariableInfo(EFI_VARIABLE_NON_VOLATILE |
+                                       EFI_VARIABLE_BOOTSERVICE_ACCESS |
+                                       EFI_VARIABLE_RUNTIME_ACCESS,
+                                       &efi_boot_max_var_store_size,
+                                       &efi_boot_remain_var_store_size,
+                                       &efi_boot_max_var_size) :
+             EFI_INCOMPATIBLE_VERSION;
+    if ( EFI_ERROR(status) )
+    {
+        efi_boot_max_var_store_size = 0;
+        efi_boot_remain_var_store_size = 0;
+        efi_boot_max_var_size = status;
+        PrintStr(L"Warning: Could not query variable store: ");
+        DisplayUint(status, 0);
+        PrintStr(newline);
+    }
+}
+
 static int __init __maybe_unused set_color(u32 mask, int bpp, u8 *pos, u8 *sz)
 {
    if ( bpp < 0 )
@@ -1061,23 +1084,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     setup_efi_pci();
 
     /* Get snapshot of variable store parameters. */
-    status = (efi_rs->Hdr.Revision >> 16) >= 2 ?
-             efi_rs->QueryVariableInfo(EFI_VARIABLE_NON_VOLATILE |
-                                       EFI_VARIABLE_BOOTSERVICE_ACCESS |
-                                       EFI_VARIABLE_RUNTIME_ACCESS,
-                                       &efi_boot_max_var_store_size,
-                                       &efi_boot_remain_var_store_size,
-                                       &efi_boot_max_var_size) :
-             EFI_INCOMPATIBLE_VERSION;
-    if ( EFI_ERROR(status) )
-    {
-        efi_boot_max_var_store_size = 0;
-        efi_boot_remain_var_store_size = 0;
-        efi_boot_max_var_size = status;
-        PrintStr(L"Warning: Could not query variable store: ");
-        DisplayUint(status, 0);
-        PrintStr(newline);
-    }
+    efi_variables();
 
     efi_arch_memory_setup();
 
-- 
1.7.10.4

[PATCH 15/18] efi: create efi_set_gop_mode()

[Daniel Kiper]

..which sets chosen GOP mode. We need this to support
multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/common/efi/boot.c |   35 +++++++++++++++++++++--------------
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 2379022..63c930d 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -845,6 +845,25 @@ static void __init efi_variables(void)
     }
 }
 
+static void __init efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop_mode)
+{
+    EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
+    EFI_STATUS status;
+    UINTN info_size;
+
+    if ( !gop )
+        return;
+
+    /* Set graphics mode. */
+    if ( gop_mode < gop->Mode->MaxMode && gop_mode != gop->Mode->Mode )
+        gop->SetMode(gop, gop_mode);
+
+    /* Get graphics and frame buffer info. */
+    status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
+    if ( !EFI_ERROR(status) )
+        efi_arch_video_init(gop, info_size, mode_info);
+}
+
 static int __init __maybe_unused set_color(u32 mask, int bpp, u8 *pos, u8 *sz)
 {
    if ( bpp < 0 )
@@ -869,10 +888,9 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     EFI_STATUS status;
     unsigned int i, argc;
     CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
-    UINTN map_key, info_size, gop_mode = ~0;
+    UINTN map_key, gop_mode = ~0;
     EFI_SHIM_LOCK_PROTOCOL *shim_lock;
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
-    EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
     union string section = { NULL }, name;
     bool_t base_video = 0, retry;
     char *option_str;
@@ -1088,18 +1106,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     efi_arch_memory_setup();
 
-    if ( gop )
-    {
-
-        /* Set graphics mode. */
-        if ( gop_mode < gop->Mode->MaxMode && gop_mode != gop->Mode->Mode )
-            gop->SetMode(gop, gop_mode);
-
-        /* Get graphics and frame buffer info. */
-        status = gop->QueryMode(gop, gop->Mode->Mode, &info_size, &mode_info);
-        if ( !EFI_ERROR(status) )
-            efi_arch_video_init(gop, info_size, mode_info);
-    }
+    efi_set_gop_mode(gop, gop_mode);
 
     efi_bs->GetMemoryMap(&efi_memmap_size, NULL, &map_key,
                          &efi_mdesc_size, &mdesc_ver);
-- 
1.7.10.4

[PATCH 16/18] efi: create efi_exit_boot()

[Daniel Kiper]

..which gets memory map and calls ExitBootServices(). We need this
to support multiboot2 protocol on EFI platforms.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/common/efi/boot.c |   79 +++++++++++++++++++++++++++----------------------
 1 file changed, 44 insertions(+), 35 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 63c930d..f8be3dd 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -864,6 +864,47 @@ static void __init efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop
         efi_arch_video_init(gop, info_size, mode_info);
 }
 
+static void __init efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
+{
+    EFI_STATUS status;
+    UINTN map_key;
+    bool_t retry;
+
+    efi_bs->GetMemoryMap(&efi_memmap_size, NULL, &map_key,
+                         &efi_mdesc_size, &mdesc_ver);
+    efi_memmap = efi_arch_allocate_mmap_buffer(&efi_memmap_size);
+    if ( !efi_memmap )
+        blexit(L"Unable to allocate memory for EFI memory map");
+
+    for ( retry = 0; ; retry = 1 )
+    {
+        status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
+                                      &efi_mdesc_size, &mdesc_ver);
+        if ( EFI_ERROR(status) )
+            PrintErrMesg(L"Cannot obtain memory map", status);
+
+        efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
+                                    efi_mdesc_size, mdesc_ver);
+
+        efi_arch_pre_exit_boot();
+
+        status = efi_bs->ExitBootServices(ImageHandle, map_key);
+        if ( status != EFI_INVALID_PARAMETER || retry )
+            break;
+    }
+
+    if ( EFI_ERROR(status) )
+        PrintErrMesg(L"Cannot exit boot services", status);
+
+    /* Adjust pointers into EFI. */
+    efi_ct = (void *)efi_ct + DIRECTMAP_VIRT_START;
+#ifdef USE_SET_VIRTUAL_ADDRESS_MAP
+    efi_rs = (void *)efi_rs + DIRECTMAP_VIRT_START;
+#endif
+    efi_memmap = (void *)efi_memmap + DIRECTMAP_VIRT_START;
+    efi_fw_vendor = (void *)efi_fw_vendor + DIRECTMAP_VIRT_START;
+}
+
 static int __init __maybe_unused set_color(u32 mask, int bpp, u8 *pos, u8 *sz)
 {
    if ( bpp < 0 )
@@ -888,11 +929,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
     EFI_STATUS status;
     unsigned int i, argc;
     CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
-    UINTN map_key, gop_mode = ~0;
+    UINTN gop_mode = ~0;
     EFI_SHIM_LOCK_PROTOCOL *shim_lock;
     EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
     union string section = { NULL }, name;
-    bool_t base_video = 0, retry;
+    bool_t base_video = 0;
     char *option_str;
     bool_t use_cfg_file;
 
@@ -1108,39 +1149,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 
     efi_set_gop_mode(gop, gop_mode);
 
-    efi_bs->GetMemoryMap(&efi_memmap_size, NULL, &map_key,
-                         &efi_mdesc_size, &mdesc_ver);
-    efi_memmap = efi_arch_allocate_mmap_buffer(&efi_memmap_size);
-    if ( !efi_memmap )
-        blexit(L"Unable to allocate memory for EFI memory map");
-
-    for ( retry = 0; ; retry = 1 )
-    {
-        status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
-                                      &efi_mdesc_size, &mdesc_ver);
-        if ( EFI_ERROR(status) )
-            PrintErrMesg(L"Cannot obtain memory map", status);
-
-        efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
-                                    efi_mdesc_size, mdesc_ver);
-
-        efi_arch_pre_exit_boot();
-
-        status = efi_bs->ExitBootServices(ImageHandle, map_key);
-        if ( status != EFI_INVALID_PARAMETER || retry )
-            break;
-    }
-
-    if ( EFI_ERROR(status) )
-        PrintErrMesg(L"Cannot exit boot services", status);
-
-    /* Adjust pointers into EFI. */
-    efi_ct = (void *)efi_ct + DIRECTMAP_VIRT_START;
-#ifdef USE_SET_VIRTUAL_ADDRESS_MAP
-    efi_rs = (void *)efi_rs + DIRECTMAP_VIRT_START;
-#endif
-    efi_memmap = (void *)efi_memmap + DIRECTMAP_VIRT_START;
-    efi_fw_vendor = (void *)efi_fw_vendor + DIRECTMAP_VIRT_START;
+    efi_exit_boot(ImageHandle, SystemTable);
 
     efi_arch_post_exit_boot();
     for( ; ; ); /* not reached */
-- 
1.7.10.4

Re: [PATCH 16/18] efi: create efi_exit_boot()

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> ..which gets memory map and calls ExitBootServices(). We need this
> to support multiboot2 protocol on EFI platforms.

Patches from 9 up to here all make sense on the basis that patch 18
does and assuming that you really need all this code moved out to
separate functions. How much different is efi_multiboot2() introduced
in #18 from what is left of efi_start() at this point? I.e. is splitting out
all of this code really needed?

If it is, please don't title all these patches "create ..." but "split out
..." or some such - you don't really create the code. Similarly the
second sentence above is too imprecise for my taste - "we want to
re-use this code to support ..." would seem more to the point.

Jan

Re: [PATCH 16/18] efi: create efi_exit_boot()

[Daniel Kiper]

On Mon, Mar 02, 2015 at 04:45:47PM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> > ..which gets memory map and calls ExitBootServices(). We need this
> > to support multiboot2 protocol on EFI platforms.
>
> Patches from 9 up to here all make sense on the basis that patch 18
> does and assuming that you really need all this code moved out to
> separate functions. How much different is efi_multiboot2() introduced
> in #18 from what is left of efi_start() at this point? I.e. is splitting out

More or less efi_multiboot2() does not parse command line and do not
load modules itself as efi_start() does.

> all of this code really needed?

I think that it is worth doing. First of all efi_start() is huge and its
analysis is very difficult right now. So, splitting code into smaller chunks
will improve readability a lot (I am still thinking about extracting command
line parser and module loader from efi_start() even if both functions will be
used only in efi_start(); this way we will have very simple functions doing
one thing easy to understand). Additionally, we create pieces which are very
easy to reuse in efi_multiboot2() which is very simple and again easy
for analysis.

Potentially we can reuse efi_start() in multiboot2 case. However, I prefer
to have separate function because this way it is clear that multiboot2 case
is different thing then native EFI loader stuff. Additionally, efi_start()
is architecture independent and efi_multiboot2() is x86 only and it should
live in x86 files.

> If it is, please don't title all these patches "create ..." but "split out
> ..." or some such - you don't really create the code. Similarly the
> second sentence above is too imprecise for my taste - "we want to
> re-use this code to support ..." would seem more to the point.

OK.

Daniel

Re: [PATCH 16/18] efi: create efi_exit_boot()

[Jan Beulich]

>>> On 27.03.15 at 13:00, <daniel.kiper@oracle.com> wrote:
> Additionally, efi_start()
> is architecture independent and efi_multiboot2() is x86 only and it should
> live in x86 files.

Is that really the case? Looking at the grub2 sources I see support
for other than x86...

Jan

Re: [PATCH 16/18] efi: create efi_exit_boot()

[Daniel Kiper]

On Fri, Mar 27, 2015 at 12:10:56PM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 13:00, <daniel.kiper@oracle.com> wrote:
> > Additionally, efi_start()
> > is architecture independent and efi_multiboot2() is x86 only and it should
> > live in x86 files.
>
> Is that really the case? Looking at the grub2 sources I see support
> for other than x86...

Well... In theory multiboot protocol was designed as arch independet.
However, docs define more precisely stuff for i386 and MIPS (multiboot2
protocol only). As I know we do not care about MIPS. Additionally, so
called muliboot protocol for ARM is completely different thing then
multiboot protocols mentioned above (it is a mixture of EFI native
loader with DT). So, it looks that from our point of view efi_multiboot2()
is x86 only stuff (right now, I am not fortune teller, so, I am not
able to tell what happens in the future ;-))) ).

Daniel

Re: [PATCH 16/18] efi: create efi_exit_boot()

[Daniel Kiper]

On Fri, Mar 27, 2015 at 12:10:56PM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 13:00, <daniel.kiper@oracle.com> wrote:
> > Additionally, efi_start()
> > is architecture independent and efi_multiboot2() is x86 only and it should
> > live in x86 files.
>
> Is that really the case? Looking at the grub2 sources I see support
> for other than x86...

Well... In theory multiboot protocol was designed as arch independet.
However, docs define more precisely stuff for i386 and MIPS (multiboot2
protocol only). As I know we do not care about MIPS. Additionally, so
called muliboot protocol for ARM is completely different thing then
multiboot protocols mentioned above (it is a mixture of EFI native
loader with DT). So, it looks that from our point of view efi_multiboot2()
is x86 only stuff (right now, I am not fortune teller, so, I am not
able to tell what happens in the future ;-))) ).

Daniel

Re: [PATCH 16/18] efi: create efi_exit_boot()

[Ian Campbell]

On Fri, 2015-03-27 at 13:43 +0100, Daniel Kiper wrote:
> On Fri, Mar 27, 2015 at 12:10:56PM +0000, Jan Beulich wrote:
> > >>> On 27.03.15 at 13:00, <daniel.kiper@oracle.com> wrote:
> > > Additionally, efi_start()
> > > is architecture independent and efi_multiboot2() is x86 only and it should
> > > live in x86 files.
> >
> > Is that really the case? Looking at the grub2 sources I see support
> > for other than x86...
> 
> Well... In theory multiboot protocol was designed as arch independet.
> However, docs define more precisely stuff for i386 and MIPS (multiboot2
> protocol only). As I know we do not care about MIPS. Additionally, so
> called muliboot protocol for ARM is completely different thing then
> multiboot protocols mentioned above

The ARM multiboot DT thing fits into the multiboot1 "namespace", since
it is unlikely there will ever be an ARM multiboot1.

It's possible that someone might spec and implement multiboot2 for ARM
as well, although whether than has any impact on the comments made in
this threadlet I've no idea..

Ian.

Re: [PATCH 16/18] efi: create efi_exit_boot()

[Ian Campbell]

On Fri, 2015-03-27 at 13:43 +0100, Daniel Kiper wrote:
> On Fri, Mar 27, 2015 at 12:10:56PM +0000, Jan Beulich wrote:
> > >>> On 27.03.15 at 13:00, <daniel.kiper@oracle.com> wrote:
> > > Additionally, efi_start()
> > > is architecture independent and efi_multiboot2() is x86 only and it should
> > > live in x86 files.
> >
> > Is that really the case? Looking at the grub2 sources I see support
> > for other than x86...
> 
> Well... In theory multiboot protocol was designed as arch independet.
> However, docs define more precisely stuff for i386 and MIPS (multiboot2
> protocol only). As I know we do not care about MIPS. Additionally, so
> called muliboot protocol for ARM is completely different thing then
> multiboot protocols mentioned above

The ARM multiboot DT thing fits into the multiboot1 "namespace", since
it is unlikely there will ever be an ARM multiboot1.

It's possible that someone might spec and implement multiboot2 for ARM
as well, although whether than has any impact on the comments made in
this threadlet I've no idea..

Ian.

Re: [PATCH 16/18] efi: create efi_exit_boot()

[Jan Beulich]

>>> On 27.03.15 at 13:00, <daniel.kiper@oracle.com> wrote:
> Additionally, efi_start()
> is architecture independent and efi_multiboot2() is x86 only and it should
> live in x86 files.

Is that really the case? Looking at the grub2 sources I see support
for other than x86...

Jan

Re: [PATCH 16/18] efi: create efi_exit_boot()

[Daniel Kiper]

On Mon, Mar 02, 2015 at 04:45:47PM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> > ..which gets memory map and calls ExitBootServices(). We need this
> > to support multiboot2 protocol on EFI platforms.
>
> Patches from 9 up to here all make sense on the basis that patch 18
> does and assuming that you really need all this code moved out to
> separate functions. How much different is efi_multiboot2() introduced
> in #18 from what is left of efi_start() at this point? I.e. is splitting out

More or less efi_multiboot2() does not parse command line and do not
load modules itself as efi_start() does.

> all of this code really needed?

I think that it is worth doing. First of all efi_start() is huge and its
analysis is very difficult right now. So, splitting code into smaller chunks
will improve readability a lot (I am still thinking about extracting command
line parser and module loader from efi_start() even if both functions will be
used only in efi_start(); this way we will have very simple functions doing
one thing easy to understand). Additionally, we create pieces which are very
easy to reuse in efi_multiboot2() which is very simple and again easy
for analysis.

Potentially we can reuse efi_start() in multiboot2 case. However, I prefer
to have separate function because this way it is clear that multiboot2 case
is different thing then native EFI loader stuff. Additionally, efi_start()
is architecture independent and efi_multiboot2() is x86 only and it should
live in x86 files.

> If it is, please don't title all these patches "create ..." but "split out
> ..." or some such - you don't really create the code. Similarly the
> second sentence above is too imprecise for my taste - "we want to
> re-use this code to support ..." would seem more to the point.

OK.

Daniel

Re: [PATCH 16/18] efi: create efi_exit_boot()

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> ..which gets memory map and calls ExitBootServices(). We need this
> to support multiboot2 protocol on EFI platforms.

Patches from 9 up to here all make sense on the basis that patch 18
does and assuming that you really need all this code moved out to
separate functions. How much different is efi_multiboot2() introduced
in #18 from what is left of efi_start() at this point? I.e. is splitting out
all of this code really needed?

If it is, please don't title all these patches "create ..." but "split out
..." or some such - you don't really create the code. Similarly the
second sentence above is too imprecise for my taste - "we want to
re-use this code to support ..." would seem more to the point.

Jan

[PATCH 17/18] x86/efi: create new early memory allocator

[Daniel Kiper]

There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and
going down. Sadly this does not work when Xen is loaded using multiboot2
protocol because start lives on 1 MiB address. So, I tried to use
mem_lower address calculated by GRUB2. However, it works only on some
machines. There are machines in the wild (e.g. Dell PowerEdge R820)
which uses first ~640 KiB for boot services code or data... :-(((

In case of multiboot2 protocol we need that place_string() only allocate
memory chunk for EFI memory map. However, I think that it should be fixed
instead of making another function used just in one case. I thought about
two solutions.

1) We could use native EFI allocation functions (e.g. AllocatePool()
   or AllocatePages()) to get memory chunk. However, later (somewhere
   in __start_xen()) we must copy its contents to safe place or reserve
   this in e820 memory map and map it in Xen virtual address space.
   In later case we must also care about conflicts with e.g. crash
   kernel regions which could be quite difficult.

2) We may allocate memory area statically somewhere in Xen code which
   could be used as memory pool for early dynamic allocations. Looks
   quite simple. Additionally, it would not depend on EFI at all and
   could be used on legacy BIOS platforms if we need it. However, we
   must carefully choose size of this pool. We do not want increase
   Xen binary size too much and waste too much memory but also we must fit
   at least memory map on x86 EFI platforms. As I saw on small machine,
   e.g. IBM System x3550 M2 with 8 GiB RAM, memory map my contain more
   than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
   So, it means that we need more than 8 KiB for EFI memory map only.
   Additionally, if we want to use this memory pool for Xen and modules
   command line storage (it would be used when xen.efi is executed as EFI
   application) then we should add, I think, about 1 KiB. In this case,
   to be on safe side, we should assume at least 64 KiB pool for early
   memory allocations, which is about 4 times of our earlier calculations.
   If we think that we should not waste unallocated memory in the pool
   on running system then we can mark this region as __initdata and move
   all required data to dynamically allocated places somewhere in __start_xen().

Now solution #2 is implemented but maybe we should consider #1 too.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/arch/x86/efi/efi-boot.h |   37 +++++++++++++++++++++++++++++--------
 xen/arch/x86/setup.c        |    3 +--
 2 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 3a3b4fe..6e98bc8 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -103,9 +103,35 @@ static void __init relocate_trampoline(unsigned long phys)
         *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4;
 }
 
+#define __MALLOC_SIZE	65536
+
+static char __malloc_mem[__MALLOC_SIZE];
+static char *__malloc_free = NULL;
+
+static void __init *__malloc(size_t size)
+{
+    void *ptr;
+
+    /*
+     * Init __malloc_free on runtime. Static initialization
+     * will not work because it puts virtual address there.
+     */
+    if ( __malloc_free == NULL )
+        __malloc_free = __malloc_mem;
+
+    ptr = __malloc_free;
+
+    __malloc_free += size;
+
+    if ( __malloc_free - __malloc_mem > sizeof(__malloc_mem) )
+        blexit(L"Out of static memory\r\n");
+
+    return ptr;
+}
+
 static void __init place_string(u32 *addr, const char *s)
 {
-    static char *__initdata alloc = start;
+    char *alloc = NULL;
 
     if ( s && *s )
     {
@@ -113,7 +139,7 @@ static void __init place_string(u32 *addr, const char *s)
         const char *old = (char *)(long)*addr;
         size_t len2 = *addr ? strlen(old) + 1 : 0;
 
-        alloc -= len1 + len2;
+        alloc = __malloc(len1 + len2);
         /*
          * Insert new string before already existing one. This is needed
          * for options passed on the command line to override options from
@@ -192,12 +218,7 @@ static void __init efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
 
 static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
 {
-    place_string(&mbi.mem_upper, NULL);
-    mbi.mem_upper -= *map_size;
-    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
-    if ( mbi.mem_upper < xen_phys_start )
-        return NULL;
-    return (void *)(long)mbi.mem_upper;
+    return __malloc(*map_size);
 }
 
 static void __init efi_arch_pre_exit_boot(void)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 711fdb0..aebd010 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -962,8 +962,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
     if ( !xen_phys_start )
         panic("Not enough memory to relocate Xen.");
-    reserve_e820_ram(&boot_e820, efi_loader ? mbi->mem_upper : __pa(&_start),
-                     __pa(&_end));
+    reserve_e820_ram(&boot_e820, __pa(&_start), __pa(&_end));
 
     /* Late kexec reservation (dynamic start address). */
     kexec_reserve_area(&boot_e820);
-- 
1.7.10.4

Re: [PATCH 17/18] x86/efi: create new early memory allocator

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -103,9 +103,35 @@ static void __init relocate_trampoline(unsigned long phys)
>          *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4;
>  }
>  
> +#define __MALLOC_SIZE	65536
> +
> +static char __malloc_mem[__MALLOC_SIZE];
> +static char *__malloc_free = NULL;
> +
> +static void __init *__malloc(size_t size)

Please do away with all these prefixing underscores.

> +{
> +    void *ptr;
> +
> +    /*
> +     * Init __malloc_free on runtime. Static initialization
> +     * will not work because it puts virtual address there.
> +     */
> +    if ( __malloc_free == NULL )
> +        __malloc_free = __malloc_mem;
> +
> +    ptr = __malloc_free;
> +
> +    __malloc_free += size;
> +
> +    if ( __malloc_free - __malloc_mem > sizeof(__malloc_mem) )
> +        blexit(L"Out of static memory\r\n");
> +
> +    return ptr;
> +}

You're ignoring alignment requirements here altogether.

> @@ -192,12 +218,7 @@ static void __init 
> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
>  
>  static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
>  {
> -    place_string(&mbi.mem_upper, NULL);
> -    mbi.mem_upper -= *map_size;
> -    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
> -    if ( mbi.mem_upper < xen_phys_start )
> -        return NULL;
> -    return (void *)(long)mbi.mem_upper;
> +    return __malloc(*map_size);
>  }

Which then even suggests that _if_ we go this route, this could be
shared with ARM (and hence become common code again).

Jan

Re: [PATCH 17/18] x86/efi: create new early memory allocator

[Roy Franz]

On Mon, Mar 2, 2015 at 9:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -103,9 +103,35 @@ static void __init relocate_trampoline(unsigned long phys)
>>          *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4;
>>  }
>>
>> +#define __MALLOC_SIZE        65536
>> +
>> +static char __malloc_mem[__MALLOC_SIZE];
>> +static char *__malloc_free = NULL;
>> +
>> +static void __init *__malloc(size_t size)
>
> Please do away with all these prefixing underscores.
>
>> +{
>> +    void *ptr;
>> +
>> +    /*
>> +     * Init __malloc_free on runtime. Static initialization
>> +     * will not work because it puts virtual address there.
>> +     */
>> +    if ( __malloc_free == NULL )
>> +        __malloc_free = __malloc_mem;
>> +
>> +    ptr = __malloc_free;
>> +
>> +    __malloc_free += size;
>> +
>> +    if ( __malloc_free - __malloc_mem > sizeof(__malloc_mem) )
>> +        blexit(L"Out of static memory\r\n");
>> +
>> +    return ptr;
>> +}
>
> You're ignoring alignment requirements here altogether.
>
>> @@ -192,12 +218,7 @@ static void __init
>> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
>>
>>  static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
>>  {
>> -    place_string(&mbi.mem_upper, NULL);
>> -    mbi.mem_upper -= *map_size;
>> -    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
>> -    if ( mbi.mem_upper < xen_phys_start )
>> -        return NULL;
>> -    return (void *)(long)mbi.mem_upper;
>> +    return __malloc(*map_size);
>>  }
>
> Which then even suggests that _if_ we go this route, this could be
> shared with ARM (and hence become common code again).
>
> Jan
>

We could do the same thing on ARM.  For ARM, 2 allocations are done: 1
for the FDT, and
this one for the EFI memory map.  Both of these are currently
allocated with EFI allocation
functions, so don't have fixed size limits.  If we go with the fixed
size pool, I don't think that 64k
will be enough for the ARM case, as FDTs can be 20-50k in size.

Roy

Re: [PATCH 17/18] x86/efi: create new early memory allocator

[Jan Beulich]

>>> On 02.03.15 at 21:25, <roy.franz@linaro.org> wrote:
> On Mon, Mar 2, 2015 at 9:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>> @@ -192,12 +218,7 @@ static void __init
>>> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
>>>
>>>  static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
>>>  {
>>> -    place_string(&mbi.mem_upper, NULL);
>>> -    mbi.mem_upper -= *map_size;
>>> -    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
>>> -    if ( mbi.mem_upper < xen_phys_start )
>>> -        return NULL;
>>> -    return (void *)(long)mbi.mem_upper;
>>> +    return __malloc(*map_size);
>>>  }
>>
>> Which then even suggests that _if_ we go this route, this could be
>> shared with ARM (and hence become common code again).
> 
> We could do the same thing on ARM.  For ARM, 2 allocations are done: 1
> for the FDT, and
> this one for the EFI memory map.  Both of these are currently
> allocated with EFI allocation
> functions, so don't have fixed size limits.  If we go with the fixed
> size pool, I don't think that 64k
> will be enough for the ARM case, as FDTs can be 20-50k in size.

The 64k size here is to be debated anyway I think. We currently have
about 1Mb in the x86 variant, and I'd much rather see the pool be
this size initially, properly taking care of releasing to the allocator any
unused portions of it.

Jan

Re: [PATCH 17/18] x86/efi: create new early memory allocator

[Jan Beulich]

>>> On 02.03.15 at 21:25, <roy.franz@linaro.org> wrote:
> On Mon, Mar 2, 2015 at 9:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>> @@ -192,12 +218,7 @@ static void __init
>>> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
>>>
>>>  static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
>>>  {
>>> -    place_string(&mbi.mem_upper, NULL);
>>> -    mbi.mem_upper -= *map_size;
>>> -    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
>>> -    if ( mbi.mem_upper < xen_phys_start )
>>> -        return NULL;
>>> -    return (void *)(long)mbi.mem_upper;
>>> +    return __malloc(*map_size);
>>>  }
>>
>> Which then even suggests that _if_ we go this route, this could be
>> shared with ARM (and hence become common code again).
> 
> We could do the same thing on ARM.  For ARM, 2 allocations are done: 1
> for the FDT, and
> this one for the EFI memory map.  Both of these are currently
> allocated with EFI allocation
> functions, so don't have fixed size limits.  If we go with the fixed
> size pool, I don't think that 64k
> will be enough for the ARM case, as FDTs can be 20-50k in size.

The 64k size here is to be debated anyway I think. We currently have
about 1Mb in the x86 variant, and I'd much rather see the pool be
this size initially, properly taking care of releasing to the allocator any
unused portions of it.

Jan

Re: [PATCH 17/18] x86/efi: create new early memory allocator

[Daniel Kiper]

On Tue, Mar 03, 2015 at 08:04:09AM +0000, Jan Beulich wrote:
> >>> On 02.03.15 at 21:25, <roy.franz@linaro.org> wrote:
> > On Mon, Mar 2, 2015 at 9:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >>> @@ -192,12 +218,7 @@ static void __init
> >>> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
> >>>
> >>>  static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
> >>>  {
> >>> -    place_string(&mbi.mem_upper, NULL);
> >>> -    mbi.mem_upper -= *map_size;
> >>> -    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
> >>> -    if ( mbi.mem_upper < xen_phys_start )
> >>> -        return NULL;
> >>> -    return (void *)(long)mbi.mem_upper;
> >>> +    return __malloc(*map_size);
> >>>  }
> >>
> >> Which then even suggests that _if_ we go this route, this could be
> >> shared with ARM (and hence become common code again).
> >
> > We could do the same thing on ARM.  For ARM, 2 allocations are done: 1
> > for the FDT, and
> > this one for the EFI memory map.  Both of these are currently
> > allocated with EFI allocation
> > functions, so don't have fixed size limits.  If we go with the fixed
> > size pool, I don't think that 64k
> > will be enough for the ARM case, as FDTs can be 20-50k in size.
>
> The 64k size here is to be debated anyway I think. We currently have
> about 1Mb in the x86 variant, and I'd much rather see the pool be
> this size initially, properly taking care of releasing to the allocator any
> unused portions of it.

Thanks for your comments guys. I will reply for all of them probably
next week. Now I am busy with bugs in GRUB2. Please stay tuned.

Daniel

Re: [PATCH 17/18] x86/efi: create new early memory allocator

[Daniel Kiper]

On Tue, Mar 03, 2015 at 08:04:09AM +0000, Jan Beulich wrote:
> >>> On 02.03.15 at 21:25, <roy.franz@linaro.org> wrote:
> > On Mon, Mar 2, 2015 at 9:23 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >>> @@ -192,12 +218,7 @@ static void __init
> >>> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
> >>>
> >>>  static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
> >>>  {
> >>> -    place_string(&mbi.mem_upper, NULL);
> >>> -    mbi.mem_upper -= *map_size;
> >>> -    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
> >>> -    if ( mbi.mem_upper < xen_phys_start )
> >>> -        return NULL;
> >>> -    return (void *)(long)mbi.mem_upper;
> >>> +    return __malloc(*map_size);
> >>>  }
> >>
> >> Which then even suggests that _if_ we go this route, this could be
> >> shared with ARM (and hence become common code again).
> >
> > We could do the same thing on ARM.  For ARM, 2 allocations are done: 1
> > for the FDT, and
> > this one for the EFI memory map.  Both of these are currently
> > allocated with EFI allocation
> > functions, so don't have fixed size limits.  If we go with the fixed
> > size pool, I don't think that 64k
> > will be enough for the ARM case, as FDTs can be 20-50k in size.
>
> The 64k size here is to be debated anyway I think. We currently have
> about 1Mb in the x86 variant, and I'd much rather see the pool be
> this size initially, properly taking care of releasing to the allocator any
> unused portions of it.

Thanks for your comments guys. I will reply for all of them probably
next week. Now I am busy with bugs in GRUB2. Please stay tuned.

Daniel

Re: [PATCH 17/18] x86/efi: create new early memory allocator

[Daniel Kiper]

On Mon, Mar 02, 2015 at 05:23:49PM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> > --- a/xen/arch/x86/efi/efi-boot.h
> > +++ b/xen/arch/x86/efi/efi-boot.h
> > @@ -103,9 +103,35 @@ static void __init relocate_trampoline(unsigned long phys)
> >          *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4;
> >  }
> >
> > +#define __MALLOC_SIZE	65536
> > +
> > +static char __malloc_mem[__MALLOC_SIZE];
> > +static char *__malloc_free = NULL;
> > +
> > +static void __init *__malloc(size_t size)
>
> Please do away with all these prefixing underscores.
>
> > +{
> > +    void *ptr;
> > +
> > +    /*
> > +     * Init __malloc_free on runtime. Static initialization
> > +     * will not work because it puts virtual address there.
> > +     */
> > +    if ( __malloc_free == NULL )
> > +        __malloc_free = __malloc_mem;
> > +
> > +    ptr = __malloc_free;
> > +
> > +    __malloc_free += size;
> > +
> > +    if ( __malloc_free - __malloc_mem > sizeof(__malloc_mem) )
> > +        blexit(L"Out of static memory\r\n");
> > +
> > +    return ptr;
> > +}
>
> You're ignoring alignment requirements here altogether.

I can understand why __malloc_mem should be let's say page aligned
but I am not sure why we should care here about alignment inside
of __malloc_mem array like...

> > @@ -192,12 +218,7 @@ static void __init
> > efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
> >
> >  static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
> >  {
> > -    place_string(&mbi.mem_upper, NULL);
> > -    mbi.mem_upper -= *map_size;
> > -    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);

...here...

> > -    if ( mbi.mem_upper < xen_phys_start )
> > -        return NULL;
> > -    return (void *)(long)mbi.mem_upper;
> > +    return __malloc(*map_size);
> >  }
>
> Which then even suggests that _if_ we go this route, this could be
> shared with ARM (and hence become common code again).

So, go or no go this route? If not what do you suggest?

Daniel

Re: [PATCH 17/18] x86/efi: create new early memory allocator

[Daniel Kiper]

On Mon, Mar 02, 2015 at 05:23:49PM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> > --- a/xen/arch/x86/efi/efi-boot.h
> > +++ b/xen/arch/x86/efi/efi-boot.h
> > @@ -103,9 +103,35 @@ static void __init relocate_trampoline(unsigned long phys)
> >          *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4;
> >  }
> >
> > +#define __MALLOC_SIZE	65536
> > +
> > +static char __malloc_mem[__MALLOC_SIZE];
> > +static char *__malloc_free = NULL;
> > +
> > +static void __init *__malloc(size_t size)
>
> Please do away with all these prefixing underscores.
>
> > +{
> > +    void *ptr;
> > +
> > +    /*
> > +     * Init __malloc_free on runtime. Static initialization
> > +     * will not work because it puts virtual address there.
> > +     */
> > +    if ( __malloc_free == NULL )
> > +        __malloc_free = __malloc_mem;
> > +
> > +    ptr = __malloc_free;
> > +
> > +    __malloc_free += size;
> > +
> > +    if ( __malloc_free - __malloc_mem > sizeof(__malloc_mem) )
> > +        blexit(L"Out of static memory\r\n");
> > +
> > +    return ptr;
> > +}
>
> You're ignoring alignment requirements here altogether.

I can understand why __malloc_mem should be let's say page aligned
but I am not sure why we should care here about alignment inside
of __malloc_mem array like...

> > @@ -192,12 +218,7 @@ static void __init
> > efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
> >
> >  static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
> >  {
> > -    place_string(&mbi.mem_upper, NULL);
> > -    mbi.mem_upper -= *map_size;
> > -    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);

...here...

> > -    if ( mbi.mem_upper < xen_phys_start )
> > -        return NULL;
> > -    return (void *)(long)mbi.mem_upper;
> > +    return __malloc(*map_size);
> >  }
>
> Which then even suggests that _if_ we go this route, this could be
> shared with ARM (and hence become common code again).

So, go or no go this route? If not what do you suggest?

Daniel

Re: [PATCH 17/18] x86/efi: create new early memory allocator

[Jan Beulich]

>>> On 27.03.15 at 13:57, <daniel.kiper@oracle.com> wrote:
> On Mon, Mar 02, 2015 at 05:23:49PM +0000, Jan Beulich wrote:
>> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> > +{
>> > +    void *ptr;
>> > +
>> > +    /*
>> > +     * Init __malloc_free on runtime. Static initialization
>> > +     * will not work because it puts virtual address there.
>> > +     */
>> > +    if ( __malloc_free == NULL )
>> > +        __malloc_free = __malloc_mem;
>> > +
>> > +    ptr = __malloc_free;
>> > +
>> > +    __malloc_free += size;
>> > +
>> > +    if ( __malloc_free - __malloc_mem > sizeof(__malloc_mem) )
>> > +        blexit(L"Out of static memory\r\n");
>> > +
>> > +    return ptr;
>> > +}
>>
>> You're ignoring alignment requirements here altogether.
> 
> I can understand why __malloc_mem should be let's say page aligned
> but I am not sure why we should care here about alignment inside
> of __malloc_mem array like...
> 
>> > @@ -192,12 +218,7 @@ static void __init
>> > efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
>> >
>> >  static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
>> >  {
>> > -    place_string(&mbi.mem_upper, NULL);
>> > -    mbi.mem_upper -= *map_size;
>> > -    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
> 
> ...here...

Specifically with the later mentioned potential for sharing this with
ARM I think you have to make sure that things are suitably aligned,
or else you cause aborts.

>> > -    if ( mbi.mem_upper < xen_phys_start )
>> > -        return NULL;
>> > -    return (void *)(long)mbi.mem_upper;
>> > +    return __malloc(*map_size);
>> >  }
>>
>> Which then even suggests that _if_ we go this route, this could be
>> shared with ARM (and hence become common code again).
> 
> So, go or no go this route?

As long as it's being done properly, I'm not wildly opposed.

Jan

Re: [PATCH 17/18] x86/efi: create new early memory allocator

[Daniel Kiper]

On Fri, Mar 27, 2015 at 01:35:11PM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 13:57, <daniel.kiper@oracle.com> wrote:
> > On Mon, Mar 02, 2015 at 05:23:49PM +0000, Jan Beulich wrote:
> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >> > +{
> >> > +    void *ptr;
> >> > +
> >> > +    /*
> >> > +     * Init __malloc_free on runtime. Static initialization
> >> > +     * will not work because it puts virtual address there.
> >> > +     */
> >> > +    if ( __malloc_free == NULL )
> >> > +        __malloc_free = __malloc_mem;
> >> > +
> >> > +    ptr = __malloc_free;
> >> > +
> >> > +    __malloc_free += size;
> >> > +
> >> > +    if ( __malloc_free - __malloc_mem > sizeof(__malloc_mem) )
> >> > +        blexit(L"Out of static memory\r\n");
> >> > +
> >> > +    return ptr;
> >> > +}
> >>
> >> You're ignoring alignment requirements here altogether.
> >
> > I can understand why __malloc_mem should be let's say page aligned
> > but I am not sure why we should care here about alignment inside
> > of __malloc_mem array like...
> >
> >> > @@ -192,12 +218,7 @@ static void __init
> >> > efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
> >> >
> >> >  static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
> >> >  {
> >> > -    place_string(&mbi.mem_upper, NULL);
> >> > -    mbi.mem_upper -= *map_size;
> >> > -    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
> >
> > ...here...
>
> Specifically with the later mentioned potential for sharing this with
> ARM I think you have to make sure that things are suitably aligned,
> or else you cause aborts.
>
> >> > -    if ( mbi.mem_upper < xen_phys_start )
> >> > -        return NULL;
> >> > -    return (void *)(long)mbi.mem_upper;
> >> > +    return __malloc(*map_size);
> >> >  }
> >>
> >> Which then even suggests that _if_ we go this route, this could be
> >> shared with ARM (and hence become common code again).
> >
> > So, go or no go this route?
>
> As long as it's being done properly, I'm not wildly opposed.

So, AIUI, general idea is OK but fix all stuff which should be fixed. Right?

Daniel

Re: [PATCH 17/18] x86/efi: create new early memory allocator

[Daniel Kiper]

On Fri, Mar 27, 2015 at 01:35:11PM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 13:57, <daniel.kiper@oracle.com> wrote:
> > On Mon, Mar 02, 2015 at 05:23:49PM +0000, Jan Beulich wrote:
> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >> > +{
> >> > +    void *ptr;
> >> > +
> >> > +    /*
> >> > +     * Init __malloc_free on runtime. Static initialization
> >> > +     * will not work because it puts virtual address there.
> >> > +     */
> >> > +    if ( __malloc_free == NULL )
> >> > +        __malloc_free = __malloc_mem;
> >> > +
> >> > +    ptr = __malloc_free;
> >> > +
> >> > +    __malloc_free += size;
> >> > +
> >> > +    if ( __malloc_free - __malloc_mem > sizeof(__malloc_mem) )
> >> > +        blexit(L"Out of static memory\r\n");
> >> > +
> >> > +    return ptr;
> >> > +}
> >>
> >> You're ignoring alignment requirements here altogether.
> >
> > I can understand why __malloc_mem should be let's say page aligned
> > but I am not sure why we should care here about alignment inside
> > of __malloc_mem array like...
> >
> >> > @@ -192,12 +218,7 @@ static void __init
> >> > efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
> >> >
> >> >  static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
> >> >  {
> >> > -    place_string(&mbi.mem_upper, NULL);
> >> > -    mbi.mem_upper -= *map_size;
> >> > -    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
> >
> > ...here...
>
> Specifically with the later mentioned potential for sharing this with
> ARM I think you have to make sure that things are suitably aligned,
> or else you cause aborts.
>
> >> > -    if ( mbi.mem_upper < xen_phys_start )
> >> > -        return NULL;
> >> > -    return (void *)(long)mbi.mem_upper;
> >> > +    return __malloc(*map_size);
> >> >  }
> >>
> >> Which then even suggests that _if_ we go this route, this could be
> >> shared with ARM (and hence become common code again).
> >
> > So, go or no go this route?
>
> As long as it's being done properly, I'm not wildly opposed.

So, AIUI, general idea is OK but fix all stuff which should be fixed. Right?

Daniel

Re: [PATCH 17/18] x86/efi: create new early memory allocator

[Jan Beulich]

>>> On 27.03.15 at 13:57, <daniel.kiper@oracle.com> wrote:
> On Mon, Mar 02, 2015 at 05:23:49PM +0000, Jan Beulich wrote:
>> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> > +{
>> > +    void *ptr;
>> > +
>> > +    /*
>> > +     * Init __malloc_free on runtime. Static initialization
>> > +     * will not work because it puts virtual address there.
>> > +     */
>> > +    if ( __malloc_free == NULL )
>> > +        __malloc_free = __malloc_mem;
>> > +
>> > +    ptr = __malloc_free;
>> > +
>> > +    __malloc_free += size;
>> > +
>> > +    if ( __malloc_free - __malloc_mem > sizeof(__malloc_mem) )
>> > +        blexit(L"Out of static memory\r\n");
>> > +
>> > +    return ptr;
>> > +}
>>
>> You're ignoring alignment requirements here altogether.
> 
> I can understand why __malloc_mem should be let's say page aligned
> but I am not sure why we should care here about alignment inside
> of __malloc_mem array like...
> 
>> > @@ -192,12 +218,7 @@ static void __init
>> > efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
>> >
>> >  static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
>> >  {
>> > -    place_string(&mbi.mem_upper, NULL);
>> > -    mbi.mem_upper -= *map_size;
>> > -    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
> 
> ...here...

Specifically with the later mentioned potential for sharing this with
ARM I think you have to make sure that things are suitably aligned,
or else you cause aborts.

>> > -    if ( mbi.mem_upper < xen_phys_start )
>> > -        return NULL;
>> > -    return (void *)(long)mbi.mem_upper;
>> > +    return __malloc(*map_size);
>> >  }
>>
>> Which then even suggests that _if_ we go this route, this could be
>> shared with ARM (and hence become common code again).
> 
> So, go or no go this route?

As long as it's being done properly, I'm not wildly opposed.

Jan

Re: [PATCH 17/18] x86/efi: create new early memory allocator

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -103,9 +103,35 @@ static void __init relocate_trampoline(unsigned long phys)
>          *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4;
>  }
>  
> +#define __MALLOC_SIZE	65536
> +
> +static char __malloc_mem[__MALLOC_SIZE];
> +static char *__malloc_free = NULL;
> +
> +static void __init *__malloc(size_t size)

Please do away with all these prefixing underscores.

> +{
> +    void *ptr;
> +
> +    /*
> +     * Init __malloc_free on runtime. Static initialization
> +     * will not work because it puts virtual address there.
> +     */
> +    if ( __malloc_free == NULL )
> +        __malloc_free = __malloc_mem;
> +
> +    ptr = __malloc_free;
> +
> +    __malloc_free += size;
> +
> +    if ( __malloc_free - __malloc_mem > sizeof(__malloc_mem) )
> +        blexit(L"Out of static memory\r\n");
> +
> +    return ptr;
> +}

You're ignoring alignment requirements here altogether.

> @@ -192,12 +218,7 @@ static void __init 
> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
>  
>  static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
>  {
> -    place_string(&mbi.mem_upper, NULL);
> -    mbi.mem_upper -= *map_size;
> -    mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
> -    if ( mbi.mem_upper < xen_phys_start )
> -        return NULL;
> -    return (void *)(long)mbi.mem_upper;
> +    return __malloc(*map_size);
>  }

Which then even suggests that _if_ we go this route, this could be
shared with ARM (and hence become common code again).

Jan

[PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 xen/arch/x86/boot/head.S          |  174 +++++++++++++++++++++++++++++++++++--
 xen/arch/x86/efi/efi-boot.h       |   29 +++++++
 xen/arch/x86/setup.c              |   23 ++---
 xen/arch/x86/x86_64/asm-offsets.c |    2 +
 xen/common/efi/boot.c             |   11 +++
 5 files changed, 222 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 7861057..89f5aa7 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -8,6 +8,7 @@
 #include <asm/page.h>
 #include <asm/msr.h>
 #include <asm/cpufeature.h>
+#include <asm/processor.h>
 
         .text
         .code32
@@ -57,6 +58,9 @@ ENTRY(start)
         .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
         .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
         .long   MULTIBOOT2_TAG_TYPE_MMAP
+        .long   MULTIBOOT2_TAG_TYPE_EFI_BS
+        .long   MULTIBOOT2_TAG_TYPE_EFI64
+        .long   MULTIBOOT2_TAG_TYPE_EFI64_IH
 .Lmultiboot2_info_req_end:
 
         .align  MULTIBOOT2_TAG_ALIGN
@@ -80,6 +84,19 @@ ENTRY(start)
         .long   0 /* Number of the lines - no preference. */
         .long   0 /* Number of bits per pixel - no preference. */
 
+        /* Do not disable EFI boot services. */
+        .align  MULTIBOOT2_TAG_ALIGN
+        .short  MULTIBOOT2_HEADER_TAG_EFI_BS
+        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
+        .long   8 /* Tag size. */
+
+        /* EFI64 entry point. */
+        .align  MULTIBOOT2_TAG_ALIGN
+        .short  MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64
+        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
+        .long   12 /* Tag size. */
+        .long   sym_phys(__efi64_start)
+
         /* Multiboot2 header end tag. */
         .align  MULTIBOOT2_TAG_ALIGN
         .short  MULTIBOOT2_HEADER_TAG_END
@@ -94,6 +111,17 @@ ENTRY(start)
 gdt_boot_descr:
         .word   6*8-1
         .long   sym_phys(trampoline_gdt)
+        .long   0 /* Needed for 64-bit lgdt */
+
+cs32_switch_addr:
+        .long   sym_phys(cs32_switch)
+        .long   BOOT_CS32
+
+efi_st:
+        .quad   0
+
+efi_ih:
+        .quad   0
 
 .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
 .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
@@ -124,6 +152,133 @@ print_err:
 .Lhalt: hlt
         jmp     .Lhalt
 
+        .code64
+
+__efi64_start:
+        cld
+
+        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
+        xor     %edx,%edx
+
+        /* Check for Multiboot2 bootloader */
+        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
+        je      efi_multiboot2_proto
+
+        jmp     not_multiboot
+
+efi_multiboot2_proto:
+        /* Skip Multiboot2 information fixed part */
+        lea     MB2_fixed_sizeof(%ebx),%ecx
+
+0:
+        /* Get mem_lower from Multiboot2 information */
+        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
+        jne     1f
+
+        mov     MB2_mem_lower(%ecx),%edx
+        jmp     4f
+
+1:
+        /* Get EFI SystemTable address from Multiboot2 information */
+        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
+        jne     2f
+
+        lea     MB2_efi64_st(%ecx),%esi
+        lea     efi_st(%rip),%edi
+        movsq
+
+        /* Do not go into real mode on EFI platform */
+        movb    $1,skip_realmode(%rip)
+
+        jmp     4f
+
+2:
+        /* Get EFI ImageHandle address from Multiboot2 information */
+        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64_IH,(%ecx)
+        jne     3f
+
+        lea     MB2_efi64_ih(%ecx),%esi
+        lea     efi_ih(%rip),%edi
+        movsq
+        jmp     4f
+
+3:
+        /* Is it the end of Multiboot2 information? */
+        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
+        je      run_bs
+
+4:
+        /* Go to next Multiboot2 information tag */
+        add     MB2_tag_size(%ecx),%ecx
+        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
+        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
+        jmp     0b
+
+run_bs:
+        push    %rax
+        push    %rdx
+
+        /* Initialize BSS (no nasty surprises!) */
+        lea     __bss_start(%rip),%rdi
+        lea     _end(%rip),%rcx
+        sub     %rdi,%rcx
+        xor     %rax,%rax
+        rep     stosb
+
+        mov     efi_ih(%rip),%rdi   /* EFI ImageHandle */
+        mov     efi_st(%rip),%rsi   /* EFI SystemTable */
+        call    efi_multiboot2
+
+        pop     %rcx
+        pop     %rax
+
+        shl     $10-4,%rcx          /* Convert multiboot2.mem_lower to bytes/16 */
+
+        cli
+
+        /* Initialise GDT */
+        lgdt    gdt_boot_descr(%rip)
+
+        /* Reload code selector */
+        ljmpl   *cs32_switch_addr(%rip)
+
+        .code32
+
+cs32_switch:
+        /* Initialise basic data segments */
+        mov     $BOOT_DS,%edx
+        mov     %edx,%ds
+        mov     %edx,%es
+        mov     %edx,%fs
+        mov     %edx,%gs
+        mov     %edx,%ss
+
+        mov     $sym_phys(cpu0_stack)+1024,%esp
+
+        /* Disable paging */
+        mov     %cr0,%edx
+        and     $(~X86_CR0_PG),%edx
+        mov     %edx,%cr0
+
+        push    %eax
+        push    %ecx
+
+        /* Disable Long Mode */
+        mov     $MSR_EFER,%ecx
+        rdmsr
+        and     $(~EFER_LME),%eax
+        wrmsr
+
+        pop     %ecx
+        pop     %eax
+
+        /* Turn off PAE */
+        mov     %cr4,%edx
+        and     $(~X86_CR4_PAE),%edx
+        mov     %edx,%cr4
+
+        jmp     trampoline_setup
+
 __start:
         cld
         cli
@@ -151,10 +306,10 @@ __start:
 multiboot1_proto:
         /* Get mem_lower from Multiboot information */
         testb   $MBI_MEMLIMITS,(%ebx)
-        jz      trampoline_setup    /* not available? BDA value will be fine */
+        jz      bios_platform       /* not available? BDA value will be fine */
 
         mov     MB_mem_lower(%ebx),%edx
-        jmp     trampoline_setup
+        jmp     bios_platform
 
 multiboot2_proto:
         /* Skip Multiboot2 information fixed part */
@@ -166,12 +321,12 @@ multiboot2_proto:
         jne     1f
 
         mov     MB2_mem_lower(%ecx),%edx
-        jmp     trampoline_setup
+        jmp     bios_platform
 
 1:
         /* Is it the end of Multiboot2 information? */
         cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
-        je      trampoline_setup
+        je      bios_platform
 
         /* Go to next Multiboot2 information tag */
         add     MB2_tag_size(%ecx),%ecx
@@ -179,7 +334,7 @@ multiboot2_proto:
         and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
         jmp     0b
 
-trampoline_setup:
+bios_platform:
         /* Set up trampoline segment 64k below EBDA */
         movzwl  0x40e,%ecx          /* EBDA segment */
         cmp     $0xa000,%ecx        /* sanity check (high) */
@@ -195,12 +350,13 @@ trampoline_setup:
          * multiboot structure (if available) and use the smallest.
          */
         cmp     $0x100,%edx         /* is the multiboot value too small? */
-        jb      2f                  /* if so, do not use it */
+        jb      trampoline_setup    /* if so, do not use it */
         shl     $10-4,%edx
         cmp     %ecx,%edx           /* compare with BDA value */
         cmovb   %edx,%ecx           /* and use the smaller */
 
-2:      /* Reserve 64kb for the trampoline */
+trampoline_setup:
+        /* Reserve 64kb for the trampoline */
         sub     $0x1000,%ecx
 
         /* From arch/x86/smpboot.c: start_eip had better be page-aligned! */
@@ -215,6 +371,9 @@ trampoline_setup:
         call    reloc               /* %ecx contains trampoline address */
         mov     %eax,sym_phys(multiboot_ptr)
 
+        cmpb    $1,sym_phys(skip_realmode)
+        je      1f
+
         /* Initialize BSS (no nasty surprises!) */
         mov     $sym_phys(__bss_start),%edi
         mov     $sym_phys(_end),%ecx
@@ -222,6 +381,7 @@ trampoline_setup:
         xor     %eax,%eax
         rep     stosb
 
+1:
         /* Interrogate CPU extended features via CPUID. */
         mov     $0x80000000,%eax
         cpuid
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 6e98bc8..f50c10a 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -223,6 +223,9 @@ static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
 
 static void __init efi_arch_pre_exit_boot(void)
 {
+    if ( !efi_loader )
+        return;
+
     if ( !trampoline_phys )
     {
         if ( !cfg.addr )
@@ -650,6 +653,32 @@ static bool_t __init efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable)
     return 1; /* x86 always uses a config file */
 }
 
+void __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
+{
+    EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
+    UINTN cols, gop_mode = ~0, rows;
+
+    efi_platform = 1;
+    efi_loader = 0;
+
+    efi_init(ImageHandle, SystemTable);
+
+    efi_console_set_mode();
+
+    if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
+                           &cols, &rows) == EFI_SUCCESS )
+        efi_arch_console_init(cols, rows);
+
+    gop = efi_get_gop();
+    gop_mode = efi_find_gop_mode(gop, 0, 0, 0);
+    efi_arch_edd();
+    efi_tables();
+    setup_efi_pci();
+    efi_variables();
+    efi_set_gop_mode(gop, gop_mode);
+    efi_exit_boot(ImageHandle, SystemTable);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index aebd010..8991b12 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -663,20 +663,23 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
         panic("Misaligned CPU0 stack.");
 
-    if ( efi_loader )
+    if ( efi_platform )
     {
-        set_pdx_range(xen_phys_start >> PAGE_SHIFT,
-                      (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
+        if ( efi_loader )
+        {
+            set_pdx_range(xen_phys_start >> PAGE_SHIFT,
+                          (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
 
-        /* Clean up boot loader identity mappings. */
-        destroy_xen_mappings(xen_phys_start,
-                             xen_phys_start + BOOTSTRAP_MAP_BASE);
+            /* Clean up boot loader identity mappings. */
+            destroy_xen_mappings(xen_phys_start,
+                                 xen_phys_start + BOOTSTRAP_MAP_BASE);
 
-        /* Make boot page tables match non-EFI boot. */
-        l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] =
-            l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR);
+            /* Make boot page tables match non-EFI boot. */
+            l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] =
+                l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR);
+        }
 
-        memmap_type = loader;
+        memmap_type = "EFI";
     }
     else if ( e820_raw_nr != 0 )
     {
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index ca3712f..d27596b 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -172,4 +172,6 @@ void __dummy__(void)
     DEFINE(MB2_fixed_sizeof, sizeof(multiboot2_fixed_t));
     OFFSET(MB2_tag_size, multiboot2_tag_t, size);
     OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
+    OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
+    OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
 }
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index f8be3dd..c5725ca 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -75,6 +75,17 @@ static size_t wstrlen(const CHAR16 * s);
 static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
 static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
 
+static void efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
+static void efi_console_set_mode(void);
+static EFI_GRAPHICS_OUTPUT_PROTOCOL *efi_get_gop(void);
+static UINTN efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
+                               UINTN cols, UINTN rows, UINTN depth);
+static void efi_tables(void);
+static void setup_efi_pci(void);
+static void efi_variables(void);
+static void efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop_mode);
+static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
+
 static const EFI_BOOT_SERVICES *__initdata efi_bs;
 static EFI_HANDLE __initdata efi_ih;
 
-- 
1.7.10.4

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Andrew Cooper]

On 30/01/15 17:54, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  xen/arch/x86/boot/head.S          |  174 +++++++++++++++++++++++++++++++++++--
>  xen/arch/x86/efi/efi-boot.h       |   29 +++++++
>  xen/arch/x86/setup.c              |   23 ++---
>  xen/arch/x86/x86_64/asm-offsets.c |    2 +
>  xen/common/efi/boot.c             |   11 +++
>  5 files changed, 222 insertions(+), 17 deletions(-)
>
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 7861057..89f5aa7 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -8,6 +8,7 @@
>  #include <asm/page.h>
>  #include <asm/msr.h>
>  #include <asm/cpufeature.h>
> +#include <asm/processor.h>
>  
>          .text
>          .code32
> @@ -57,6 +58,9 @@ ENTRY(start)
>          .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
>          .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
>          .long   MULTIBOOT2_TAG_TYPE_MMAP
> +        .long   MULTIBOOT2_TAG_TYPE_EFI_BS
> +        .long   MULTIBOOT2_TAG_TYPE_EFI64
> +        .long   MULTIBOOT2_TAG_TYPE_EFI64_IH
>  .Lmultiboot2_info_req_end:
>  
>          .align  MULTIBOOT2_TAG_ALIGN
> @@ -80,6 +84,19 @@ ENTRY(start)
>          .long   0 /* Number of the lines - no preference. */
>          .long   0 /* Number of bits per pixel - no preference. */
>  
> +        /* Do not disable EFI boot services. */
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_EFI_BS
> +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> +        .long   8 /* Tag size. */
> +
> +        /* EFI64 entry point. */
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64
> +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> +        .long   12 /* Tag size. */
> +        .long   sym_phys(__efi64_start)
> +
>          /* Multiboot2 header end tag. */
>          .align  MULTIBOOT2_TAG_ALIGN
>          .short  MULTIBOOT2_HEADER_TAG_END
> @@ -94,6 +111,17 @@ ENTRY(start)
>  gdt_boot_descr:
>          .word   6*8-1
>          .long   sym_phys(trampoline_gdt)
> +        .long   0 /* Needed for 64-bit lgdt */
> +
> +cs32_switch_addr:
> +        .long   sym_phys(cs32_switch)
> +        .long   BOOT_CS32

.word

ljmpl refers to an m32:16 not an m32:32

> +
> +efi_st:
> +        .quad   0
> +
> +efi_ih:
> +        .quad   0
>  
>  .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
>  .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
> @@ -124,6 +152,133 @@ print_err:
>  .Lhalt: hlt
>          jmp     .Lhalt
>  
> +        .code64
> +
> +__efi64_start:
> +        cld
> +
> +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> +        xor     %edx,%edx
> +
> +        /* Check for Multiboot2 bootloader */
> +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> +        je      efi_multiboot2_proto
> +
> +        jmp     not_multiboot

not_multiboot is 32bit code.  You must drop out of 64bit before using
it, or make a 64bit variant.

> +
> +efi_multiboot2_proto:
> +        /* Skip Multiboot2 information fixed part */
> +        lea     MB2_fixed_sizeof(%ebx),%ecx
> +
> +0:
> +        /* Get mem_lower from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> +        jne     1f
> +
> +        mov     MB2_mem_lower(%ecx),%edx
> +        jmp     4f
> +
> +1:
> +        /* Get EFI SystemTable address from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
> +        jne     2f
> +
> +        lea     MB2_efi64_st(%ecx),%esi
> +        lea     efi_st(%rip),%edi
> +        movsq

This is complete overkill for copying a 64bit variable out of the tag
and into a local variable.  Just use a plain 64bit load and store.

> +
> +        /* Do not go into real mode on EFI platform */
> +        movb    $1,skip_realmode(%rip)
> +
> +        jmp     4f
> +
> +2:
> +        /* Get EFI ImageHandle address from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64_IH,(%ecx)
> +        jne     3f
> +
> +        lea     MB2_efi64_ih(%ecx),%esi
> +        lea     efi_ih(%rip),%edi
> +        movsq

And here.

> +        jmp     4f
> +
> +3:
> +        /* Is it the end of Multiboot2 information? */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
> +        je      run_bs
> +
> +4:
> +        /* Go to next Multiboot2 information tag */
> +        add     MB2_tag_size(%ecx),%ecx
> +        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +        jmp     0b
> +
> +run_bs:
> +        push    %rax
> +        push    %rdx

Does the EFI spec guarantee that we have a good stack to use at this point?

> +
> +        /* Initialize BSS (no nasty surprises!) */
> +        lea     __bss_start(%rip),%rdi
> +        lea     _end(%rip),%rcx
> +        sub     %rdi,%rcx
> +        xor     %rax,%rax

xor %eax,%eax is shorter.

> +        rep     stosb

It would be more efficient to make sure that the linker aligns
__bss_start and _end on 8 byte boundaries, and use stosq instead.

> +
> +        mov     efi_ih(%rip),%rdi   /* EFI ImageHandle */
> +        mov     efi_st(%rip),%rsi   /* EFI SystemTable */
> +        call    efi_multiboot2
> +
> +        pop     %rcx
> +        pop     %rax
> +
> +        shl     $10-4,%rcx          /* Convert multiboot2.mem_lower to bytes/16 */
> +
> +        cli

This looks suspiciously out of place.  Surely the EFI spec doesn't
permit entry with interrupts enabled?

> +
> +        /* Initialise GDT */
> +        lgdt    gdt_boot_descr(%rip)
> +
> +        /* Reload code selector */
> +        ljmpl   *cs32_switch_addr(%rip)
> +
> +        .code32
> +
> +cs32_switch:
> +        /* Initialise basic data segments */
> +        mov     $BOOT_DS,%edx
> +        mov     %edx,%ds
> +        mov     %edx,%es
> +        mov     %edx,%fs
> +        mov     %edx,%gs
> +        mov     %edx,%ss
> +
> +        mov     $sym_phys(cpu0_stack)+1024,%esp
> +
> +        /* Disable paging */
> +        mov     %cr0,%edx
> +        and     $(~X86_CR0_PG),%edx
> +        mov     %edx,%cr0
> +
> +        push    %eax
> +        push    %ecx
> +
> +        /* Disable Long Mode */
> +        mov     $MSR_EFER,%ecx
> +        rdmsr
> +        and     $(~EFER_LME),%eax
> +        wrmsr
> +
> +        pop     %ecx
> +        pop     %eax
> +
> +        /* Turn off PAE */
> +        mov     %cr4,%edx
> +        and     $(~X86_CR4_PAE),%edx
> +        mov     %edx,%cr4
> +
> +        jmp     trampoline_setup
> +
>  __start:
>          cld
>          cli
> @@ -151,10 +306,10 @@ __start:
>  multiboot1_proto:
>          /* Get mem_lower from Multiboot information */
>          testb   $MBI_MEMLIMITS,(%ebx)
> -        jz      trampoline_setup    /* not available? BDA value will be fine */
> +        jz      bios_platform       /* not available? BDA value will be fine */
>  
>          mov     MB_mem_lower(%ebx),%edx
> -        jmp     trampoline_setup
> +        jmp     bios_platform
>  
>  multiboot2_proto:
>          /* Skip Multiboot2 information fixed part */
> @@ -166,12 +321,12 @@ multiboot2_proto:
>          jne     1f
>  
>          mov     MB2_mem_lower(%ecx),%edx
> -        jmp     trampoline_setup
> +        jmp     bios_platform
>  
>  1:
>          /* Is it the end of Multiboot2 information? */
>          cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
> -        je      trampoline_setup
> +        je      bios_platform
>  
>          /* Go to next Multiboot2 information tag */
>          add     MB2_tag_size(%ecx),%ecx
> @@ -179,7 +334,7 @@ multiboot2_proto:
>          and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
>          jmp     0b
>  
> -trampoline_setup:
> +bios_platform:
>          /* Set up trampoline segment 64k below EBDA */
>          movzwl  0x40e,%ecx          /* EBDA segment */
>          cmp     $0xa000,%ecx        /* sanity check (high) */
> @@ -195,12 +350,13 @@ trampoline_setup:
>           * multiboot structure (if available) and use the smallest.
>           */
>          cmp     $0x100,%edx         /* is the multiboot value too small? */
> -        jb      2f                  /* if so, do not use it */
> +        jb      trampoline_setup    /* if so, do not use it */
>          shl     $10-4,%edx
>          cmp     %ecx,%edx           /* compare with BDA value */
>          cmovb   %edx,%ecx           /* and use the smaller */
>  
> -2:      /* Reserve 64kb for the trampoline */
> +trampoline_setup:
> +        /* Reserve 64kb for the trampoline */
>          sub     $0x1000,%ecx
>  
>          /* From arch/x86/smpboot.c: start_eip had better be page-aligned! */
> @@ -215,6 +371,9 @@ trampoline_setup:
>          call    reloc               /* %ecx contains trampoline address */
>          mov     %eax,sym_phys(multiboot_ptr)
>  
> +        cmpb    $1,sym_phys(skip_realmode)
> +        je      1f
> +
>          /* Initialize BSS (no nasty surprises!) */
>          mov     $sym_phys(__bss_start),%edi
>          mov     $sym_phys(_end),%ecx
> @@ -222,6 +381,7 @@ trampoline_setup:
>          xor     %eax,%eax
>          rep     stosb
>  
> +1:
>          /* Interrogate CPU extended features via CPUID. */
>          mov     $0x80000000,%eax
>          cpuid
> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> index 6e98bc8..f50c10a 100644
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -223,6 +223,9 @@ static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
>  
>  static void __init efi_arch_pre_exit_boot(void)
>  {
> +    if ( !efi_loader )
> +        return;
> +
>      if ( !trampoline_phys )
>      {
>          if ( !cfg.addr )
> @@ -650,6 +653,32 @@ static bool_t __init efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable)
>      return 1; /* x86 always uses a config file */
>  }
>  
> +void __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
> +{
> +    EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
> +    UINTN cols, gop_mode = ~0, rows;
> +
> +    efi_platform = 1;
> +    efi_loader = 0;
> +
> +    efi_init(ImageHandle, SystemTable);
> +
> +    efi_console_set_mode();
> +
> +    if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
> +                           &cols, &rows) == EFI_SUCCESS )
> +        efi_arch_console_init(cols, rows);
> +
> +    gop = efi_get_gop();
> +    gop_mode = efi_find_gop_mode(gop, 0, 0, 0);
> +    efi_arch_edd();
> +    efi_tables();
> +    setup_efi_pci();
> +    efi_variables();
> +    efi_set_gop_mode(gop, gop_mode);
> +    efi_exit_boot(ImageHandle, SystemTable);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index aebd010..8991b12 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -663,20 +663,23 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>      if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
>          panic("Misaligned CPU0 stack.");
>  
> -    if ( efi_loader )
> +    if ( efi_platform )
>      {
> -        set_pdx_range(xen_phys_start >> PAGE_SHIFT,
> -                      (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
> +        if ( efi_loader )
> +        {
> +            set_pdx_range(xen_phys_start >> PAGE_SHIFT,
> +                          (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
>  
> -        /* Clean up boot loader identity mappings. */
> -        destroy_xen_mappings(xen_phys_start,
> -                             xen_phys_start + BOOTSTRAP_MAP_BASE);
> +            /* Clean up boot loader identity mappings. */
> +            destroy_xen_mappings(xen_phys_start,
> +                                 xen_phys_start + BOOTSTRAP_MAP_BASE);
>  
> -        /* Make boot page tables match non-EFI boot. */
> -        l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] =
> -            l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR);
> +            /* Make boot page tables match non-EFI boot. */
> +            l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] =
> +                l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR);
> +        }
>  
> -        memmap_type = loader;
> +        memmap_type = "EFI";
>      }
>      else if ( e820_raw_nr != 0 )
>      {
> diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
> index ca3712f..d27596b 100644
> --- a/xen/arch/x86/x86_64/asm-offsets.c
> +++ b/xen/arch/x86/x86_64/asm-offsets.c
> @@ -172,4 +172,6 @@ void __dummy__(void)
>      DEFINE(MB2_fixed_sizeof, sizeof(multiboot2_fixed_t));
>      OFFSET(MB2_tag_size, multiboot2_tag_t, size);
>      OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
> +    OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
> +    OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
>  }
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index f8be3dd..c5725ca 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -75,6 +75,17 @@ static size_t wstrlen(const CHAR16 * s);
>  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
>  static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
>  
> +static void efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
> +static void efi_console_set_mode(void);
> +static EFI_GRAPHICS_OUTPUT_PROTOCOL *efi_get_gop(void);
> +static UINTN efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> +                               UINTN cols, UINTN rows, UINTN depth);
> +static void efi_tables(void);
> +static void setup_efi_pci(void);
> +static void efi_variables(void);
> +static void efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop_mode);
> +static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
> +

If any of these forward declarations are needed, they should be
introduced in the appropriate create efi_$FOO patch.  However, I can't
spot a need for any of them.

~Andrew

>  static const EFI_BOOT_SERVICES *__initdata efi_bs;
>  static EFI_HANDLE __initdata efi_ih;
>  

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Andrew Cooper]

On 30/01/15 17:54, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  xen/arch/x86/boot/head.S          |  174 +++++++++++++++++++++++++++++++++++--
>  xen/arch/x86/efi/efi-boot.h       |   29 +++++++
>  xen/arch/x86/setup.c              |   23 ++---
>  xen/arch/x86/x86_64/asm-offsets.c |    2 +
>  xen/common/efi/boot.c             |   11 +++
>  5 files changed, 222 insertions(+), 17 deletions(-)
>
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 7861057..89f5aa7 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -8,6 +8,7 @@
>  #include <asm/page.h>
>  #include <asm/msr.h>
>  #include <asm/cpufeature.h>
> +#include <asm/processor.h>
>  
>          .text
>          .code32
> @@ -57,6 +58,9 @@ ENTRY(start)
>          .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
>          .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
>          .long   MULTIBOOT2_TAG_TYPE_MMAP
> +        .long   MULTIBOOT2_TAG_TYPE_EFI_BS
> +        .long   MULTIBOOT2_TAG_TYPE_EFI64
> +        .long   MULTIBOOT2_TAG_TYPE_EFI64_IH
>  .Lmultiboot2_info_req_end:
>  
>          .align  MULTIBOOT2_TAG_ALIGN
> @@ -80,6 +84,19 @@ ENTRY(start)
>          .long   0 /* Number of the lines - no preference. */
>          .long   0 /* Number of bits per pixel - no preference. */
>  
> +        /* Do not disable EFI boot services. */
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_EFI_BS
> +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> +        .long   8 /* Tag size. */
> +
> +        /* EFI64 entry point. */
> +        .align  MULTIBOOT2_TAG_ALIGN
> +        .short  MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64
> +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> +        .long   12 /* Tag size. */
> +        .long   sym_phys(__efi64_start)
> +
>          /* Multiboot2 header end tag. */
>          .align  MULTIBOOT2_TAG_ALIGN
>          .short  MULTIBOOT2_HEADER_TAG_END
> @@ -94,6 +111,17 @@ ENTRY(start)
>  gdt_boot_descr:
>          .word   6*8-1
>          .long   sym_phys(trampoline_gdt)
> +        .long   0 /* Needed for 64-bit lgdt */
> +
> +cs32_switch_addr:
> +        .long   sym_phys(cs32_switch)
> +        .long   BOOT_CS32

.word

ljmpl refers to an m32:16 not an m32:32

> +
> +efi_st:
> +        .quad   0
> +
> +efi_ih:
> +        .quad   0
>  
>  .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
>  .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
> @@ -124,6 +152,133 @@ print_err:
>  .Lhalt: hlt
>          jmp     .Lhalt
>  
> +        .code64
> +
> +__efi64_start:
> +        cld
> +
> +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> +        xor     %edx,%edx
> +
> +        /* Check for Multiboot2 bootloader */
> +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> +        je      efi_multiboot2_proto
> +
> +        jmp     not_multiboot

not_multiboot is 32bit code.  You must drop out of 64bit before using
it, or make a 64bit variant.

> +
> +efi_multiboot2_proto:
> +        /* Skip Multiboot2 information fixed part */
> +        lea     MB2_fixed_sizeof(%ebx),%ecx
> +
> +0:
> +        /* Get mem_lower from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> +        jne     1f
> +
> +        mov     MB2_mem_lower(%ecx),%edx
> +        jmp     4f
> +
> +1:
> +        /* Get EFI SystemTable address from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
> +        jne     2f
> +
> +        lea     MB2_efi64_st(%ecx),%esi
> +        lea     efi_st(%rip),%edi
> +        movsq

This is complete overkill for copying a 64bit variable out of the tag
and into a local variable.  Just use a plain 64bit load and store.

> +
> +        /* Do not go into real mode on EFI platform */
> +        movb    $1,skip_realmode(%rip)
> +
> +        jmp     4f
> +
> +2:
> +        /* Get EFI ImageHandle address from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64_IH,(%ecx)
> +        jne     3f
> +
> +        lea     MB2_efi64_ih(%ecx),%esi
> +        lea     efi_ih(%rip),%edi
> +        movsq

And here.

> +        jmp     4f
> +
> +3:
> +        /* Is it the end of Multiboot2 information? */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
> +        je      run_bs
> +
> +4:
> +        /* Go to next Multiboot2 information tag */
> +        add     MB2_tag_size(%ecx),%ecx
> +        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +        jmp     0b
> +
> +run_bs:
> +        push    %rax
> +        push    %rdx

Does the EFI spec guarantee that we have a good stack to use at this point?

> +
> +        /* Initialize BSS (no nasty surprises!) */
> +        lea     __bss_start(%rip),%rdi
> +        lea     _end(%rip),%rcx
> +        sub     %rdi,%rcx
> +        xor     %rax,%rax

xor %eax,%eax is shorter.

> +        rep     stosb

It would be more efficient to make sure that the linker aligns
__bss_start and _end on 8 byte boundaries, and use stosq instead.

> +
> +        mov     efi_ih(%rip),%rdi   /* EFI ImageHandle */
> +        mov     efi_st(%rip),%rsi   /* EFI SystemTable */
> +        call    efi_multiboot2
> +
> +        pop     %rcx
> +        pop     %rax
> +
> +        shl     $10-4,%rcx          /* Convert multiboot2.mem_lower to bytes/16 */
> +
> +        cli

This looks suspiciously out of place.  Surely the EFI spec doesn't
permit entry with interrupts enabled?

> +
> +        /* Initialise GDT */
> +        lgdt    gdt_boot_descr(%rip)
> +
> +        /* Reload code selector */
> +        ljmpl   *cs32_switch_addr(%rip)
> +
> +        .code32
> +
> +cs32_switch:
> +        /* Initialise basic data segments */
> +        mov     $BOOT_DS,%edx
> +        mov     %edx,%ds
> +        mov     %edx,%es
> +        mov     %edx,%fs
> +        mov     %edx,%gs
> +        mov     %edx,%ss
> +
> +        mov     $sym_phys(cpu0_stack)+1024,%esp
> +
> +        /* Disable paging */
> +        mov     %cr0,%edx
> +        and     $(~X86_CR0_PG),%edx
> +        mov     %edx,%cr0
> +
> +        push    %eax
> +        push    %ecx
> +
> +        /* Disable Long Mode */
> +        mov     $MSR_EFER,%ecx
> +        rdmsr
> +        and     $(~EFER_LME),%eax
> +        wrmsr
> +
> +        pop     %ecx
> +        pop     %eax
> +
> +        /* Turn off PAE */
> +        mov     %cr4,%edx
> +        and     $(~X86_CR4_PAE),%edx
> +        mov     %edx,%cr4
> +
> +        jmp     trampoline_setup
> +
>  __start:
>          cld
>          cli
> @@ -151,10 +306,10 @@ __start:
>  multiboot1_proto:
>          /* Get mem_lower from Multiboot information */
>          testb   $MBI_MEMLIMITS,(%ebx)
> -        jz      trampoline_setup    /* not available? BDA value will be fine */
> +        jz      bios_platform       /* not available? BDA value will be fine */
>  
>          mov     MB_mem_lower(%ebx),%edx
> -        jmp     trampoline_setup
> +        jmp     bios_platform
>  
>  multiboot2_proto:
>          /* Skip Multiboot2 information fixed part */
> @@ -166,12 +321,12 @@ multiboot2_proto:
>          jne     1f
>  
>          mov     MB2_mem_lower(%ecx),%edx
> -        jmp     trampoline_setup
> +        jmp     bios_platform
>  
>  1:
>          /* Is it the end of Multiboot2 information? */
>          cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
> -        je      trampoline_setup
> +        je      bios_platform
>  
>          /* Go to next Multiboot2 information tag */
>          add     MB2_tag_size(%ecx),%ecx
> @@ -179,7 +334,7 @@ multiboot2_proto:
>          and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
>          jmp     0b
>  
> -trampoline_setup:
> +bios_platform:
>          /* Set up trampoline segment 64k below EBDA */
>          movzwl  0x40e,%ecx          /* EBDA segment */
>          cmp     $0xa000,%ecx        /* sanity check (high) */
> @@ -195,12 +350,13 @@ trampoline_setup:
>           * multiboot structure (if available) and use the smallest.
>           */
>          cmp     $0x100,%edx         /* is the multiboot value too small? */
> -        jb      2f                  /* if so, do not use it */
> +        jb      trampoline_setup    /* if so, do not use it */
>          shl     $10-4,%edx
>          cmp     %ecx,%edx           /* compare with BDA value */
>          cmovb   %edx,%ecx           /* and use the smaller */
>  
> -2:      /* Reserve 64kb for the trampoline */
> +trampoline_setup:
> +        /* Reserve 64kb for the trampoline */
>          sub     $0x1000,%ecx
>  
>          /* From arch/x86/smpboot.c: start_eip had better be page-aligned! */
> @@ -215,6 +371,9 @@ trampoline_setup:
>          call    reloc               /* %ecx contains trampoline address */
>          mov     %eax,sym_phys(multiboot_ptr)
>  
> +        cmpb    $1,sym_phys(skip_realmode)
> +        je      1f
> +
>          /* Initialize BSS (no nasty surprises!) */
>          mov     $sym_phys(__bss_start),%edi
>          mov     $sym_phys(_end),%ecx
> @@ -222,6 +381,7 @@ trampoline_setup:
>          xor     %eax,%eax
>          rep     stosb
>  
> +1:
>          /* Interrogate CPU extended features via CPUID. */
>          mov     $0x80000000,%eax
>          cpuid
> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> index 6e98bc8..f50c10a 100644
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -223,6 +223,9 @@ static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
>  
>  static void __init efi_arch_pre_exit_boot(void)
>  {
> +    if ( !efi_loader )
> +        return;
> +
>      if ( !trampoline_phys )
>      {
>          if ( !cfg.addr )
> @@ -650,6 +653,32 @@ static bool_t __init efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable)
>      return 1; /* x86 always uses a config file */
>  }
>  
> +void __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
> +{
> +    EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
> +    UINTN cols, gop_mode = ~0, rows;
> +
> +    efi_platform = 1;
> +    efi_loader = 0;
> +
> +    efi_init(ImageHandle, SystemTable);
> +
> +    efi_console_set_mode();
> +
> +    if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
> +                           &cols, &rows) == EFI_SUCCESS )
> +        efi_arch_console_init(cols, rows);
> +
> +    gop = efi_get_gop();
> +    gop_mode = efi_find_gop_mode(gop, 0, 0, 0);
> +    efi_arch_edd();
> +    efi_tables();
> +    setup_efi_pci();
> +    efi_variables();
> +    efi_set_gop_mode(gop, gop_mode);
> +    efi_exit_boot(ImageHandle, SystemTable);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index aebd010..8991b12 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -663,20 +663,23 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>      if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
>          panic("Misaligned CPU0 stack.");
>  
> -    if ( efi_loader )
> +    if ( efi_platform )
>      {
> -        set_pdx_range(xen_phys_start >> PAGE_SHIFT,
> -                      (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
> +        if ( efi_loader )
> +        {
> +            set_pdx_range(xen_phys_start >> PAGE_SHIFT,
> +                          (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
>  
> -        /* Clean up boot loader identity mappings. */
> -        destroy_xen_mappings(xen_phys_start,
> -                             xen_phys_start + BOOTSTRAP_MAP_BASE);
> +            /* Clean up boot loader identity mappings. */
> +            destroy_xen_mappings(xen_phys_start,
> +                                 xen_phys_start + BOOTSTRAP_MAP_BASE);
>  
> -        /* Make boot page tables match non-EFI boot. */
> -        l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] =
> -            l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR);
> +            /* Make boot page tables match non-EFI boot. */
> +            l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] =
> +                l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR);
> +        }
>  
> -        memmap_type = loader;
> +        memmap_type = "EFI";
>      }
>      else if ( e820_raw_nr != 0 )
>      {
> diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
> index ca3712f..d27596b 100644
> --- a/xen/arch/x86/x86_64/asm-offsets.c
> +++ b/xen/arch/x86/x86_64/asm-offsets.c
> @@ -172,4 +172,6 @@ void __dummy__(void)
>      DEFINE(MB2_fixed_sizeof, sizeof(multiboot2_fixed_t));
>      OFFSET(MB2_tag_size, multiboot2_tag_t, size);
>      OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
> +    OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
> +    OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
>  }
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index f8be3dd..c5725ca 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -75,6 +75,17 @@ static size_t wstrlen(const CHAR16 * s);
>  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
>  static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
>  
> +static void efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
> +static void efi_console_set_mode(void);
> +static EFI_GRAPHICS_OUTPUT_PROTOCOL *efi_get_gop(void);
> +static UINTN efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> +                               UINTN cols, UINTN rows, UINTN depth);
> +static void efi_tables(void);
> +static void setup_efi_pci(void);
> +static void efi_variables(void);
> +static void efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop_mode);
> +static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
> +

If any of these forward declarations are needed, they should be
introduced in the appropriate create efi_$FOO patch.  However, I can't
spot a need for any of them.

~Andrew

>  static const EFI_BOOT_SERVICES *__initdata efi_bs;
>  static EFI_HANDLE __initdata efi_ih;
>  

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Fri, Jan 30, 2015 at 07:06:53PM +0000, Andrew Cooper wrote:
> On 30/01/15 17:54, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> > ---
> >  xen/arch/x86/boot/head.S          |  174 +++++++++++++++++++++++++++++++++++--
> >  xen/arch/x86/efi/efi-boot.h       |   29 +++++++
> >  xen/arch/x86/setup.c              |   23 ++---
> >  xen/arch/x86/x86_64/asm-offsets.c |    2 +
> >  xen/common/efi/boot.c             |   11 +++
> >  5 files changed, 222 insertions(+), 17 deletions(-)
> >
> > diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> > index 7861057..89f5aa7 100644
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -8,6 +8,7 @@
> >  #include <asm/page.h>
> >  #include <asm/msr.h>
> >  #include <asm/cpufeature.h>
> > +#include <asm/processor.h>
> >
> >          .text
> >          .code32
> > @@ -57,6 +58,9 @@ ENTRY(start)
> >          .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
> >          .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
> >          .long   MULTIBOOT2_TAG_TYPE_MMAP
> > +        .long   MULTIBOOT2_TAG_TYPE_EFI_BS
> > +        .long   MULTIBOOT2_TAG_TYPE_EFI64
> > +        .long   MULTIBOOT2_TAG_TYPE_EFI64_IH
> >  .Lmultiboot2_info_req_end:
> >
> >          .align  MULTIBOOT2_TAG_ALIGN
> > @@ -80,6 +84,19 @@ ENTRY(start)
> >          .long   0 /* Number of the lines - no preference. */
> >          .long   0 /* Number of bits per pixel - no preference. */
> >
> > +        /* Do not disable EFI boot services. */
> > +        .align  MULTIBOOT2_TAG_ALIGN
> > +        .short  MULTIBOOT2_HEADER_TAG_EFI_BS
> > +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> > +        .long   8 /* Tag size. */
> > +
> > +        /* EFI64 entry point. */
> > +        .align  MULTIBOOT2_TAG_ALIGN
> > +        .short  MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64
> > +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> > +        .long   12 /* Tag size. */
> > +        .long   sym_phys(__efi64_start)
> > +
> >          /* Multiboot2 header end tag. */
> >          .align  MULTIBOOT2_TAG_ALIGN
> >          .short  MULTIBOOT2_HEADER_TAG_END
> > @@ -94,6 +111,17 @@ ENTRY(start)
> >  gdt_boot_descr:
> >          .word   6*8-1
> >          .long   sym_phys(trampoline_gdt)
> > +        .long   0 /* Needed for 64-bit lgdt */
> > +
> > +cs32_switch_addr:
> > +        .long   sym_phys(cs32_switch)
> > +        .long   BOOT_CS32
>
> .word
>
> ljmpl refers to an m32:16 not an m32:32
>
> > +
> > +efi_st:
> > +        .quad   0
> > +
> > +efi_ih:
> > +        .quad   0
> >
> >  .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
> >  .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
> > @@ -124,6 +152,133 @@ print_err:
> >  .Lhalt: hlt
> >          jmp     .Lhalt
> >
> > +        .code64
> > +
> > +__efi64_start:
> > +        cld
> > +
> > +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> > +        xor     %edx,%edx
> > +
> > +        /* Check for Multiboot2 bootloader */
> > +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> > +        je      efi_multiboot2_proto
> > +
> > +        jmp     not_multiboot
>
> not_multiboot is 32bit code.  You must drop out of 64bit before using
> it, or make a 64bit variant.
>
> > +
> > +efi_multiboot2_proto:
> > +        /* Skip Multiboot2 information fixed part */
> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
> > +
> > +0:
> > +        /* Get mem_lower from Multiboot2 information */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> > +        jne     1f
> > +
> > +        mov     MB2_mem_lower(%ecx),%edx
> > +        jmp     4f
> > +
> > +1:
> > +        /* Get EFI SystemTable address from Multiboot2 information */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
> > +        jne     2f
> > +
> > +        lea     MB2_efi64_st(%ecx),%esi
> > +        lea     efi_st(%rip),%edi
> > +        movsq
>
> This is complete overkill for copying a 64bit variable out of the tag
> and into a local variable.  Just use a plain 64bit load and store.

I am not sure what do you mean by "64bit load and store" but I have
just realized that we do not need these variables. They are remnants
from early developments when I thought that we need ImageHandle
and SystemTable here and later somewhere else.

> > +        /* Do not go into real mode on EFI platform */
> > +        movb    $1,skip_realmode(%rip)
> > +
> > +        jmp     4f
> > +
> > +2:
> > +        /* Get EFI ImageHandle address from Multiboot2 information */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64_IH,(%ecx)
> > +        jne     3f
> > +
> > +        lea     MB2_efi64_ih(%ecx),%esi
> > +        lea     efi_ih(%rip),%edi
> > +        movsq
>
> And here.

Ditto.

> > +        jmp     4f
> > +
> > +3:
> > +        /* Is it the end of Multiboot2 information? */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
> > +        je      run_bs
> > +
> > +4:
> > +        /* Go to next Multiboot2 information tag */
> > +        add     MB2_tag_size(%ecx),%ecx
> > +        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +        jmp     0b
> > +
> > +run_bs:
> > +        push    %rax
> > +        push    %rdx
>
> Does the EFI spec guarantee that we have a good stack to use at this point?

Unified Extensible Firmware Interface Specification, Version 2.4 Errata B,
section 2.3.4, x64 Platforms says: During boot services time the processor
is in the following execution mode: ..., 128 KiB, or more, of available
stack space. GRUB2 uses this stack too and do not move it to different
memory region. So, I think that here we are on safe side.

> > +        /* Initialize BSS (no nasty surprises!) */
> > +        lea     __bss_start(%rip),%rdi
> > +        lea     _end(%rip),%rcx
> > +        sub     %rdi,%rcx
> > +        xor     %rax,%rax
>
> xor %eax,%eax is shorter.
>
> > +        rep     stosb
>
> It would be more efficient to make sure that the linker aligns
> __bss_start and _end on 8 byte boundaries, and use stosq instead.

Right but just for this. Is it pays? We do this only once.
However, if you wish...

> > +        mov     efi_ih(%rip),%rdi   /* EFI ImageHandle */
> > +        mov     efi_st(%rip),%rsi   /* EFI SystemTable */
> > +        call    efi_multiboot2
> > +
> > +        pop     %rcx
> > +        pop     %rax
> > +
> > +        shl     $10-4,%rcx          /* Convert multiboot2.mem_lower to bytes/16 */
> > +
> > +        cli
>
> This looks suspiciously out of place.  Surely the EFI spec doesn't
> permit entry with interrupts enabled?

Unified Extensible Firmware Interface Specification, Version 2.4 Errata B,
section 2.3.4, x64 Platforms says: During boot services time the processor
is in the following execution mode: ..., Interrupts are enabled–though no
interrupt services are supported other than the UEFI boot services timer
functions (All loaded device drivers are serviced synchronously by “polling.”).
So, I think that we should use BS with interrupts enabled and disable
them after ExitBootServices(). Hmmm... Now I think that we should use
cli immediately after efi_multiboot2() call.

[...]

> > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> > index 6e98bc8..f50c10a 100644
> > --- a/xen/arch/x86/efi/efi-boot.h
> > +++ b/xen/arch/x86/efi/efi-boot.h
> > @@ -223,6 +223,9 @@ static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
> >
> >  static void __init efi_arch_pre_exit_boot(void)
> >  {
> > +    if ( !efi_loader )
> > +        return;
> > +
> >      if ( !trampoline_phys )
> >      {
> >          if ( !cfg.addr )
> > @@ -650,6 +653,32 @@ static bool_t __init efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable)
> >      return 1; /* x86 always uses a config file */
> >  }
> >
> > +void __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
> > +{
> > +    EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
> > +    UINTN cols, gop_mode = ~0, rows;
> > +
> > +    efi_platform = 1;
> > +    efi_loader = 0;
> > +
> > +    efi_init(ImageHandle, SystemTable);
> > +
> > +    efi_console_set_mode();
> > +
> > +    if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
> > +                           &cols, &rows) == EFI_SUCCESS )
> > +        efi_arch_console_init(cols, rows);
> > +
> > +    gop = efi_get_gop();
> > +    gop_mode = efi_find_gop_mode(gop, 0, 0, 0);
> > +    efi_arch_edd();
> > +    efi_tables();
> > +    setup_efi_pci();
> > +    efi_variables();
> > +    efi_set_gop_mode(gop, gop_mode);
> > +    efi_exit_boot(ImageHandle, SystemTable);
> > +}
> > +
> >  /*
> >   * Local variables:
> >   * mode: C
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index aebd010..8991b12 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -663,20 +663,23 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >      if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
> >          panic("Misaligned CPU0 stack.");
> >
> > -    if ( efi_loader )
> > +    if ( efi_platform )
> >      {
> > -        set_pdx_range(xen_phys_start >> PAGE_SHIFT,
> > -                      (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
> > +        if ( efi_loader )
> > +        {
> > +            set_pdx_range(xen_phys_start >> PAGE_SHIFT,
> > +                          (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
> >
> > -        /* Clean up boot loader identity mappings. */
> > -        destroy_xen_mappings(xen_phys_start,
> > -                             xen_phys_start + BOOTSTRAP_MAP_BASE);
> > +            /* Clean up boot loader identity mappings. */
> > +            destroy_xen_mappings(xen_phys_start,
> > +                                 xen_phys_start + BOOTSTRAP_MAP_BASE);
> >
> > -        /* Make boot page tables match non-EFI boot. */
> > -        l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] =
> > -            l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR);
> > +            /* Make boot page tables match non-EFI boot. */
> > +            l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] =
> > +                l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR);
> > +        }
> >
> > -        memmap_type = loader;
> > +        memmap_type = "EFI";
> >      }
> >      else if ( e820_raw_nr != 0 )
> >      {
> > diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
> > index ca3712f..d27596b 100644
> > --- a/xen/arch/x86/x86_64/asm-offsets.c
> > +++ b/xen/arch/x86/x86_64/asm-offsets.c
> > @@ -172,4 +172,6 @@ void __dummy__(void)
> >      DEFINE(MB2_fixed_sizeof, sizeof(multiboot2_fixed_t));
> >      OFFSET(MB2_tag_size, multiboot2_tag_t, size);
> >      OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
> > +    OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
> > +    OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
> >  }
> > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> > index f8be3dd..c5725ca 100644
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -75,6 +75,17 @@ static size_t wstrlen(const CHAR16 * s);
> >  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
> >  static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
> >
> > +static void efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
> > +static void efi_console_set_mode(void);
> > +static EFI_GRAPHICS_OUTPUT_PROTOCOL *efi_get_gop(void);
> > +static UINTN efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> > +                               UINTN cols, UINTN rows, UINTN depth);
> > +static void efi_tables(void);
> > +static void setup_efi_pci(void);
> > +static void efi_variables(void);
> > +static void efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop_mode);
> > +static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
> > +
>
> If any of these forward declarations are needed, they should be

They are needed because efi-boot.h is included before above
mentioned functions definitions.

> introduced in the appropriate create efi_$FOO patch.  However, I can't

I thought about that during development. However, I stated that if I do what
you suggest then it is not clear who needs/uses these forward declarations.

> spot a need for any of them.

efi-boot.h:efi_multiboot2() uses them.

Daniel

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Andrew Cooper]

On 30/01/2015 23:43, Daniel Kiper wrote:
> On Fri, Jan 30, 2015 at 07:06:53PM +0000, Andrew Cooper wrote:
>> On 30/01/15 17:54, Daniel Kiper wrote:
>>> +
>>> +efi_multiboot2_proto:
>>> +        /* Skip Multiboot2 information fixed part */
>>> +        lea     MB2_fixed_sizeof(%ebx),%ecx
>>> +
>>> +0:
>>> +        /* Get mem_lower from Multiboot2 information */
>>> +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
>>> +        jne     1f
>>> +
>>> +        mov     MB2_mem_lower(%ecx),%edx
>>> +        jmp     4f
>>> +
>>> +1:
>>> +        /* Get EFI SystemTable address from Multiboot2 information */
>>> +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
>>> +        jne     2f
>>> +
>>> +        lea     MB2_efi64_st(%ecx),%esi
>>> +        lea     efi_st(%rip),%edi
>>> +        movsq
>> This is complete overkill for copying a 64bit variable out of the tag
>> and into a local variable.  Just use a plain 64bit load and store.
> I am not sure what do you mean by "64bit load and store" but I have
> just realized that we do not need these variables. They are remnants
> from early developments when I thought that we need ImageHandle
> and SystemTable here and later somewhere else.

mov MB2_efi64_st(%rcx), %rdi
mov %rdi, efi_st(%rip)

But if they are not needed, drop the code completely.

>>> +        jmp     4f
>>> +
>>> +3:
>>> +        /* Is it the end of Multiboot2 information? */
>>> +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
>>> +        je      run_bs
>>> +
>>> +4:
>>> +        /* Go to next Multiboot2 information tag */
>>> +        add     MB2_tag_size(%ecx),%ecx
>>> +        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
>>> +        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
>>> +        jmp     0b
>>> +
>>> +run_bs:
>>> +        push    %rax
>>> +        push    %rdx
>> Does the EFI spec guarantee that we have a good stack to use at this point?
> Unified Extensible Firmware Interface Specification, Version 2.4 Errata B,
> section 2.3.4, x64 Platforms says: During boot services time the processor
> is in the following execution mode: ..., 128 KiB, or more, of available
> stack space. GRUB2 uses this stack too and do not move it to different
> memory region. So, I think that here we are on safe side.

Sounds ok then.

>
>>> +        /* Initialize BSS (no nasty surprises!) */
>>> +        lea     __bss_start(%rip),%rdi
>>> +        lea     _end(%rip),%rcx
>>> +        sub     %rdi,%rcx
>>> +        xor     %rax,%rax
>> xor %eax,%eax is shorter.
>>
>>> +        rep     stosb
>> It would be more efficient to make sure that the linker aligns
>> __bss_start and _end on 8 byte boundaries, and use stosq instead.
> Right but just for this. Is it pays? We do this only once.

The BSS in Xen is 300k.  It is absolutely better to clear it 8 bytes at
a time rather than 1.

> However, if you wish...
>
>>> +        mov     efi_ih(%rip),%rdi   /* EFI ImageHandle */
>>> +        mov     efi_st(%rip),%rsi   /* EFI SystemTable */
>>> +        call    efi_multiboot2
>>> +
>>> +        pop     %rcx
>>> +        pop     %rax
>>> +
>>> +        shl     $10-4,%rcx          /* Convert multiboot2.mem_lower to bytes/16 */
>>> +
>>> +        cli
>> This looks suspiciously out of place.  Surely the EFI spec doesn't
>> permit entry with interrupts enabled?
> Unified Extensible Firmware Interface Specification, Version 2.4 Errata B,
> section 2.3.4, x64 Platforms says: During boot services time the processor
> is in the following execution mode: ..., Interrupts are enabled–though no
> interrupt services are supported other than the UEFI boot services timer
> functions (All loaded device drivers are serviced synchronously by “polling.”).
> So, I think that we should use BS with interrupts enabled and disable
> them after ExitBootServices(). Hmmm... Now I think that we should use
> cli immediately after efi_multiboot2() call.

I presume then that the firmware has set up a valid idt somewhere and is
actually serving any interrupts we get.

> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index f8be3dd..c5725ca 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -75,6 +75,17 @@ static size_t wstrlen(const CHAR16 * s);
>  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
>  static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
>
> +static void efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
> +static void efi_console_set_mode(void);
> +static EFI_GRAPHICS_OUTPUT_PROTOCOL *efi_get_gop(void);
> +static UINTN efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> +                               UINTN cols, UINTN rows, UINTN depth);
> +static void efi_tables(void);
> +static void setup_efi_pci(void);
> +static void efi_variables(void);
> +static void efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop_mode);
> +static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
> +
>> If any of these forward declarations are needed, they should be
> They are needed because efi-boot.h is included before above
> mentioned functions definitions.
>
>> introduced in the appropriate create efi_$FOO patch.  However, I can't
> I thought about that during development. However, I stated that if I do what
> you suggest then it is not clear who needs/uses these forward declarations.
>
>> spot a need for any of them.
> efi-boot.h:efi_multiboot2() uses them.

Ah - I see now.

~Andrew

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Andrew Cooper]

On 30/01/2015 23:43, Daniel Kiper wrote:
> On Fri, Jan 30, 2015 at 07:06:53PM +0000, Andrew Cooper wrote:
>> On 30/01/15 17:54, Daniel Kiper wrote:
>>> +
>>> +efi_multiboot2_proto:
>>> +        /* Skip Multiboot2 information fixed part */
>>> +        lea     MB2_fixed_sizeof(%ebx),%ecx
>>> +
>>> +0:
>>> +        /* Get mem_lower from Multiboot2 information */
>>> +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
>>> +        jne     1f
>>> +
>>> +        mov     MB2_mem_lower(%ecx),%edx
>>> +        jmp     4f
>>> +
>>> +1:
>>> +        /* Get EFI SystemTable address from Multiboot2 information */
>>> +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
>>> +        jne     2f
>>> +
>>> +        lea     MB2_efi64_st(%ecx),%esi
>>> +        lea     efi_st(%rip),%edi
>>> +        movsq
>> This is complete overkill for copying a 64bit variable out of the tag
>> and into a local variable.  Just use a plain 64bit load and store.
> I am not sure what do you mean by "64bit load and store" but I have
> just realized that we do not need these variables. They are remnants
> from early developments when I thought that we need ImageHandle
> and SystemTable here and later somewhere else.

mov MB2_efi64_st(%rcx), %rdi
mov %rdi, efi_st(%rip)

But if they are not needed, drop the code completely.

>>> +        jmp     4f
>>> +
>>> +3:
>>> +        /* Is it the end of Multiboot2 information? */
>>> +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
>>> +        je      run_bs
>>> +
>>> +4:
>>> +        /* Go to next Multiboot2 information tag */
>>> +        add     MB2_tag_size(%ecx),%ecx
>>> +        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
>>> +        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
>>> +        jmp     0b
>>> +
>>> +run_bs:
>>> +        push    %rax
>>> +        push    %rdx
>> Does the EFI spec guarantee that we have a good stack to use at this point?
> Unified Extensible Firmware Interface Specification, Version 2.4 Errata B,
> section 2.3.4, x64 Platforms says: During boot services time the processor
> is in the following execution mode: ..., 128 KiB, or more, of available
> stack space. GRUB2 uses this stack too and do not move it to different
> memory region. So, I think that here we are on safe side.

Sounds ok then.

>
>>> +        /* Initialize BSS (no nasty surprises!) */
>>> +        lea     __bss_start(%rip),%rdi
>>> +        lea     _end(%rip),%rcx
>>> +        sub     %rdi,%rcx
>>> +        xor     %rax,%rax
>> xor %eax,%eax is shorter.
>>
>>> +        rep     stosb
>> It would be more efficient to make sure that the linker aligns
>> __bss_start and _end on 8 byte boundaries, and use stosq instead.
> Right but just for this. Is it pays? We do this only once.

The BSS in Xen is 300k.  It is absolutely better to clear it 8 bytes at
a time rather than 1.

> However, if you wish...
>
>>> +        mov     efi_ih(%rip),%rdi   /* EFI ImageHandle */
>>> +        mov     efi_st(%rip),%rsi   /* EFI SystemTable */
>>> +        call    efi_multiboot2
>>> +
>>> +        pop     %rcx
>>> +        pop     %rax
>>> +
>>> +        shl     $10-4,%rcx          /* Convert multiboot2.mem_lower to bytes/16 */
>>> +
>>> +        cli
>> This looks suspiciously out of place.  Surely the EFI spec doesn't
>> permit entry with interrupts enabled?
> Unified Extensible Firmware Interface Specification, Version 2.4 Errata B,
> section 2.3.4, x64 Platforms says: During boot services time the processor
> is in the following execution mode: ..., Interrupts are enabled–though no
> interrupt services are supported other than the UEFI boot services timer
> functions (All loaded device drivers are serviced synchronously by “polling.”).
> So, I think that we should use BS with interrupts enabled and disable
> them after ExitBootServices(). Hmmm... Now I think that we should use
> cli immediately after efi_multiboot2() call.

I presume then that the firmware has set up a valid idt somewhere and is
actually serving any interrupts we get.

> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index f8be3dd..c5725ca 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -75,6 +75,17 @@ static size_t wstrlen(const CHAR16 * s);
>  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
>  static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
>
> +static void efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
> +static void efi_console_set_mode(void);
> +static EFI_GRAPHICS_OUTPUT_PROTOCOL *efi_get_gop(void);
> +static UINTN efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> +                               UINTN cols, UINTN rows, UINTN depth);
> +static void efi_tables(void);
> +static void setup_efi_pci(void);
> +static void efi_variables(void);
> +static void efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop_mode);
> +static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
> +
>> If any of these forward declarations are needed, they should be
> They are needed because efi-boot.h is included before above
> mentioned functions definitions.
>
>> introduced in the appropriate create efi_$FOO patch.  However, I can't
> I thought about that during development. However, I stated that if I do what
> you suggest then it is not clear who needs/uses these forward declarations.
>
>> spot a need for any of them.
> efi-boot.h:efi_multiboot2() uses them.

Ah - I see now.

~Andrew

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

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Fri, Jan 30, 2015 at 07:06:53PM +0000, Andrew Cooper wrote:
> On 30/01/15 17:54, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> > ---
> >  xen/arch/x86/boot/head.S          |  174 +++++++++++++++++++++++++++++++++++--
> >  xen/arch/x86/efi/efi-boot.h       |   29 +++++++
> >  xen/arch/x86/setup.c              |   23 ++---
> >  xen/arch/x86/x86_64/asm-offsets.c |    2 +
> >  xen/common/efi/boot.c             |   11 +++
> >  5 files changed, 222 insertions(+), 17 deletions(-)
> >
> > diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> > index 7861057..89f5aa7 100644
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -8,6 +8,7 @@
> >  #include <asm/page.h>
> >  #include <asm/msr.h>
> >  #include <asm/cpufeature.h>
> > +#include <asm/processor.h>
> >
> >          .text
> >          .code32
> > @@ -57,6 +58,9 @@ ENTRY(start)
> >          .long   .Lmultiboot2_info_req_end - .Lmultiboot2_info_req
> >          .long   MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO
> >          .long   MULTIBOOT2_TAG_TYPE_MMAP
> > +        .long   MULTIBOOT2_TAG_TYPE_EFI_BS
> > +        .long   MULTIBOOT2_TAG_TYPE_EFI64
> > +        .long   MULTIBOOT2_TAG_TYPE_EFI64_IH
> >  .Lmultiboot2_info_req_end:
> >
> >          .align  MULTIBOOT2_TAG_ALIGN
> > @@ -80,6 +84,19 @@ ENTRY(start)
> >          .long   0 /* Number of the lines - no preference. */
> >          .long   0 /* Number of bits per pixel - no preference. */
> >
> > +        /* Do not disable EFI boot services. */
> > +        .align  MULTIBOOT2_TAG_ALIGN
> > +        .short  MULTIBOOT2_HEADER_TAG_EFI_BS
> > +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> > +        .long   8 /* Tag size. */
> > +
> > +        /* EFI64 entry point. */
> > +        .align  MULTIBOOT2_TAG_ALIGN
> > +        .short  MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64
> > +        .short  MULTIBOOT2_HEADER_TAG_OPTIONAL
> > +        .long   12 /* Tag size. */
> > +        .long   sym_phys(__efi64_start)
> > +
> >          /* Multiboot2 header end tag. */
> >          .align  MULTIBOOT2_TAG_ALIGN
> >          .short  MULTIBOOT2_HEADER_TAG_END
> > @@ -94,6 +111,17 @@ ENTRY(start)
> >  gdt_boot_descr:
> >          .word   6*8-1
> >          .long   sym_phys(trampoline_gdt)
> > +        .long   0 /* Needed for 64-bit lgdt */
> > +
> > +cs32_switch_addr:
> > +        .long   sym_phys(cs32_switch)
> > +        .long   BOOT_CS32
>
> .word
>
> ljmpl refers to an m32:16 not an m32:32
>
> > +
> > +efi_st:
> > +        .quad   0
> > +
> > +efi_ih:
> > +        .quad   0
> >
> >  .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
> >  .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
> > @@ -124,6 +152,133 @@ print_err:
> >  .Lhalt: hlt
> >          jmp     .Lhalt
> >
> > +        .code64
> > +
> > +__efi64_start:
> > +        cld
> > +
> > +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> > +        xor     %edx,%edx
> > +
> > +        /* Check for Multiboot2 bootloader */
> > +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> > +        je      efi_multiboot2_proto
> > +
> > +        jmp     not_multiboot
>
> not_multiboot is 32bit code.  You must drop out of 64bit before using
> it, or make a 64bit variant.
>
> > +
> > +efi_multiboot2_proto:
> > +        /* Skip Multiboot2 information fixed part */
> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
> > +
> > +0:
> > +        /* Get mem_lower from Multiboot2 information */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> > +        jne     1f
> > +
> > +        mov     MB2_mem_lower(%ecx),%edx
> > +        jmp     4f
> > +
> > +1:
> > +        /* Get EFI SystemTable address from Multiboot2 information */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
> > +        jne     2f
> > +
> > +        lea     MB2_efi64_st(%ecx),%esi
> > +        lea     efi_st(%rip),%edi
> > +        movsq
>
> This is complete overkill for copying a 64bit variable out of the tag
> and into a local variable.  Just use a plain 64bit load and store.

I am not sure what do you mean by "64bit load and store" but I have
just realized that we do not need these variables. They are remnants
from early developments when I thought that we need ImageHandle
and SystemTable here and later somewhere else.

> > +        /* Do not go into real mode on EFI platform */
> > +        movb    $1,skip_realmode(%rip)
> > +
> > +        jmp     4f
> > +
> > +2:
> > +        /* Get EFI ImageHandle address from Multiboot2 information */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64_IH,(%ecx)
> > +        jne     3f
> > +
> > +        lea     MB2_efi64_ih(%ecx),%esi
> > +        lea     efi_ih(%rip),%edi
> > +        movsq
>
> And here.

Ditto.

> > +        jmp     4f
> > +
> > +3:
> > +        /* Is it the end of Multiboot2 information? */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
> > +        je      run_bs
> > +
> > +4:
> > +        /* Go to next Multiboot2 information tag */
> > +        add     MB2_tag_size(%ecx),%ecx
> > +        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +        jmp     0b
> > +
> > +run_bs:
> > +        push    %rax
> > +        push    %rdx
>
> Does the EFI spec guarantee that we have a good stack to use at this point?

Unified Extensible Firmware Interface Specification, Version 2.4 Errata B,
section 2.3.4, x64 Platforms says: During boot services time the processor
is in the following execution mode: ..., 128 KiB, or more, of available
stack space. GRUB2 uses this stack too and do not move it to different
memory region. So, I think that here we are on safe side.

> > +        /* Initialize BSS (no nasty surprises!) */
> > +        lea     __bss_start(%rip),%rdi
> > +        lea     _end(%rip),%rcx
> > +        sub     %rdi,%rcx
> > +        xor     %rax,%rax
>
> xor %eax,%eax is shorter.
>
> > +        rep     stosb
>
> It would be more efficient to make sure that the linker aligns
> __bss_start and _end on 8 byte boundaries, and use stosq instead.

Right but just for this. Is it pays? We do this only once.
However, if you wish...

> > +        mov     efi_ih(%rip),%rdi   /* EFI ImageHandle */
> > +        mov     efi_st(%rip),%rsi   /* EFI SystemTable */
> > +        call    efi_multiboot2
> > +
> > +        pop     %rcx
> > +        pop     %rax
> > +
> > +        shl     $10-4,%rcx          /* Convert multiboot2.mem_lower to bytes/16 */
> > +
> > +        cli
>
> This looks suspiciously out of place.  Surely the EFI spec doesn't
> permit entry with interrupts enabled?

Unified Extensible Firmware Interface Specification, Version 2.4 Errata B,
section 2.3.4, x64 Platforms says: During boot services time the processor
is in the following execution mode: ..., Interrupts are enabled–though no
interrupt services are supported other than the UEFI boot services timer
functions (All loaded device drivers are serviced synchronously by “polling.”).
So, I think that we should use BS with interrupts enabled and disable
them after ExitBootServices(). Hmmm... Now I think that we should use
cli immediately after efi_multiboot2() call.

[...]

> > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> > index 6e98bc8..f50c10a 100644
> > --- a/xen/arch/x86/efi/efi-boot.h
> > +++ b/xen/arch/x86/efi/efi-boot.h
> > @@ -223,6 +223,9 @@ static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
> >
> >  static void __init efi_arch_pre_exit_boot(void)
> >  {
> > +    if ( !efi_loader )
> > +        return;
> > +
> >      if ( !trampoline_phys )
> >      {
> >          if ( !cfg.addr )
> > @@ -650,6 +653,32 @@ static bool_t __init efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable)
> >      return 1; /* x86 always uses a config file */
> >  }
> >
> > +void __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
> > +{
> > +    EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
> > +    UINTN cols, gop_mode = ~0, rows;
> > +
> > +    efi_platform = 1;
> > +    efi_loader = 0;
> > +
> > +    efi_init(ImageHandle, SystemTable);
> > +
> > +    efi_console_set_mode();
> > +
> > +    if ( StdOut->QueryMode(StdOut, StdOut->Mode->Mode,
> > +                           &cols, &rows) == EFI_SUCCESS )
> > +        efi_arch_console_init(cols, rows);
> > +
> > +    gop = efi_get_gop();
> > +    gop_mode = efi_find_gop_mode(gop, 0, 0, 0);
> > +    efi_arch_edd();
> > +    efi_tables();
> > +    setup_efi_pci();
> > +    efi_variables();
> > +    efi_set_gop_mode(gop, gop_mode);
> > +    efi_exit_boot(ImageHandle, SystemTable);
> > +}
> > +
> >  /*
> >   * Local variables:
> >   * mode: C
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index aebd010..8991b12 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -663,20 +663,23 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >      if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
> >          panic("Misaligned CPU0 stack.");
> >
> > -    if ( efi_loader )
> > +    if ( efi_platform )
> >      {
> > -        set_pdx_range(xen_phys_start >> PAGE_SHIFT,
> > -                      (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
> > +        if ( efi_loader )
> > +        {
> > +            set_pdx_range(xen_phys_start >> PAGE_SHIFT,
> > +                          (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
> >
> > -        /* Clean up boot loader identity mappings. */
> > -        destroy_xen_mappings(xen_phys_start,
> > -                             xen_phys_start + BOOTSTRAP_MAP_BASE);
> > +            /* Clean up boot loader identity mappings. */
> > +            destroy_xen_mappings(xen_phys_start,
> > +                                 xen_phys_start + BOOTSTRAP_MAP_BASE);
> >
> > -        /* Make boot page tables match non-EFI boot. */
> > -        l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] =
> > -            l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR);
> > +            /* Make boot page tables match non-EFI boot. */
> > +            l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] =
> > +                l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR);
> > +        }
> >
> > -        memmap_type = loader;
> > +        memmap_type = "EFI";
> >      }
> >      else if ( e820_raw_nr != 0 )
> >      {
> > diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
> > index ca3712f..d27596b 100644
> > --- a/xen/arch/x86/x86_64/asm-offsets.c
> > +++ b/xen/arch/x86/x86_64/asm-offsets.c
> > @@ -172,4 +172,6 @@ void __dummy__(void)
> >      DEFINE(MB2_fixed_sizeof, sizeof(multiboot2_fixed_t));
> >      OFFSET(MB2_tag_size, multiboot2_tag_t, size);
> >      OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
> > +    OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
> > +    OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
> >  }
> > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> > index f8be3dd..c5725ca 100644
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -75,6 +75,17 @@ static size_t wstrlen(const CHAR16 * s);
> >  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
> >  static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
> >
> > +static void efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
> > +static void efi_console_set_mode(void);
> > +static EFI_GRAPHICS_OUTPUT_PROTOCOL *efi_get_gop(void);
> > +static UINTN efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> > +                               UINTN cols, UINTN rows, UINTN depth);
> > +static void efi_tables(void);
> > +static void setup_efi_pci(void);
> > +static void efi_variables(void);
> > +static void efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop_mode);
> > +static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable);
> > +
>
> If any of these forward declarations are needed, they should be

They are needed because efi-boot.h is included before above
mentioned functions definitions.

> introduced in the appropriate create efi_$FOO patch.  However, I can't

I thought about that during development. However, I stated that if I do what
you suggest then it is not clear who needs/uses these forward declarations.

> spot a need for any of them.

efi-boot.h:efi_multiboot2() uses them.

Daniel

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

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Fri, Jan 30, 2015 at 06:54:22PM +0100, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  xen/arch/x86/boot/head.S          |  174 +++++++++++++++++++++++++++++++++++--
>  xen/arch/x86/efi/efi-boot.h       |   29 +++++++
>  xen/arch/x86/setup.c              |   23 ++---
>  xen/arch/x86/x86_64/asm-offsets.c |    2 +
>  xen/common/efi/boot.c             |   11 +++
>  5 files changed, 222 insertions(+), 17 deletions(-)

After some testing we have found at least one machine on which this thing
does not work. It is Dell PowerEdge R820 with latest firmware. Machine
crashes/stops because early 32-bit code is not relocatable and must live
under 0x100000 address. (side note: I am surprised how it worked without
any issue until now; Multiboot protocol, any version, does not guarantee
that OS image will be loaded at specified/requested address; So, it looks
that there are not any legacy BIOS machines with e.g. 1 MiB - 2 MiB region
reserved in the wild or they are not very common; Am I missing something?).
Sadly, this region is used by BS, so, GRUB2 loads Xen higher (at least
above 64 MiB). Please look at memory map on this machine:

Type       Start            End              # Pages          Attributes
BS_Data    0000000000010000-000000000009FFFF 0000000000000090 000000000000000F
BS_Data    0000000000100000-0000000003FFFFFF 0000000000003F00 000000000000000F
Available  0000000004000000-000000000FFFEFFF 000000000000BFFF 000000000000000F
BS_Code    000000000FFFF000-000000001006CFFF 000000000000006E 000000000000000F
Available  000000001006D000-00000000B3E73FFF 00000000000A3E07 000000000000000F

[...]

Additionally, early Xen boot code maps only first 16 MiB of memory. Hence,
it means that jump into __high_start fails immediately.

Now I see two solutions for these issues:

1) We can make early 32-bit code relocatable. We may use something similar
   to xen/arch/x86/boot/trampoline.S:bootsym_rel(). Additionally, I think
   that early code should not blindly map first 16 MiB of memory. It should
   map first 1 MiB of memory and then 16 MiB of memory starting from
   xen_phys_start. This way we also fix long standing bug in early code
   which I described earlier.

2) We can jump from EFI x86-64 mode directly into "Xen x86-64 mode" like
   it is done in case of EFI loader. However, then we must duplicate multiboot2
   protocol implementation in x86-64 mode (if we wish that multiboot2 protocol
   can be used on legacy BIOS and EFI platforms; I think that we should support
   this protocol on both for users convenience). Additionally, we must use
   a workaround to relocate trampoline if boot services uses memory below 1 MiB
   (please check commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d, x86/EFI: make
   trampoline allocation more flexible, for more details).

I prefer #1 because this way we do not duplicate multiboot2 protocol implementation
(one for legacy BIOS and EFI) and we avoid issues with trampoline relocation when
low memory is occupied by boot services and/or 1:1 EFI page tables.

Daniel

PS I have just realized that commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d
   will not work if trampoline code will overwrite some of EFI 1:1 page tables.
   Dell PowerEdge R820 store part of 1:1 page tables below 1 MiB. Xen loaded
   by native EFI loader boots but it is only lucky coincidence that it does
   not overwrite used entries. So, I tend to go and choose #1 even more.

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Fri, Jan 30, 2015 at 06:54:22PM +0100, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  xen/arch/x86/boot/head.S          |  174 +++++++++++++++++++++++++++++++++++--
>  xen/arch/x86/efi/efi-boot.h       |   29 +++++++
>  xen/arch/x86/setup.c              |   23 ++---
>  xen/arch/x86/x86_64/asm-offsets.c |    2 +
>  xen/common/efi/boot.c             |   11 +++
>  5 files changed, 222 insertions(+), 17 deletions(-)

After some testing we have found at least one machine on which this thing
does not work. It is Dell PowerEdge R820 with latest firmware. Machine
crashes/stops because early 32-bit code is not relocatable and must live
under 0x100000 address. (side note: I am surprised how it worked without
any issue until now; Multiboot protocol, any version, does not guarantee
that OS image will be loaded at specified/requested address; So, it looks
that there are not any legacy BIOS machines with e.g. 1 MiB - 2 MiB region
reserved in the wild or they are not very common; Am I missing something?).
Sadly, this region is used by BS, so, GRUB2 loads Xen higher (at least
above 64 MiB). Please look at memory map on this machine:

Type       Start            End              # Pages          Attributes
BS_Data    0000000000010000-000000000009FFFF 0000000000000090 000000000000000F
BS_Data    0000000000100000-0000000003FFFFFF 0000000000003F00 000000000000000F
Available  0000000004000000-000000000FFFEFFF 000000000000BFFF 000000000000000F
BS_Code    000000000FFFF000-000000001006CFFF 000000000000006E 000000000000000F
Available  000000001006D000-00000000B3E73FFF 00000000000A3E07 000000000000000F

[...]

Additionally, early Xen boot code maps only first 16 MiB of memory. Hence,
it means that jump into __high_start fails immediately.

Now I see two solutions for these issues:

1) We can make early 32-bit code relocatable. We may use something similar
   to xen/arch/x86/boot/trampoline.S:bootsym_rel(). Additionally, I think
   that early code should not blindly map first 16 MiB of memory. It should
   map first 1 MiB of memory and then 16 MiB of memory starting from
   xen_phys_start. This way we also fix long standing bug in early code
   which I described earlier.

2) We can jump from EFI x86-64 mode directly into "Xen x86-64 mode" like
   it is done in case of EFI loader. However, then we must duplicate multiboot2
   protocol implementation in x86-64 mode (if we wish that multiboot2 protocol
   can be used on legacy BIOS and EFI platforms; I think that we should support
   this protocol on both for users convenience). Additionally, we must use
   a workaround to relocate trampoline if boot services uses memory below 1 MiB
   (please check commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d, x86/EFI: make
   trampoline allocation more flexible, for more details).

I prefer #1 because this way we do not duplicate multiboot2 protocol implementation
(one for legacy BIOS and EFI) and we avoid issues with trampoline relocation when
low memory is occupied by boot services and/or 1:1 EFI page tables.

Daniel

PS I have just realized that commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d
   will not work if trampoline code will overwrite some of EFI 1:1 page tables.
   Dell PowerEdge R820 store part of 1:1 page tables below 1 MiB. Xen loaded
   by native EFI loader boots but it is only lucky coincidence that it does
   not overwrite used entries. So, I tend to go and choose #1 even more.

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Andrew Cooper]

On 10/02/2015 21:27, Daniel Kiper wrote:
> On Fri, Jan 30, 2015 at 06:54:22PM +0100, Daniel Kiper wrote:
>> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>> ---
>>  xen/arch/x86/boot/head.S          |  174 +++++++++++++++++++++++++++++++++++--
>>  xen/arch/x86/efi/efi-boot.h       |   29 +++++++
>>  xen/arch/x86/setup.c              |   23 ++---
>>  xen/arch/x86/x86_64/asm-offsets.c |    2 +
>>  xen/common/efi/boot.c             |   11 +++
>>  5 files changed, 222 insertions(+), 17 deletions(-)
> After some testing we have found at least one machine on which this thing
> does not work. It is Dell PowerEdge R820 with latest firmware. Machine
> crashes/stops because early 32-bit code is not relocatable and must live
> under 0x100000 address. (side note: I am surprised how it worked without
> any issue until now; Multiboot protocol, any version, does not guarantee
> that OS image will be loaded at specified/requested address; So, it looks
> that there are not any legacy BIOS machines with e.g. 1 MiB - 2 MiB region
> reserved in the wild or they are not very common; Am I missing something?).
> Sadly, this region is used by BS, so, GRUB2 loads Xen higher (at least
> above 64 MiB). Please look at memory map on this machine:
>
> Type       Start            End              # Pages          Attributes
> BS_Data    0000000000010000-000000000009FFFF 0000000000000090 000000000000000F
> BS_Data    0000000000100000-0000000003FFFFFF 0000000000003F00 000000000000000F
> Available  0000000004000000-000000000FFFEFFF 000000000000BFFF 000000000000000F
> BS_Code    000000000FFFF000-000000001006CFFF 000000000000006E 000000000000000F
> Available  000000001006D000-00000000B3E73FFF 00000000000A3E07 000000000000000F
>
> [...]
>
> Additionally, early Xen boot code maps only first 16 MiB of memory. Hence,
> it means that jump into __high_start fails immediately.
>
> Now I see two solutions for these issues:
>
> 1) We can make early 32-bit code relocatable. We may use something similar
>    to xen/arch/x86/boot/trampoline.S:bootsym_rel(). Additionally, I think
>    that early code should not blindly map first 16 MiB of memory. It should
>    map first 1 MiB of memory and then 16 MiB of memory starting from
>    xen_phys_start. This way we also fix long standing bug in early code
>    which I described earlier.
>
> 2) We can jump from EFI x86-64 mode directly into "Xen x86-64 mode" like
>    it is done in case of EFI loader. However, then we must duplicate multiboot2
>    protocol implementation in x86-64 mode (if we wish that multiboot2 protocol
>    can be used on legacy BIOS and EFI platforms; I think that we should support
>    this protocol on both for users convenience). Additionally, we must use
>    a workaround to relocate trampoline if boot services uses memory below 1 MiB
>    (please check commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d, x86/EFI: make
>    trampoline allocation more flexible, for more details).
>
> I prefer #1 because this way we do not duplicate multiboot2 protocol implementation
> (one for legacy BIOS and EFI) and we avoid issues with trampoline relocation when
> low memory is occupied by boot services and/or 1:1 EFI page tables.
>
> Daniel
>
> PS I have just realized that commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d
>    will not work if trampoline code will overwrite some of EFI 1:1 page tables.
>    Dell PowerEdge R820 store part of 1:1 page tables below 1 MiB. Xen loaded
>    by native EFI loader boots but it is only lucky coincidence that it does
>    not overwrite used entries. So, I tend to go and choose #1 even more.

I have to admit to also being surprised at the fragility of the Xen, and
how it cannot function if _start isn't loaded on the 1MB boundary.

Given that there is provably one system in the wild which causes us to
fall over this limitation, it clearly needs fixing.

I would also agree that making the entry point relocatable is the
correct way forwards.  However, you cannot use something like
bootsym_rel() as that requires infrastructure to patch the references
(observe the loop over __trampoline_rel_{start,end} just before the call
to cmdline_parse_early())

This can probably be achieved by having a small bit of hand-written PIC
which puts an appropriate offset into %ds.

~Andrew

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Andrew Cooper]

On 10/02/2015 21:27, Daniel Kiper wrote:
> On Fri, Jan 30, 2015 at 06:54:22PM +0100, Daniel Kiper wrote:
>> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>> ---
>>  xen/arch/x86/boot/head.S          |  174 +++++++++++++++++++++++++++++++++++--
>>  xen/arch/x86/efi/efi-boot.h       |   29 +++++++
>>  xen/arch/x86/setup.c              |   23 ++---
>>  xen/arch/x86/x86_64/asm-offsets.c |    2 +
>>  xen/common/efi/boot.c             |   11 +++
>>  5 files changed, 222 insertions(+), 17 deletions(-)
> After some testing we have found at least one machine on which this thing
> does not work. It is Dell PowerEdge R820 with latest firmware. Machine
> crashes/stops because early 32-bit code is not relocatable and must live
> under 0x100000 address. (side note: I am surprised how it worked without
> any issue until now; Multiboot protocol, any version, does not guarantee
> that OS image will be loaded at specified/requested address; So, it looks
> that there are not any legacy BIOS machines with e.g. 1 MiB - 2 MiB region
> reserved in the wild or they are not very common; Am I missing something?).
> Sadly, this region is used by BS, so, GRUB2 loads Xen higher (at least
> above 64 MiB). Please look at memory map on this machine:
>
> Type       Start            End              # Pages          Attributes
> BS_Data    0000000000010000-000000000009FFFF 0000000000000090 000000000000000F
> BS_Data    0000000000100000-0000000003FFFFFF 0000000000003F00 000000000000000F
> Available  0000000004000000-000000000FFFEFFF 000000000000BFFF 000000000000000F
> BS_Code    000000000FFFF000-000000001006CFFF 000000000000006E 000000000000000F
> Available  000000001006D000-00000000B3E73FFF 00000000000A3E07 000000000000000F
>
> [...]
>
> Additionally, early Xen boot code maps only first 16 MiB of memory. Hence,
> it means that jump into __high_start fails immediately.
>
> Now I see two solutions for these issues:
>
> 1) We can make early 32-bit code relocatable. We may use something similar
>    to xen/arch/x86/boot/trampoline.S:bootsym_rel(). Additionally, I think
>    that early code should not blindly map first 16 MiB of memory. It should
>    map first 1 MiB of memory and then 16 MiB of memory starting from
>    xen_phys_start. This way we also fix long standing bug in early code
>    which I described earlier.
>
> 2) We can jump from EFI x86-64 mode directly into "Xen x86-64 mode" like
>    it is done in case of EFI loader. However, then we must duplicate multiboot2
>    protocol implementation in x86-64 mode (if we wish that multiboot2 protocol
>    can be used on legacy BIOS and EFI platforms; I think that we should support
>    this protocol on both for users convenience). Additionally, we must use
>    a workaround to relocate trampoline if boot services uses memory below 1 MiB
>    (please check commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d, x86/EFI: make
>    trampoline allocation more flexible, for more details).
>
> I prefer #1 because this way we do not duplicate multiboot2 protocol implementation
> (one for legacy BIOS and EFI) and we avoid issues with trampoline relocation when
> low memory is occupied by boot services and/or 1:1 EFI page tables.
>
> Daniel
>
> PS I have just realized that commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d
>    will not work if trampoline code will overwrite some of EFI 1:1 page tables.
>    Dell PowerEdge R820 store part of 1:1 page tables below 1 MiB. Xen loaded
>    by native EFI loader boots but it is only lucky coincidence that it does
>    not overwrite used entries. So, I tend to go and choose #1 even more.

I have to admit to also being surprised at the fragility of the Xen, and
how it cannot function if _start isn't loaded on the 1MB boundary.

Given that there is provably one system in the wild which causes us to
fall over this limitation, it clearly needs fixing.

I would also agree that making the entry point relocatable is the
correct way forwards.  However, you cannot use something like
bootsym_rel() as that requires infrastructure to patch the references
(observe the loop over __trampoline_rel_{start,end} just before the call
to cmdline_parse_early())

This can probably be achieved by having a small bit of hand-written PIC
which puts an appropriate offset into %ds.

~Andrew

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 10.02.15 at 22:27, <daniel.kiper@oracle.com> wrote:
> After some testing we have found at least one machine on which this thing
> does not work. It is Dell PowerEdge R820 with latest firmware. Machine
> crashes/stops because early 32-bit code is not relocatable and must live
> under 0x100000 address. (side note: I am surprised how it worked without
> any issue until now; Multiboot protocol, any version, does not guarantee
> that OS image will be loaded at specified/requested address;

How does it not? It's an ELF binary without relocations that's being
loaded - I can't see how such could be validly loaded anywhere but
at the virtual address(es) its program header states (and I don't
know whether grub [1 or 2] would correctly process relocations if
there were any, but I doubt it).

> Now I see two solutions for these issues:
> 
> 1) We can make early 32-bit code relocatable. We may use something similar
>    to xen/arch/x86/boot/trampoline.S:bootsym_rel(). Additionally, I think
>    that early code should not blindly map first 16 MiB of memory. It should
>    map first 1 MiB of memory and then 16 MiB of memory starting from
>    xen_phys_start. This way we also fix long standing bug in early code
>    which I described earlier.
> 
> 2) We can jump from EFI x86-64 mode directly into "Xen x86-64 mode" like
>    it is done in case of EFI loader. However, then we must duplicate 
> multiboot2
>    protocol implementation in x86-64 mode (if we wish that multiboot2 
> protocol
>    can be used on legacy BIOS and EFI platforms; I think that we should 
> support
>    this protocol on both for users convenience). Additionally, we must use
>    a workaround to relocate trampoline if boot services uses memory below 1 
> MiB
>    (please check commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d, x86/EFI: 
> make
>    trampoline allocation more flexible, for more details).
> 
> I prefer #1 because this way we do not duplicate multiboot2 protocol 
> implementation
> (one for legacy BIOS and EFI) and we avoid issues with trampoline relocation 
> when
> low memory is occupied by boot services and/or 1:1 EFI page tables.

Between the two, 1 is certainly the preferable option.

> PS I have just realized that commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d
>    will not work if trampoline code will overwrite some of EFI 1:1 page 
> tables.
>    Dell PowerEdge R820 store part of 1:1 page tables below 1 MiB. Xen loaded
>    by native EFI loader boots but it is only lucky coincidence that it does
>    not overwrite used entries. So, I tend to go and choose #1 even more.

How awful a firmware implementation! On PC-like systems, _nothing_
that _absolutely_ has to be below 1Mb should be placed there.

Jan

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 10.02.15 at 22:27, <daniel.kiper@oracle.com> wrote:
> After some testing we have found at least one machine on which this thing
> does not work. It is Dell PowerEdge R820 with latest firmware. Machine
> crashes/stops because early 32-bit code is not relocatable and must live
> under 0x100000 address. (side note: I am surprised how it worked without
> any issue until now; Multiboot protocol, any version, does not guarantee
> that OS image will be loaded at specified/requested address;

How does it not? It's an ELF binary without relocations that's being
loaded - I can't see how such could be validly loaded anywhere but
at the virtual address(es) its program header states (and I don't
know whether grub [1 or 2] would correctly process relocations if
there were any, but I doubt it).

> Now I see two solutions for these issues:
> 
> 1) We can make early 32-bit code relocatable. We may use something similar
>    to xen/arch/x86/boot/trampoline.S:bootsym_rel(). Additionally, I think
>    that early code should not blindly map first 16 MiB of memory. It should
>    map first 1 MiB of memory and then 16 MiB of memory starting from
>    xen_phys_start. This way we also fix long standing bug in early code
>    which I described earlier.
> 
> 2) We can jump from EFI x86-64 mode directly into "Xen x86-64 mode" like
>    it is done in case of EFI loader. However, then we must duplicate 
> multiboot2
>    protocol implementation in x86-64 mode (if we wish that multiboot2 
> protocol
>    can be used on legacy BIOS and EFI platforms; I think that we should 
> support
>    this protocol on both for users convenience). Additionally, we must use
>    a workaround to relocate trampoline if boot services uses memory below 1 
> MiB
>    (please check commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d, x86/EFI: 
> make
>    trampoline allocation more flexible, for more details).
> 
> I prefer #1 because this way we do not duplicate multiboot2 protocol 
> implementation
> (one for legacy BIOS and EFI) and we avoid issues with trampoline relocation 
> when
> low memory is occupied by boot services and/or 1:1 EFI page tables.

Between the two, 1 is certainly the preferable option.

> PS I have just realized that commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d
>    will not work if trampoline code will overwrite some of EFI 1:1 page 
> tables.
>    Dell PowerEdge R820 store part of 1:1 page tables below 1 MiB. Xen loaded
>    by native EFI loader boots but it is only lucky coincidence that it does
>    not overwrite used entries. So, I tend to go and choose #1 even more.

How awful a firmware implementation! On PC-like systems, _nothing_
that _absolutely_ has to be below 1Mb should be placed there.

Jan

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Andrei Borzenkov]

В Wed, 11 Feb 2015 08:20:04 +0000
"Jan Beulich" <JBeulich@suse.com> пишет:

> >>> On 10.02.15 at 22:27, <daniel.kiper@oracle.com> wrote:
> > After some testing we have found at least one machine on which this thing
> > does not work. It is Dell PowerEdge R820 with latest firmware. Machine
> > crashes/stops because early 32-bit code is not relocatable and must live
> > under 0x100000 address. (side note: I am surprised how it worked without
> > any issue until now; Multiboot protocol, any version, does not guarantee
> > that OS image will be loaded at specified/requested address;
> 
> How does it not? It's an ELF binary without relocations that's being
> loaded - I can't see how such could be validly loaded anywhere but
> at the virtual address(es) its program header states (and I don't
> know whether grub [1 or 2] would correctly process relocations if
> there were any, but I doubt it).
> 

grub2 relocates own modules when loading them. It does not do
relocation when loading Xen binary, but it does not sound impossible.

> > Now I see two solutions for these issues:
> > 
> > 1) We can make early 32-bit code relocatable. We may use something similar
> >    to xen/arch/x86/boot/trampoline.S:bootsym_rel(). Additionally, I think
> >    that early code should not blindly map first 16 MiB of memory. It should
> >    map first 1 MiB of memory and then 16 MiB of memory starting from
> >    xen_phys_start. This way we also fix long standing bug in early code
> >    which I described earlier.
> > 
> > 2) We can jump from EFI x86-64 mode directly into "Xen x86-64 mode" like
> >    it is done in case of EFI loader. However, then we must duplicate 
> > multiboot2
> >    protocol implementation in x86-64 mode (if we wish that multiboot2 
> > protocol
> >    can be used on legacy BIOS and EFI platforms; I think that we should 
> > support
> >    this protocol on both for users convenience). Additionally, we must use
> >    a workaround to relocate trampoline if boot services uses memory below 1 
> > MiB
> >    (please check commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d, x86/EFI: 
> > make
> >    trampoline allocation more flexible, for more details).
> > 
> > I prefer #1 because this way we do not duplicate multiboot2 protocol 
> > implementation
> > (one for legacy BIOS and EFI) and we avoid issues with trampoline relocation 
> > when
> > low memory is occupied by boot services and/or 1:1 EFI page tables.
> 
> Between the two, 1 is certainly the preferable option.
> 
> > PS I have just realized that commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d
> >    will not work if trampoline code will overwrite some of EFI 1:1 page 
> > tables.
> >    Dell PowerEdge R820 store part of 1:1 page tables below 1 MiB. Xen loaded
> >    by native EFI loader boots but it is only lucky coincidence that it does
> >    not overwrite used entries. So, I tend to go and choose #1 even more.
> 
> How awful a firmware implementation! On PC-like systems, _nothing_
> that _absolutely_ has to be below 1Mb should be placed there.
> 
> Jan
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Sat, Feb 14, 2015 at 08:23:45PM +0300, Andrei Borzenkov wrote:
> В Wed, 11 Feb 2015 08:20:04 +0000
> "Jan Beulich" <JBeulich@suse.com> пишет:
>
> > >>> On 10.02.15 at 22:27, <daniel.kiper@oracle.com> wrote:
> > > After some testing we have found at least one machine on which this thing
> > > does not work. It is Dell PowerEdge R820 with latest firmware. Machine
> > > crashes/stops because early 32-bit code is not relocatable and must live
> > > under 0x100000 address. (side note: I am surprised how it worked without
> > > any issue until now; Multiboot protocol, any version, does not guarantee
> > > that OS image will be loaded at specified/requested address;
> >
> > How does it not? It's an ELF binary without relocations that's being
> > loaded - I can't see how such could be validly loaded anywhere but
> > at the virtual address(es) its program header states (and I don't
> > know whether grub [1 or 2] would correctly process relocations if
> > there were any, but I doubt it).
> >
>
> grub2 relocates own modules when loading them. It does not do

Great! However, it also ignores MULTIBOOT_TAG_TYPE_EFI_BS flag
and overwrite BS if it leaves in region requested by image. It
is a bug which I have just discovered. I will fix it.

> relocation when loading Xen binary, but it does not sound impossible.

Ugh... You are right. I was confused because multiboot2 command just
allocate memory outside reserved regions. I thought that this is final
destination. However, later if you execute boot command then image
is relocated to final destination. Facepalm! Anyway, we must support
relocatable images in multiboot2 protocol. I think that image (any
format, e.g. PE) could inform loader that it can live anywhere below
4 GiB by setting special flag in multiboot2 header. Or ELF image could
have relocation section which would be interpreted by loader. Both
approaches make sense and are feasible.

Daniel

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

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Sat, Feb 14, 2015 at 08:23:45PM +0300, Andrei Borzenkov wrote:
> В Wed, 11 Feb 2015 08:20:04 +0000
> "Jan Beulich" <JBeulich@suse.com> пишет:
>
> > >>> On 10.02.15 at 22:27, <daniel.kiper@oracle.com> wrote:
> > > After some testing we have found at least one machine on which this thing
> > > does not work. It is Dell PowerEdge R820 with latest firmware. Machine
> > > crashes/stops because early 32-bit code is not relocatable and must live
> > > under 0x100000 address. (side note: I am surprised how it worked without
> > > any issue until now; Multiboot protocol, any version, does not guarantee
> > > that OS image will be loaded at specified/requested address;
> >
> > How does it not? It's an ELF binary without relocations that's being
> > loaded - I can't see how such could be validly loaded anywhere but
> > at the virtual address(es) its program header states (and I don't
> > know whether grub [1 or 2] would correctly process relocations if
> > there were any, but I doubt it).
> >
>
> grub2 relocates own modules when loading them. It does not do

Great! However, it also ignores MULTIBOOT_TAG_TYPE_EFI_BS flag
and overwrite BS if it leaves in region requested by image. It
is a bug which I have just discovered. I will fix it.

> relocation when loading Xen binary, but it does not sound impossible.

Ugh... You are right. I was confused because multiboot2 command just
allocate memory outside reserved regions. I thought that this is final
destination. However, later if you execute boot command then image
is relocated to final destination. Facepalm! Anyway, we must support
relocatable images in multiboot2 protocol. I think that image (any
format, e.g. PE) could inform loader that it can live anywhere below
4 GiB by setting special flag in multiboot2 header. Or ELF image could
have relocation section which would be interpreted by loader. Both
approaches make sense and are feasible.

Daniel

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Andrei Borzenkov]

В Wed, 11 Feb 2015 08:20:04 +0000
"Jan Beulich" <JBeulich@suse.com> пишет:

> >>> On 10.02.15 at 22:27, <daniel.kiper@oracle.com> wrote:
> > After some testing we have found at least one machine on which this thing
> > does not work. It is Dell PowerEdge R820 with latest firmware. Machine
> > crashes/stops because early 32-bit code is not relocatable and must live
> > under 0x100000 address. (side note: I am surprised how it worked without
> > any issue until now; Multiboot protocol, any version, does not guarantee
> > that OS image will be loaded at specified/requested address;
> 
> How does it not? It's an ELF binary without relocations that's being
> loaded - I can't see how such could be validly loaded anywhere but
> at the virtual address(es) its program header states (and I don't
> know whether grub [1 or 2] would correctly process relocations if
> there were any, but I doubt it).
> 

grub2 relocates own modules when loading them. It does not do
relocation when loading Xen binary, but it does not sound impossible.

> > Now I see two solutions for these issues:
> > 
> > 1) We can make early 32-bit code relocatable. We may use something similar
> >    to xen/arch/x86/boot/trampoline.S:bootsym_rel(). Additionally, I think
> >    that early code should not blindly map first 16 MiB of memory. It should
> >    map first 1 MiB of memory and then 16 MiB of memory starting from
> >    xen_phys_start. This way we also fix long standing bug in early code
> >    which I described earlier.
> > 
> > 2) We can jump from EFI x86-64 mode directly into "Xen x86-64 mode" like
> >    it is done in case of EFI loader. However, then we must duplicate 
> > multiboot2
> >    protocol implementation in x86-64 mode (if we wish that multiboot2 
> > protocol
> >    can be used on legacy BIOS and EFI platforms; I think that we should 
> > support
> >    this protocol on both for users convenience). Additionally, we must use
> >    a workaround to relocate trampoline if boot services uses memory below 1 
> > MiB
> >    (please check commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d, x86/EFI: 
> > make
> >    trampoline allocation more flexible, for more details).
> > 
> > I prefer #1 because this way we do not duplicate multiboot2 protocol 
> > implementation
> > (one for legacy BIOS and EFI) and we avoid issues with trampoline relocation 
> > when
> > low memory is occupied by boot services and/or 1:1 EFI page tables.
> 
> Between the two, 1 is certainly the preferable option.
> 
> > PS I have just realized that commit c1f2dfe8f6a559bc28935f24e31bb33d17d9713d
> >    will not work if trampoline code will overwrite some of EFI 1:1 page 
> > tables.
> >    Dell PowerEdge R820 store part of 1:1 page tables below 1 MiB. Xen loaded
> >    by native EFI loader boots but it is only lucky coincidence that it does
> >    not overwrite used entries. So, I tend to go and choose #1 even more.
> 
> How awful a firmware implementation! On PC-like systems, _nothing_
> that _absolutely_ has to be below 1Mb should be placed there.
> 
> Jan
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


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

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> @@ -94,6 +111,17 @@ ENTRY(start)
>  gdt_boot_descr:
>          .word   6*8-1
>          .long   sym_phys(trampoline_gdt)
> +        .long   0 /* Needed for 64-bit lgdt */
> +
> +cs32_switch_addr:
> +        .long   sym_phys(cs32_switch)
> +        .long   BOOT_CS32
> +
> +efi_st:
> +        .quad   0
> +
> +efi_ih:
> +        .quad   0
>  
>  .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
>  .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
> @@ -124,6 +152,133 @@ print_err:
>  .Lhalt: hlt
>          jmp     .Lhalt
>  
> +        .code64
> +
> +__efi64_start:
> +        cld
> +
> +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> +        xor     %edx,%edx
> +
> +        /* Check for Multiboot2 bootloader */
> +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> +        je      efi_multiboot2_proto
> +
> +        jmp     not_multiboot
> +
> +efi_multiboot2_proto:

jne not_multiboot (and efi_multiboot2_proto dropped altogether)

> +        /* Skip Multiboot2 information fixed part */
> +        lea     MB2_fixed_sizeof(%ebx),%ecx

Let's please not add more assumptions than necessary about stuff
being below 4G.

> +
> +0:
> +        /* Get mem_lower from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> +        jne     1f
> +
> +        mov     MB2_mem_lower(%ecx),%edx
> +        jmp     4f
> +
> +1:
> +        /* Get EFI SystemTable address from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
> +        jne     2f
> +
> +        lea     MB2_efi64_st(%ecx),%esi
> +        lea     efi_st(%rip),%edi
> +        movsq

A simple pair of mov-s please, assuming all of this really needs to be
done in assembly in the first place. Also please use .L<name> labels
in this assembly coded switch statement to ease reading.

> +
> +        /* Do not go into real mode on EFI platform */
> +        movb    $1,skip_realmode(%rip)
> +
> +        jmp     4f
> +
> +2:
> +        /* Get EFI ImageHandle address from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64_IH,(%ecx)
> +        jne     3f
> +
> +        lea     MB2_efi64_ih(%ecx),%esi
> +        lea     efi_ih(%rip),%edi
> +        movsq
> +        jmp     4f
> +
> +3:
> +        /* Is it the end of Multiboot2 information? */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
> +        je      run_bs
> +
> +4:

Please switch the order so that 2 can fall through into 4 (and you
then won't need the run_bs label, which otherwise should also
becom .Lrun_bs).

> +        /* Go to next Multiboot2 information tag */
> +        add     MB2_tag_size(%ecx),%ecx
> +        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +        jmp     0b
> +
> +run_bs:
> +        push    %rax
> +        push    %rdx
> +
> +        /* Initialize BSS (no nasty surprises!) */
> +        lea     __bss_start(%rip),%rdi
> +        lea     _end(%rip),%rcx
> +        sub     %rdi,%rcx
> +        xor     %rax,%rax
> +        rep     stosb

rep stosb

> +
> +        mov     efi_ih(%rip),%rdi   /* EFI ImageHandle */
> +        mov     efi_st(%rip),%rsi   /* EFI SystemTable */
> +        call    efi_multiboot2

With efi_multiboot2 being a C function it really looks like much of the
above doesn't need to be done in assembly.

> +
> +        pop     %rcx
> +        pop     %rax
> +
> +        shl     $10-4,%rcx          /* Convert multiboot2.mem_lower to bytes/16 */
> +
> +        cli
> +
> +        /* Initialise GDT */
> +        lgdt    gdt_boot_descr(%rip)
> +
> +        /* Reload code selector */
> +        ljmpl   *cs32_switch_addr(%rip)
> +
> +        .code32
> +
> +cs32_switch:
> +        /* Initialise basic data segments */
> +        mov     $BOOT_DS,%edx
> +        mov     %edx,%ds
> +        mov     %edx,%es
> +        mov     %edx,%fs
> +        mov     %edx,%gs
> +        mov     %edx,%ss
> +
> +        mov     $sym_phys(cpu0_stack)+1024,%esp
> +
> +        /* Disable paging */
> +        mov     %cr0,%edx
> +        and     $(~X86_CR0_PG),%edx
> +        mov     %edx,%cr0
> +
> +        push    %eax
> +        push    %ecx
> +
> +        /* Disable Long Mode */
> +        mov     $MSR_EFER,%ecx
> +        rdmsr
> +        and     $(~EFER_LME),%eax
> +        wrmsr

I don't think this is really needed.

> +
> +        pop     %ecx
> +        pop     %eax
> +
> +        /* Turn off PAE */
> +        mov     %cr4,%edx
> +        and     $(~X86_CR4_PAE),%edx
> +        mov     %edx,%cr4

Nor this.

> @@ -179,7 +334,7 @@ multiboot2_proto:
>          and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
>          jmp     0b
>  
> -trampoline_setup:
> +bios_platform:
>          /* Set up trampoline segment 64k below EBDA */

This is still trampoline setup code, so it's not clear why you rename
the label. If you need another named label ...

> @@ -195,12 +350,13 @@ trampoline_setup:
>           * multiboot structure (if available) and use the smallest.
>           */
>          cmp     $0x100,%edx         /* is the multiboot value too small? */
> -        jb      2f                  /* if so, do not use it */
> +        jb      trampoline_setup    /* if so, do not use it */
>          shl     $10-4,%edx
>          cmp     %ecx,%edx           /* compare with BDA value */
>          cmovb   %edx,%ecx           /* and use the smaller */
>  
> -2:      /* Reserve 64kb for the trampoline */
> +trampoline_setup:
> +        /* Reserve 64kb for the trampoline */

... here, then give it a name descriptive to the specific purpose
you have.

> @@ -215,6 +371,9 @@ trampoline_setup:
>          call    reloc               /* %ecx contains trampoline address */
>          mov     %eax,sym_phys(multiboot_ptr)
>  
> +        cmpb    $1,sym_phys(skip_realmode)
> +        je      1f
> +
>          /* Initialize BSS (no nasty surprises!) */

As the checked variable is completely unrelated to the purpose of
the code skipped, the code being added needs a comment.

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -663,20 +663,23 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>      if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
>          panic("Misaligned CPU0 stack.");
>  
> -    if ( efi_loader )
> +    if ( efi_platform )
>      {
> -        set_pdx_range(xen_phys_start >> PAGE_SHIFT,
> -                      (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
> +        if ( efi_loader )
> +        {
> +            set_pdx_range(xen_phys_start >> PAGE_SHIFT,
> +                          (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
>  
> -        /* Clean up boot loader identity mappings. */
> -        destroy_xen_mappings(xen_phys_start,
> -                             xen_phys_start + BOOTSTRAP_MAP_BASE);
> +            /* Clean up boot loader identity mappings. */
> +            destroy_xen_mappings(xen_phys_start,
> +                                 xen_phys_start + BOOTSTRAP_MAP_BASE);
>  
> -        /* Make boot page tables match non-EFI boot. */
> -        l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] =
> -            l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR);
> +            /* Make boot page tables match non-EFI boot. */
> +            l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] =
> +                l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR);
> +        }
>  
> -        memmap_type = loader;
> +        memmap_type = "EFI";
>      }

Please try to limit the churn you cause on existing code: Afaict all
you really need is the insertion of another else if (along with the
switch from efi_loader to efi_platform, which is subject to change
due to comments on earlier patches anyway).

Jan

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> @@ -94,6 +111,17 @@ ENTRY(start)
>  gdt_boot_descr:
>          .word   6*8-1
>          .long   sym_phys(trampoline_gdt)
> +        .long   0 /* Needed for 64-bit lgdt */
> +
> +cs32_switch_addr:
> +        .long   sym_phys(cs32_switch)
> +        .long   BOOT_CS32
> +
> +efi_st:
> +        .quad   0
> +
> +efi_ih:
> +        .quad   0
>  
>  .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
>  .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
> @@ -124,6 +152,133 @@ print_err:
>  .Lhalt: hlt
>          jmp     .Lhalt
>  
> +        .code64
> +
> +__efi64_start:
> +        cld
> +
> +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> +        xor     %edx,%edx
> +
> +        /* Check for Multiboot2 bootloader */
> +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> +        je      efi_multiboot2_proto
> +
> +        jmp     not_multiboot
> +
> +efi_multiboot2_proto:

jne not_multiboot (and efi_multiboot2_proto dropped altogether)

> +        /* Skip Multiboot2 information fixed part */
> +        lea     MB2_fixed_sizeof(%ebx),%ecx

Let's please not add more assumptions than necessary about stuff
being below 4G.

> +
> +0:
> +        /* Get mem_lower from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> +        jne     1f
> +
> +        mov     MB2_mem_lower(%ecx),%edx
> +        jmp     4f
> +
> +1:
> +        /* Get EFI SystemTable address from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
> +        jne     2f
> +
> +        lea     MB2_efi64_st(%ecx),%esi
> +        lea     efi_st(%rip),%edi
> +        movsq

A simple pair of mov-s please, assuming all of this really needs to be
done in assembly in the first place. Also please use .L<name> labels
in this assembly coded switch statement to ease reading.

> +
> +        /* Do not go into real mode on EFI platform */
> +        movb    $1,skip_realmode(%rip)
> +
> +        jmp     4f
> +
> +2:
> +        /* Get EFI ImageHandle address from Multiboot2 information */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64_IH,(%ecx)
> +        jne     3f
> +
> +        lea     MB2_efi64_ih(%ecx),%esi
> +        lea     efi_ih(%rip),%edi
> +        movsq
> +        jmp     4f
> +
> +3:
> +        /* Is it the end of Multiboot2 information? */
> +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
> +        je      run_bs
> +
> +4:

Please switch the order so that 2 can fall through into 4 (and you
then won't need the run_bs label, which otherwise should also
becom .Lrun_bs).

> +        /* Go to next Multiboot2 information tag */
> +        add     MB2_tag_size(%ecx),%ecx
> +        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +        jmp     0b
> +
> +run_bs:
> +        push    %rax
> +        push    %rdx
> +
> +        /* Initialize BSS (no nasty surprises!) */
> +        lea     __bss_start(%rip),%rdi
> +        lea     _end(%rip),%rcx
> +        sub     %rdi,%rcx
> +        xor     %rax,%rax
> +        rep     stosb

rep stosb

> +
> +        mov     efi_ih(%rip),%rdi   /* EFI ImageHandle */
> +        mov     efi_st(%rip),%rsi   /* EFI SystemTable */
> +        call    efi_multiboot2

With efi_multiboot2 being a C function it really looks like much of the
above doesn't need to be done in assembly.

> +
> +        pop     %rcx
> +        pop     %rax
> +
> +        shl     $10-4,%rcx          /* Convert multiboot2.mem_lower to bytes/16 */
> +
> +        cli
> +
> +        /* Initialise GDT */
> +        lgdt    gdt_boot_descr(%rip)
> +
> +        /* Reload code selector */
> +        ljmpl   *cs32_switch_addr(%rip)
> +
> +        .code32
> +
> +cs32_switch:
> +        /* Initialise basic data segments */
> +        mov     $BOOT_DS,%edx
> +        mov     %edx,%ds
> +        mov     %edx,%es
> +        mov     %edx,%fs
> +        mov     %edx,%gs
> +        mov     %edx,%ss
> +
> +        mov     $sym_phys(cpu0_stack)+1024,%esp
> +
> +        /* Disable paging */
> +        mov     %cr0,%edx
> +        and     $(~X86_CR0_PG),%edx
> +        mov     %edx,%cr0
> +
> +        push    %eax
> +        push    %ecx
> +
> +        /* Disable Long Mode */
> +        mov     $MSR_EFER,%ecx
> +        rdmsr
> +        and     $(~EFER_LME),%eax
> +        wrmsr

I don't think this is really needed.

> +
> +        pop     %ecx
> +        pop     %eax
> +
> +        /* Turn off PAE */
> +        mov     %cr4,%edx
> +        and     $(~X86_CR4_PAE),%edx
> +        mov     %edx,%cr4

Nor this.

> @@ -179,7 +334,7 @@ multiboot2_proto:
>          and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
>          jmp     0b
>  
> -trampoline_setup:
> +bios_platform:
>          /* Set up trampoline segment 64k below EBDA */

This is still trampoline setup code, so it's not clear why you rename
the label. If you need another named label ...

> @@ -195,12 +350,13 @@ trampoline_setup:
>           * multiboot structure (if available) and use the smallest.
>           */
>          cmp     $0x100,%edx         /* is the multiboot value too small? */
> -        jb      2f                  /* if so, do not use it */
> +        jb      trampoline_setup    /* if so, do not use it */
>          shl     $10-4,%edx
>          cmp     %ecx,%edx           /* compare with BDA value */
>          cmovb   %edx,%ecx           /* and use the smaller */
>  
> -2:      /* Reserve 64kb for the trampoline */
> +trampoline_setup:
> +        /* Reserve 64kb for the trampoline */

... here, then give it a name descriptive to the specific purpose
you have.

> @@ -215,6 +371,9 @@ trampoline_setup:
>          call    reloc               /* %ecx contains trampoline address */
>          mov     %eax,sym_phys(multiboot_ptr)
>  
> +        cmpb    $1,sym_phys(skip_realmode)
> +        je      1f
> +
>          /* Initialize BSS (no nasty surprises!) */

As the checked variable is completely unrelated to the purpose of
the code skipped, the code being added needs a comment.

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -663,20 +663,23 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>      if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
>          panic("Misaligned CPU0 stack.");
>  
> -    if ( efi_loader )
> +    if ( efi_platform )
>      {
> -        set_pdx_range(xen_phys_start >> PAGE_SHIFT,
> -                      (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
> +        if ( efi_loader )
> +        {
> +            set_pdx_range(xen_phys_start >> PAGE_SHIFT,
> +                          (xen_phys_start + BOOTSTRAP_MAP_BASE) >> PAGE_SHIFT);
>  
> -        /* Clean up boot loader identity mappings. */
> -        destroy_xen_mappings(xen_phys_start,
> -                             xen_phys_start + BOOTSTRAP_MAP_BASE);
> +            /* Clean up boot loader identity mappings. */
> +            destroy_xen_mappings(xen_phys_start,
> +                                 xen_phys_start + BOOTSTRAP_MAP_BASE);
>  
> -        /* Make boot page tables match non-EFI boot. */
> -        l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] =
> -            l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR);
> +            /* Make boot page tables match non-EFI boot. */
> +            l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] =
> +                l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR);
> +        }
>  
> -        memmap_type = loader;
> +        memmap_type = "EFI";
>      }

Please try to limit the churn you cause on existing code: Afaict all
you really need is the insertion of another else if (along with the
switch from efi_loader to efi_platform, which is subject to change
due to comments on earlier patches anyway).

Jan

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> > @@ -94,6 +111,17 @@ ENTRY(start)
> >  gdt_boot_descr:
> >          .word   6*8-1
> >          .long   sym_phys(trampoline_gdt)
> > +        .long   0 /* Needed for 64-bit lgdt */
> > +
> > +cs32_switch_addr:
> > +        .long   sym_phys(cs32_switch)
> > +        .long   BOOT_CS32
> > +
> > +efi_st:
> > +        .quad   0
> > +
> > +efi_ih:
> > +        .quad   0
> >
> >  .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
> >  .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
> > @@ -124,6 +152,133 @@ print_err:
> >  .Lhalt: hlt
> >          jmp     .Lhalt
> >
> > +        .code64
> > +
> > +__efi64_start:
> > +        cld
> > +
> > +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> > +        xor     %edx,%edx
> > +
> > +        /* Check for Multiboot2 bootloader */
> > +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> > +        je      efi_multiboot2_proto
> > +
> > +        jmp     not_multiboot
> > +
> > +efi_multiboot2_proto:
>
> jne not_multiboot (and efi_multiboot2_proto dropped altogether)

[...]

Jan, thanks for your comments. Now I am working on relocatable early Xen code.
I hope that I will finish that this week and start tests on this crazy
UEFI platforms. Then I get back to this patch series and replay for your
and other guys comments.

Daniel

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> > @@ -94,6 +111,17 @@ ENTRY(start)
> >  gdt_boot_descr:
> >          .word   6*8-1
> >          .long   sym_phys(trampoline_gdt)
> > +        .long   0 /* Needed for 64-bit lgdt */
> > +
> > +cs32_switch_addr:
> > +        .long   sym_phys(cs32_switch)
> > +        .long   BOOT_CS32
> > +
> > +efi_st:
> > +        .quad   0
> > +
> > +efi_ih:
> > +        .quad   0
> >
> >  .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
> >  .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
> > @@ -124,6 +152,133 @@ print_err:
> >  .Lhalt: hlt
> >          jmp     .Lhalt
> >
> > +        .code64
> > +
> > +__efi64_start:
> > +        cld
> > +
> > +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> > +        xor     %edx,%edx
> > +
> > +        /* Check for Multiboot2 bootloader */
> > +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> > +        je      efi_multiboot2_proto
> > +
> > +        jmp     not_multiboot
> > +
> > +efi_multiboot2_proto:
>
> jne not_multiboot (and efi_multiboot2_proto dropped altogether)

[...]

Jan, thanks for your comments. Now I am working on relocatable early Xen code.
I hope that I will finish that this week and start tests on this crazy
UEFI platforms. Then I get back to this patch series and replay for your
and other guys comments.

Daniel

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> > @@ -94,6 +111,17 @@ ENTRY(start)
> >  gdt_boot_descr:
> >          .word   6*8-1
> >          .long   sym_phys(trampoline_gdt)
> > +        .long   0 /* Needed for 64-bit lgdt */
> > +
> > +cs32_switch_addr:
> > +        .long   sym_phys(cs32_switch)
> > +        .long   BOOT_CS32
> > +
> > +efi_st:
> > +        .quad   0
> > +
> > +efi_ih:
> > +        .quad   0
> >
> >  .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
> >  .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
> > @@ -124,6 +152,133 @@ print_err:
> >  .Lhalt: hlt
> >          jmp     .Lhalt
> >
> > +        .code64
> > +
> > +__efi64_start:
> > +        cld
> > +
> > +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> > +        xor     %edx,%edx
> > +
> > +        /* Check for Multiboot2 bootloader */
> > +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> > +        je      efi_multiboot2_proto
> > +
> > +        jmp     not_multiboot
> > +
> > +efi_multiboot2_proto:
>
> jne not_multiboot (and efi_multiboot2_proto dropped altogether)
>
> > +        /* Skip Multiboot2 information fixed part */
> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
>
> Let's please not add more assumptions than necessary about stuff
> being below 4G.

I am not sure what do you mean by that.

> > +
> > +0:
> > +        /* Get mem_lower from Multiboot2 information */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> > +        jne     1f
> > +
> > +        mov     MB2_mem_lower(%ecx),%edx
> > +        jmp     4f
> > +
> > +1:
> > +        /* Get EFI SystemTable address from Multiboot2 information */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
> > +        jne     2f
> > +
> > +        lea     MB2_efi64_st(%ecx),%esi
> > +        lea     efi_st(%rip),%edi
> > +        movsq
>
> A simple pair of mov-s please, assuming all of this really needs to be
> done in assembly in the first place. Also please use .L<name> labels
> in this assembly coded switch statement to ease reading.
>
> > +
> > +        /* Do not go into real mode on EFI platform */
> > +        movb    $1,skip_realmode(%rip)
> > +
> > +        jmp     4f
> > +
> > +2:
> > +        /* Get EFI ImageHandle address from Multiboot2 information */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64_IH,(%ecx)
> > +        jne     3f
> > +
> > +        lea     MB2_efi64_ih(%ecx),%esi
> > +        lea     efi_ih(%rip),%edi
> > +        movsq
> > +        jmp     4f
> > +
> > +3:
> > +        /* Is it the end of Multiboot2 information? */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
> > +        je      run_bs
> > +
> > +4:
>
> Please switch the order so that 2 can fall through into 4 (and you
> then won't need the run_bs label, which otherwise should also
> becom .Lrun_bs).
>
> > +        /* Go to next Multiboot2 information tag */
> > +        add     MB2_tag_size(%ecx),%ecx
> > +        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +        jmp     0b
> > +
> > +run_bs:
> > +        push    %rax
> > +        push    %rdx
> > +
> > +        /* Initialize BSS (no nasty surprises!) */
> > +        lea     __bss_start(%rip),%rdi
> > +        lea     _end(%rip),%rcx
> > +        sub     %rdi,%rcx
> > +        xor     %rax,%rax
> > +        rep     stosb
>
> rep stosb
>
> > +
> > +        mov     efi_ih(%rip),%rdi   /* EFI ImageHandle */
> > +        mov     efi_st(%rip),%rsi   /* EFI SystemTable */
> > +        call    efi_multiboot2
>
> With efi_multiboot2 being a C function it really looks like much of the
> above doesn't need to be done in assembly.

Potentially make sense. I will try to do that.

Daniel

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 27.03.15 at 14:06, <daniel.kiper@oracle.com> wrote:
> On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
>> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> > +        /* Skip Multiboot2 information fixed part */
>> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
>>
>> Let's please not add more assumptions than necessary about stuff
>> being below 4G.
> 
> I am not sure what do you mean by that.

See the 32-bit register used for addressing here (and in many more
places)?

Jan

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Fri, Mar 27, 2015 at 01:36:32PM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 14:06, <daniel.kiper@oracle.com> wrote:
> > On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >> > +        /* Skip Multiboot2 information fixed part */
> >> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
> >>
> >> Let's please not add more assumptions than necessary about stuff
> >> being below 4G.
> >
> > I am not sure what do you mean by that.
>
> See the 32-bit register used for addressing here (and in many more
> places)?

This is what I expected but I was confused because you were referring only
here to this problem. Anyway, is it possible to do this in different way?
Should we care if image is always loaded at 0x100000 right now? Even with
Xen early boot code being relocatable loader could not load image higher
than 0xffffffff - 14 MiB.

Daniel

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Fri, Mar 27, 2015 at 01:36:32PM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 14:06, <daniel.kiper@oracle.com> wrote:
> > On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >> > +        /* Skip Multiboot2 information fixed part */
> >> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
> >>
> >> Let's please not add more assumptions than necessary about stuff
> >> being below 4G.
> >
> > I am not sure what do you mean by that.
>
> See the 32-bit register used for addressing here (and in many more
> places)?

This is what I expected but I was confused because you were referring only
here to this problem. Anyway, is it possible to do this in different way?
Should we care if image is always loaded at 0x100000 right now? Even with
Xen early boot code being relocatable loader could not load image higher
than 0xffffffff - 14 MiB.

Daniel

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 27.03.15 at 15:26, <daniel.kiper@oracle.com> wrote:
> On Fri, Mar 27, 2015 at 01:36:32PM +0000, Jan Beulich wrote:
>> >>> On 27.03.15 at 14:06, <daniel.kiper@oracle.com> wrote:
>> > On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
>> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> >> > +        /* Skip Multiboot2 information fixed part */
>> >> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
>> >>
>> >> Let's please not add more assumptions than necessary about stuff
>> >> being below 4G.
>> >
>> > I am not sure what do you mean by that.
>>
>> See the 32-bit register used for addressing here (and in many more
>> places)?
> 
> This is what I expected but I was confused because you were referring only
> here to this problem. Anyway, is it possible to do this in different way?
> Should we care if image is always loaded at 0x100000 right now? Even with
> Xen early boot code being relocatable loader could not load image higher
> than 0xffffffff - 14 MiB.

I don't understand what you're alluding to. Just use 64-bit registers
for memory accesses and LEAs, and be done. This will result in smaller
code as a benefit.

Jan

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Fri, Mar 27, 2015 at 02:34:19PM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 15:26, <daniel.kiper@oracle.com> wrote:
> > On Fri, Mar 27, 2015 at 01:36:32PM +0000, Jan Beulich wrote:
> >> >>> On 27.03.15 at 14:06, <daniel.kiper@oracle.com> wrote:
> >> > On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
> >> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >> >> > +        /* Skip Multiboot2 information fixed part */
> >> >> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
> >> >>
> >> >> Let's please not add more assumptions than necessary about stuff
> >> >> being below 4G.
> >> >
> >> > I am not sure what do you mean by that.
> >>
> >> See the 32-bit register used for addressing here (and in many more
> >> places)?
> >
> > This is what I expected but I was confused because you were referring only
> > here to this problem. Anyway, is it possible to do this in different way?
> > Should we care if image is always loaded at 0x100000 right now? Even with
> > Xen early boot code being relocatable loader could not load image higher
> > than 0xffffffff - 14 MiB.
>
> I don't understand what you're alluding to. Just use 64-bit registers
> for memory accesses and LEAs, and be done. This will result in smaller
> code as a benefit.

Well... How can I do that here if processor is in 32-bit mode? Maybe,
we could that things after switching to 64-bit mode. However, I think
this requires separate patch to do these changes.

Daniel

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Fri, Mar 27, 2015 at 02:34:19PM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 15:26, <daniel.kiper@oracle.com> wrote:
> > On Fri, Mar 27, 2015 at 01:36:32PM +0000, Jan Beulich wrote:
> >> >>> On 27.03.15 at 14:06, <daniel.kiper@oracle.com> wrote:
> >> > On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
> >> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >> >> > +        /* Skip Multiboot2 information fixed part */
> >> >> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
> >> >>
> >> >> Let's please not add more assumptions than necessary about stuff
> >> >> being below 4G.
> >> >
> >> > I am not sure what do you mean by that.
> >>
> >> See the 32-bit register used for addressing here (and in many more
> >> places)?
> >
> > This is what I expected but I was confused because you were referring only
> > here to this problem. Anyway, is it possible to do this in different way?
> > Should we care if image is always loaded at 0x100000 right now? Even with
> > Xen early boot code being relocatable loader could not load image higher
> > than 0xffffffff - 14 MiB.
>
> I don't understand what you're alluding to. Just use 64-bit registers
> for memory accesses and LEAs, and be done. This will result in smaller
> code as a benefit.

Well... How can I do that here if processor is in 32-bit mode? Maybe,
we could that things after switching to 64-bit mode. However, I think
this requires separate patch to do these changes.

Daniel

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 27.03.15 at 15:57, <daniel.kiper@oracle.com> wrote:
> On Fri, Mar 27, 2015 at 02:34:19PM +0000, Jan Beulich wrote:
>> >>> On 27.03.15 at 15:26, <daniel.kiper@oracle.com> wrote:
>> > On Fri, Mar 27, 2015 at 01:36:32PM +0000, Jan Beulich wrote:
>> >> >>> On 27.03.15 at 14:06, <daniel.kiper@oracle.com> wrote:
>> >> > On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
>> >> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> >> >> > +        /* Skip Multiboot2 information fixed part */
>> >> >> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
>> >> >>
>> >> >> Let's please not add more assumptions than necessary about stuff
>> >> >> being below 4G.
>> >> >
>> >> > I am not sure what do you mean by that.
>> >>
>> >> See the 32-bit register used for addressing here (and in many more
>> >> places)?
>> >
>> > This is what I expected but I was confused because you were referring only
>> > here to this problem. Anyway, is it possible to do this in different way?
>> > Should we care if image is always loaded at 0x100000 right now? Even with
>> > Xen early boot code being relocatable loader could not load image higher
>> > than 0xffffffff - 14 MiB.
>>
>> I don't understand what you're alluding to. Just use 64-bit registers
>> for memory accesses and LEAs, and be done. This will result in smaller
>> code as a benefit.
> 
> Well... How can I do that here if processor is in 32-bit mode? Maybe,
> we could that things after switching to 64-bit mode. However, I think
> this requires separate patch to do these changes.

No, if the processor is in 32-bit mode, then using 32-bit registers is
fine of course. But I'm pretty certain I spotted at least some cases
where it looked like you used 32-bit registers in 64-bit mode.

Jan

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 27.03.15 at 15:57, <daniel.kiper@oracle.com> wrote:
> On Fri, Mar 27, 2015 at 02:34:19PM +0000, Jan Beulich wrote:
>> >>> On 27.03.15 at 15:26, <daniel.kiper@oracle.com> wrote:
>> > On Fri, Mar 27, 2015 at 01:36:32PM +0000, Jan Beulich wrote:
>> >> >>> On 27.03.15 at 14:06, <daniel.kiper@oracle.com> wrote:
>> >> > On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
>> >> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> >> >> > +        /* Skip Multiboot2 information fixed part */
>> >> >> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
>> >> >>
>> >> >> Let's please not add more assumptions than necessary about stuff
>> >> >> being below 4G.
>> >> >
>> >> > I am not sure what do you mean by that.
>> >>
>> >> See the 32-bit register used for addressing here (and in many more
>> >> places)?
>> >
>> > This is what I expected but I was confused because you were referring only
>> > here to this problem. Anyway, is it possible to do this in different way?
>> > Should we care if image is always loaded at 0x100000 right now? Even with
>> > Xen early boot code being relocatable loader could not load image higher
>> > than 0xffffffff - 14 MiB.
>>
>> I don't understand what you're alluding to. Just use 64-bit registers
>> for memory accesses and LEAs, and be done. This will result in smaller
>> code as a benefit.
> 
> Well... How can I do that here if processor is in 32-bit mode? Maybe,
> we could that things after switching to 64-bit mode. However, I think
> this requires separate patch to do these changes.

No, if the processor is in 32-bit mode, then using 32-bit registers is
fine of course. But I'm pretty certain I spotted at least some cases
where it looked like you used 32-bit registers in 64-bit mode.

Jan

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Fri, Mar 27, 2015 at 03:06:43PM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 15:57, <daniel.kiper@oracle.com> wrote:
> > On Fri, Mar 27, 2015 at 02:34:19PM +0000, Jan Beulich wrote:
> >> >>> On 27.03.15 at 15:26, <daniel.kiper@oracle.com> wrote:
> >> > On Fri, Mar 27, 2015 at 01:36:32PM +0000, Jan Beulich wrote:
> >> >> >>> On 27.03.15 at 14:06, <daniel.kiper@oracle.com> wrote:
> >> >> > On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
> >> >> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >> >> >> > +        /* Skip Multiboot2 information fixed part */
> >> >> >> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
> >> >> >>
> >> >> >> Let's please not add more assumptions than necessary about stuff
> >> >> >> being below 4G.
> >> >> >
> >> >> > I am not sure what do you mean by that.
> >> >>
> >> >> See the 32-bit register used for addressing here (and in many more
> >> >> places)?
> >> >
> >> > This is what I expected but I was confused because you were referring only
> >> > here to this problem. Anyway, is it possible to do this in different way?
> >> > Should we care if image is always loaded at 0x100000 right now? Even with
> >> > Xen early boot code being relocatable loader could not load image higher
> >> > than 0xffffffff - 14 MiB.
> >>
> >> I don't understand what you're alluding to. Just use 64-bit registers
> >> for memory accesses and LEAs, and be done. This will result in smaller
> >> code as a benefit.
> >
> > Well... How can I do that here if processor is in 32-bit mode? Maybe,
> > we could that things after switching to 64-bit mode. However, I think
> > this requires separate patch to do these changes.
>
> No, if the processor is in 32-bit mode, then using 32-bit registers is
> fine of course. But I'm pretty certain I spotted at least some cases
> where it looked like you used 32-bit registers in 64-bit mode.

OK, I will double check. If I find something then I will fix it.

Daniel

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Fri, Mar 27, 2015 at 03:06:43PM +0000, Jan Beulich wrote:
> >>> On 27.03.15 at 15:57, <daniel.kiper@oracle.com> wrote:
> > On Fri, Mar 27, 2015 at 02:34:19PM +0000, Jan Beulich wrote:
> >> >>> On 27.03.15 at 15:26, <daniel.kiper@oracle.com> wrote:
> >> > On Fri, Mar 27, 2015 at 01:36:32PM +0000, Jan Beulich wrote:
> >> >> >>> On 27.03.15 at 14:06, <daniel.kiper@oracle.com> wrote:
> >> >> > On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
> >> >> >> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >> >> >> > +        /* Skip Multiboot2 information fixed part */
> >> >> >> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
> >> >> >>
> >> >> >> Let's please not add more assumptions than necessary about stuff
> >> >> >> being below 4G.
> >> >> >
> >> >> > I am not sure what do you mean by that.
> >> >>
> >> >> See the 32-bit register used for addressing here (and in many more
> >> >> places)?
> >> >
> >> > This is what I expected but I was confused because you were referring only
> >> > here to this problem. Anyway, is it possible to do this in different way?
> >> > Should we care if image is always loaded at 0x100000 right now? Even with
> >> > Xen early boot code being relocatable loader could not load image higher
> >> > than 0xffffffff - 14 MiB.
> >>
> >> I don't understand what you're alluding to. Just use 64-bit registers
> >> for memory accesses and LEAs, and be done. This will result in smaller
> >> code as a benefit.
> >
> > Well... How can I do that here if processor is in 32-bit mode? Maybe,
> > we could that things after switching to 64-bit mode. However, I think
> > this requires separate patch to do these changes.
>
> No, if the processor is in 32-bit mode, then using 32-bit registers is
> fine of course. But I'm pretty certain I spotted at least some cases
> where it looked like you used 32-bit registers in 64-bit mode.

OK, I will double check. If I find something then I will fix it.

Daniel

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 27.03.15 at 14:06, <daniel.kiper@oracle.com> wrote:
> On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
>> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> > +        /* Skip Multiboot2 information fixed part */
>> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
>>
>> Let's please not add more assumptions than necessary about stuff
>> being below 4G.
> 
> I am not sure what do you mean by that.

See the 32-bit register used for addressing here (and in many more
places)?

Jan

Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Tue, Mar 17, 2015 at 10:32:01AM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> > @@ -94,6 +111,17 @@ ENTRY(start)
> >  gdt_boot_descr:
> >          .word   6*8-1
> >          .long   sym_phys(trampoline_gdt)
> > +        .long   0 /* Needed for 64-bit lgdt */
> > +
> > +cs32_switch_addr:
> > +        .long   sym_phys(cs32_switch)
> > +        .long   BOOT_CS32
> > +
> > +efi_st:
> > +        .quad   0
> > +
> > +efi_ih:
> > +        .quad   0
> >
> >  .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
> >  .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
> > @@ -124,6 +152,133 @@ print_err:
> >  .Lhalt: hlt
> >          jmp     .Lhalt
> >
> > +        .code64
> > +
> > +__efi64_start:
> > +        cld
> > +
> > +        /* Bootloaders may set multiboot[12].mem_lower to a nonzero value */
> > +        xor     %edx,%edx
> > +
> > +        /* Check for Multiboot2 bootloader */
> > +        cmp     $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> > +        je      efi_multiboot2_proto
> > +
> > +        jmp     not_multiboot
> > +
> > +efi_multiboot2_proto:
>
> jne not_multiboot (and efi_multiboot2_proto dropped altogether)
>
> > +        /* Skip Multiboot2 information fixed part */
> > +        lea     MB2_fixed_sizeof(%ebx),%ecx
>
> Let's please not add more assumptions than necessary about stuff
> being below 4G.

I am not sure what do you mean by that.

> > +
> > +0:
> > +        /* Get mem_lower from Multiboot2 information */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,(%ecx)
> > +        jne     1f
> > +
> > +        mov     MB2_mem_lower(%ecx),%edx
> > +        jmp     4f
> > +
> > +1:
> > +        /* Get EFI SystemTable address from Multiboot2 information */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64,(%ecx)
> > +        jne     2f
> > +
> > +        lea     MB2_efi64_st(%ecx),%esi
> > +        lea     efi_st(%rip),%edi
> > +        movsq
>
> A simple pair of mov-s please, assuming all of this really needs to be
> done in assembly in the first place. Also please use .L<name> labels
> in this assembly coded switch statement to ease reading.
>
> > +
> > +        /* Do not go into real mode on EFI platform */
> > +        movb    $1,skip_realmode(%rip)
> > +
> > +        jmp     4f
> > +
> > +2:
> > +        /* Get EFI ImageHandle address from Multiboot2 information */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_EFI64_IH,(%ecx)
> > +        jne     3f
> > +
> > +        lea     MB2_efi64_ih(%ecx),%esi
> > +        lea     efi_ih(%rip),%edi
> > +        movsq
> > +        jmp     4f
> > +
> > +3:
> > +        /* Is it the end of Multiboot2 information? */
> > +        cmpl    $MULTIBOOT2_TAG_TYPE_END,(%ecx)
> > +        je      run_bs
> > +
> > +4:
>
> Please switch the order so that 2 can fall through into 4 (and you
> then won't need the run_bs label, which otherwise should also
> becom .Lrun_bs).
>
> > +        /* Go to next Multiboot2 information tag */
> > +        add     MB2_tag_size(%ecx),%ecx
> > +        add     $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +        and     $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +        jmp     0b
> > +
> > +run_bs:
> > +        push    %rax
> > +        push    %rdx
> > +
> > +        /* Initialize BSS (no nasty surprises!) */
> > +        lea     __bss_start(%rip),%rdi
> > +        lea     _end(%rip),%rcx
> > +        sub     %rdi,%rcx
> > +        xor     %rax,%rax
> > +        rep     stosb
>
> rep stosb
>
> > +
> > +        mov     efi_ih(%rip),%rdi   /* EFI ImageHandle */
> > +        mov     efi_st(%rip),%rsi   /* EFI SystemTable */
> > +        call    efi_multiboot2
>
> With efi_multiboot2 being a C function it really looks like much of the
> above doesn't need to be done in assembly.

Potentially make sense. I will try to do that.

Daniel

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Daniel Kiper]

On Fri, Jan 30, 2015 at 06:54:04PM +0100, Daniel Kiper wrote:
> Hi,
>
> I am sending, long awaited, first version of multiboot2 protocol
> support for legacy BIOS and EFI platforms.

By mistake I forgot to thank you Andrew and Konrad for support
during development of this series. Sorry guys.

Daniel

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Daniel Kiper]

On Fri, Jan 30, 2015 at 06:54:04PM +0100, Daniel Kiper wrote:
> Hi,
>
> I am sending, long awaited, first version of multiboot2 protocol
> support for legacy BIOS and EFI platforms.

By mistake I forgot to thank you Andrew and Konrad for support
during development of this series. Sorry guys.

Daniel

Re: [PATCH 00/18] x86: multiboot2 protocol support

[João Jerónimo]

Hello,

Is it planned to have the boot loader set up long mode for the kernel 
(in BIOS systems) in a future multiboot version?
And, before someone talks about that, I know that long mode requires 
paging to be set up and enabled. As far as I know some OS loaders do this.

Also, something I think would be interesting to have, is a "safe" memory 
map, that marks the kernel area as "used" and things like that. :-)

JJ



On 30-01-2015 17:54, Daniel Kiper wrote:
> Hi,
>
> I am sending, long awaited, first version of multiboot2 protocol
> support for legacy BIOS and EFI platforms.
>
> The final goal is xen.efi binary file which could be loaded by EFI
> loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
> multiboot2 protocol. This way we will have:
>    - smaller Xen code base,
>    - one code base for xen.gz and xen.efi,
>    - one build method for xen.gz and xen.efi;
>      xen.efi will be extracted from xen file
>      using objcopy; PE header will be contained
>      in ELF file and will precede Xen code,
>    - xen.efi build will not so strongly depend
>      on a given GCC and binutils version.
>
> GRUB2 patch series will follow this patch series.
>
> GRUB2 guys should check patch #18 but I am sending
> to you all Xen related patches just in case.

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>   - xen.efi build will not so strongly depend
>     on a given GCC and binutils version.

While I can see the possibility of making the binutils version
dependency go away (by manually creating the PE header), I can't
see how you'd overcome the gcc one: The MS calling convention
support is still going to be needed (not having looked at the patches
themselves yet, I can't see myself accepting the introduction of
stubs to convert between calling conventions).

Jan

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Daniel Kiper]

On Mon, Feb 02, 2015 at 09:28:49AM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >   - xen.efi build will not so strongly depend
> >     on a given GCC and binutils version.
>
> While I can see the possibility of making the binutils version
> dependency go away (by manually creating the PE header), I can't
> see how you'd overcome the gcc one: The MS calling convention
> support is still going to be needed (not having looked at the patches

Right, I forgot about that one.

> themselves yet, I can't see myself accepting the introduction of
> stubs to convert between calling conventions).

I am not going to do that thing.

Daniel

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Daniel Kiper]

On Mon, Feb 02, 2015 at 09:28:49AM +0000, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >   - xen.efi build will not so strongly depend
> >     on a given GCC and binutils version.
>
> While I can see the possibility of making the binutils version
> dependency go away (by manually creating the PE header), I can't
> see how you'd overcome the gcc one: The MS calling convention
> support is still going to be needed (not having looked at the patches

Right, I forgot about that one.

> themselves yet, I can't see myself accepting the introduction of
> stubs to convert between calling conventions).

I am not going to do that thing.

Daniel

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Andrew Cooper]

On 03/02/2015 17:14, Daniel Kiper wrote:
> On Mon, Feb 02, 2015 at 09:28:49AM +0000, Jan Beulich wrote:
>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>>   - xen.efi build will not so strongly depend
>>>     on a given GCC and binutils version.
>> While I can see the possibility of making the binutils version
>> dependency go away (by manually creating the PE header), I can't
>> see how you'd overcome the gcc one: The MS calling convention
>> support is still going to be needed (not having looked at the patches
> Right, I forgot about that one.
>
>> themselves yet, I can't see myself accepting the introduction of
>> stubs to convert between calling conventions).

How about __attribute__((ms_abi)) ?  It would appear to exist for this
purpose.

~Andrew

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Jan Beulich]

>>> On 04.02.15 at 10:04, <andrew.cooper3@citrix.com> wrote:
> On 03/02/2015 17:14, Daniel Kiper wrote:
>> On Mon, Feb 02, 2015 at 09:28:49AM +0000, Jan Beulich wrote:
>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>>>   - xen.efi build will not so strongly depend
>>>>     on a given GCC and binutils version.
>>> While I can see the possibility of making the binutils version
>>> dependency go away (by manually creating the PE header), I can't
>>> see how you'd overcome the gcc one: The MS calling convention
>>> support is still going to be needed (not having looked at the patches
>> Right, I forgot about that one.
>>
>>> themselves yet, I can't see myself accepting the introduction of
>>> stubs to convert between calling conventions).
> 
> How about __attribute__((ms_abi)) ?  It would appear to exist for this
> purpose.

But that's the point: Older compilers don't support it. And with
compilers supporting it we need no stubs.

Jan

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Jan Beulich]

>>> On 04.02.15 at 10:04, <andrew.cooper3@citrix.com> wrote:
> On 03/02/2015 17:14, Daniel Kiper wrote:
>> On Mon, Feb 02, 2015 at 09:28:49AM +0000, Jan Beulich wrote:
>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>>>   - xen.efi build will not so strongly depend
>>>>     on a given GCC and binutils version.
>>> While I can see the possibility of making the binutils version
>>> dependency go away (by manually creating the PE header), I can't
>>> see how you'd overcome the gcc one: The MS calling convention
>>> support is still going to be needed (not having looked at the patches
>> Right, I forgot about that one.
>>
>>> themselves yet, I can't see myself accepting the introduction of
>>> stubs to convert between calling conventions).
> 
> How about __attribute__((ms_abi)) ?  It would appear to exist for this
> purpose.

But that's the point: Older compilers don't support it. And with
compilers supporting it we need no stubs.

Jan

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Andrew Cooper]

On 04/02/15 09:51, Jan Beulich wrote:
>>>> On 04.02.15 at 10:04, <andrew.cooper3@citrix.com> wrote:
>> On 03/02/2015 17:14, Daniel Kiper wrote:
>>> On Mon, Feb 02, 2015 at 09:28:49AM +0000, Jan Beulich wrote:
>>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>>>>   - xen.efi build will not so strongly depend
>>>>>     on a given GCC and binutils version.
>>>> While I can see the possibility of making the binutils version
>>>> dependency go away (by manually creating the PE header), I can't
>>>> see how you'd overcome the gcc one: The MS calling convention
>>>> support is still going to be needed (not having looked at the patches
>>> Right, I forgot about that one.
>>>
>>>> themselves yet, I can't see myself accepting the introduction of
>>>> stubs to convert between calling conventions).
>> How about __attribute__((ms_abi)) ?  It would appear to exist for this
>> purpose.
> But that's the point: Older compilers don't support it. And with
> compilers supporting it we need no stubs.

If the use of __attribute__((ms_abi)) was suitably contained within a
#ifdef CONFIG_EFI, I don't see an problem.  CONFIG_EFI could derive
primarily from a compiler version check if we don't wish to force a
minimum newer version of gcc.

One way or another, a newer set of tools is needed to build EFI support,
and a binary capable of both legacy and efi boot is quite desirable to have.

~Andrew

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Andrew Cooper]

On 04/02/15 09:51, Jan Beulich wrote:
>>>> On 04.02.15 at 10:04, <andrew.cooper3@citrix.com> wrote:
>> On 03/02/2015 17:14, Daniel Kiper wrote:
>>> On Mon, Feb 02, 2015 at 09:28:49AM +0000, Jan Beulich wrote:
>>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>>>>   - xen.efi build will not so strongly depend
>>>>>     on a given GCC and binutils version.
>>>> While I can see the possibility of making the binutils version
>>>> dependency go away (by manually creating the PE header), I can't
>>>> see how you'd overcome the gcc one: The MS calling convention
>>>> support is still going to be needed (not having looked at the patches
>>> Right, I forgot about that one.
>>>
>>>> themselves yet, I can't see myself accepting the introduction of
>>>> stubs to convert between calling conventions).
>> How about __attribute__((ms_abi)) ?  It would appear to exist for this
>> purpose.
> But that's the point: Older compilers don't support it. And with
> compilers supporting it we need no stubs.

If the use of __attribute__((ms_abi)) was suitably contained within a
#ifdef CONFIG_EFI, I don't see an problem.  CONFIG_EFI could derive
primarily from a compiler version check if we don't wish to force a
minimum newer version of gcc.

One way or another, a newer set of tools is needed to build EFI support,
and a binary capable of both legacy and efi boot is quite desirable to have.

~Andrew

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

Le 2015-02-04 10:51, "Jan Beulich" <JBeulich@suse.com> a écrit :
>
> >>> On 04.02.15 at 10:04, <andrew.cooper3@citrix.com> wrote:
> > On 03/02/2015 17:14, Daniel Kiper wrote:
> >> On Mon, Feb 02, 2015 at 09:28:49AM +0000, Jan Beulich wrote:
> >>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >>>>   - xen.efi build will not so strongly depend
> >>>>     on a given GCC and binutils version.
> >>> While I can see the possibility of making the binutils version
> >>> dependency go away (by manually creating the PE header), I can't
> >>> see how you'd overcome the gcc one: The MS calling convention
> >>> support is still going to be needed (not having looked at the patches
> >> Right, I forgot about that one.
> >>
> >>> themselves yet, I can't see myself accepting the introduction of
> >>> stubs to convert between calling conventions).
> >
> > How about __attribute__((ms_abi)) ?  It would appear to exist for this
> > purpose.
>
> But that's the point: Older compilers don't support it. And with
> compilers supporting it we need no stubs.
>
ms_abi has been around for years. What's your minimum compiler requirement?
> Jan
>

[-- Attachment #2: Type: text/html, Size: 1699 bytes --]

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Jan Beulich]

>>> On 05.02.15 at 12:50, <phcoder@gmail.com> wrote:
> Le 2015-02-04 10:51, "Jan Beulich" <JBeulich@suse.com> a écrit :
>>
>> >>> On 04.02.15 at 10:04, <andrew.cooper3@citrix.com> wrote:
>> > On 03/02/2015 17:14, Daniel Kiper wrote:
>> >> On Mon, Feb 02, 2015 at 09:28:49AM +0000, Jan Beulich wrote:
>> >>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> >>>>   - xen.efi build will not so strongly depend
>> >>>>     on a given GCC and binutils version.
>> >>> While I can see the possibility of making the binutils version
>> >>> dependency go away (by manually creating the PE header), I can't
>> >>> see how you'd overcome the gcc one: The MS calling convention
>> >>> support is still going to be needed (not having looked at the patches
>> >> Right, I forgot about that one.
>> >>
>> >>> themselves yet, I can't see myself accepting the introduction of
>> >>> stubs to convert between calling conventions).
>> >
>> > How about __attribute__((ms_abi)) ?  It would appear to exist for this
>> > purpose.
>>
>> But that's the point: Older compilers don't support it. And with
>> compilers supporting it we need no stubs.
>>
> ms_abi has been around for years. What's your minimum compiler requirement?

4.1

Jan

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Jan Beulich]

>>> On 05.02.15 at 12:50, <phcoder@gmail.com> wrote:
> Le 2015-02-04 10:51, "Jan Beulich" <JBeulich@suse.com> a écrit :
>>
>> >>> On 04.02.15 at 10:04, <andrew.cooper3@citrix.com> wrote:
>> > On 03/02/2015 17:14, Daniel Kiper wrote:
>> >> On Mon, Feb 02, 2015 at 09:28:49AM +0000, Jan Beulich wrote:
>> >>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>> >>>>   - xen.efi build will not so strongly depend
>> >>>>     on a given GCC and binutils version.
>> >>> While I can see the possibility of making the binutils version
>> >>> dependency go away (by manually creating the PE header), I can't
>> >>> see how you'd overcome the gcc one: The MS calling convention
>> >>> support is still going to be needed (not having looked at the patches
>> >> Right, I forgot about that one.
>> >>
>> >>> themselves yet, I can't see myself accepting the introduction of
>> >>> stubs to convert between calling conventions).
>> >
>> > How about __attribute__((ms_abi)) ?  It would appear to exist for this
>> > purpose.
>>
>> But that's the point: Older compilers don't support it. And with
>> compilers supporting it we need no stubs.
>>
> ms_abi has been around for years. What's your minimum compiler requirement?

4.1

Jan

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

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 1174 bytes --]

Le 2015-02-04 10:51, "Jan Beulich" <JBeulich@suse.com> a écrit :
>
> >>> On 04.02.15 at 10:04, <andrew.cooper3@citrix.com> wrote:
> > On 03/02/2015 17:14, Daniel Kiper wrote:
> >> On Mon, Feb 02, 2015 at 09:28:49AM +0000, Jan Beulich wrote:
> >>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
> >>>>   - xen.efi build will not so strongly depend
> >>>>     on a given GCC and binutils version.
> >>> While I can see the possibility of making the binutils version
> >>> dependency go away (by manually creating the PE header), I can't
> >>> see how you'd overcome the gcc one: The MS calling convention
> >>> support is still going to be needed (not having looked at the patches
> >> Right, I forgot about that one.
> >>
> >>> themselves yet, I can't see myself accepting the introduction of
> >>> stubs to convert between calling conventions).
> >
> > How about __attribute__((ms_abi)) ?  It would appear to exist for this
> > purpose.
>
> But that's the point: Older compilers don't support it. And with
> compilers supporting it we need no stubs.
>
ms_abi has been around for years. What's your minimum compiler requirement?
> Jan
>

[-- Attachment #1.2: Type: text/html, Size: 1699 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Andrew Cooper]

On 03/02/2015 17:14, Daniel Kiper wrote:
> On Mon, Feb 02, 2015 at 09:28:49AM +0000, Jan Beulich wrote:
>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>>   - xen.efi build will not so strongly depend
>>>     on a given GCC and binutils version.
>> While I can see the possibility of making the binutils version
>> dependency go away (by manually creating the PE header), I can't
>> see how you'd overcome the gcc one: The MS calling convention
>> support is still going to be needed (not having looked at the patches
> Right, I forgot about that one.
>
>> themselves yet, I can't see myself accepting the introduction of
>> stubs to convert between calling conventions).

How about __attribute__((ms_abi)) ?  It would appear to exist for this
purpose.

~Andrew

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Jan Beulich]

>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>   - xen.efi build will not so strongly depend
>     on a given GCC and binutils version.

While I can see the possibility of making the binutils version
dependency go away (by manually creating the PE header), I can't
see how you'd overcome the gcc one: The MS calling convention
support is still going to be needed (not having looked at the patches
themselves yet, I can't see myself accepting the introduction of
stubs to convert between calling conventions).

Jan

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Daniel Kiper]

Hi all,

On Fri, Jan 30, 2015 at 06:54:04PM +0100, Daniel Kiper wrote:
> Hi,
>
> I am sending, long awaited, first version of multiboot2 protocol
> support for legacy BIOS and EFI platforms.
>
> The final goal is xen.efi binary file which could be loaded by EFI
> loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
> multiboot2 protocol. This way we will have:
>   - smaller Xen code base,
>   - one code base for xen.gz and xen.efi,
>   - one build method for xen.gz and xen.efi;
>     xen.efi will be extracted from xen file
>     using objcopy; PE header will be contained
>     in ELF file and will precede Xen code,
>   - xen.efi build will not so strongly depend
>     on a given GCC and binutils version.

I have not received so many comments on this patch series.
Is there no interest in having this feature in Xen? Is there
anything wrong? Should I fix something?

Daniel

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Daniel Kiper]

Hi all,

On Fri, Jan 30, 2015 at 06:54:04PM +0100, Daniel Kiper wrote:
> Hi,
>
> I am sending, long awaited, first version of multiboot2 protocol
> support for legacy BIOS and EFI platforms.
>
> The final goal is xen.efi binary file which could be loaded by EFI
> loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
> multiboot2 protocol. This way we will have:
>   - smaller Xen code base,
>   - one code base for xen.gz and xen.efi,
>   - one build method for xen.gz and xen.efi;
>     xen.efi will be extracted from xen file
>     using objcopy; PE header will be contained
>     in ELF file and will precede Xen code,
>   - xen.efi build will not so strongly depend
>     on a given GCC and binutils version.

I have not received so many comments on this patch series.
Is there no interest in having this feature in Xen? Is there
anything wrong? Should I fix something?

Daniel

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Jan Beulich]

>>> On 09.02.15 at 18:59, <daniel.kiper@oracle.com> wrote:
> On Fri, Jan 30, 2015 at 06:54:04PM +0100, Daniel Kiper wrote:
>> I am sending, long awaited, first version of multiboot2 protocol
>> support for legacy BIOS and EFI platforms.
>>
>> The final goal is xen.efi binary file which could be loaded by EFI
>> loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
>> multiboot2 protocol. This way we will have:
>>   - smaller Xen code base,
>>   - one code base for xen.gz and xen.efi,
>>   - one build method for xen.gz and xen.efi;
>>     xen.efi will be extracted from xen file
>>     using objcopy; PE header will be contained
>>     in ELF file and will precede Xen code,
>>   - xen.efi build will not so strongly depend
>>     on a given GCC and binutils version.
> 
> I have not received so many comments on this patch series.
> Is there no interest in having this feature in Xen? Is there
> anything wrong? Should I fix something?

I didn't get to look at patches 4 and onwards yet, there's too much
other stuff I need to take care of right now; I'll get to this eventually.

Jan

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Jan Beulich]

>>> On 09.02.15 at 18:59, <daniel.kiper@oracle.com> wrote:
> On Fri, Jan 30, 2015 at 06:54:04PM +0100, Daniel Kiper wrote:
>> I am sending, long awaited, first version of multiboot2 protocol
>> support for legacy BIOS and EFI platforms.
>>
>> The final goal is xen.efi binary file which could be loaded by EFI
>> loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
>> multiboot2 protocol. This way we will have:
>>   - smaller Xen code base,
>>   - one code base for xen.gz and xen.efi,
>>   - one build method for xen.gz and xen.efi;
>>     xen.efi will be extracted from xen file
>>     using objcopy; PE header will be contained
>>     in ELF file and will precede Xen code,
>>   - xen.efi build will not so strongly depend
>>     on a given GCC and binutils version.
> 
> I have not received so many comments on this patch series.
> Is there no interest in having this feature in Xen? Is there
> anything wrong? Should I fix something?

I didn't get to look at patches 4 and onwards yet, there's too much
other stuff I need to take care of right now; I'll get to this eventually.

Jan

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Ian Campbell]

On Fri, 2015-01-30 at 18:54 +0100, Daniel Kiper wrote:
>  xen/arch/x86/Makefile             |   17 ++--
>  xen/arch/x86/boot/Makefile        |    3 +-
>  xen/arch/x86/boot/head.S          |  291 ++++++++++++++++++++++++++++++++++++++++++++++++++----
>  xen/arch/x86/boot/reloc.c         |  219 ++++++++++++++++++++++++++++++++++-------
>  xen/arch/x86/dmi_scan.c           |    4 +-
>  xen/arch/x86/domain_page.c        |    2 +-
>  xen/arch/x86/e820.c               |   29 ++----
>  xen/arch/x86/efi/Makefile         |   12 +--
>  xen/arch/x86/efi/efi-boot.h       |   66 +++++++++++--
>  xen/arch/x86/efi/stub.c           |   41 --------
>  xen/arch/x86/mpparse.c            |    4 +-
>  xen/arch/x86/setup.c              |   30 +++---
>  xen/arch/x86/shutdown.c           |    3 +-
>  xen/arch/x86/time.c               |    2 +-
>  xen/arch/x86/x86_64/asm-offsets.c |    8 ++
>  xen/arch/x86/xen.lds.S            |    2 -
>  xen/common/efi/boot.c             |  441 +++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------
>  xen/common/efi/runtime.c          |   11 ++-
>  xen/drivers/acpi/osl.c            |    2 +-
>  xen/include/xen/efi.h             |    6 +-
>  xen/include/xen/multiboot2.h      |  169 ++++++++++++++++++++++++++++++++
>  21 files changed, 1018 insertions(+), 344 deletions(-)

>From the diffstat I'm not sure: is there any ARM impact I should worry
about reviewing? Any patches in particular my feedback is needed on?

> 
> Daniel Kiper (18):
>       x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags
>       x86/boot/reloc: create generic alloc and copy functions
>       x86/boot: use %ecx instead of %eax
>       xen/x86: add multiboot2 protocol support
>       efi: split efi_enabled to efi_platform and efi_loader
>       x86: remove commented out stale references to efi_enabled
>       efi: run EFI specific code on EFI platform only
>       efi: build xen.gz with EFI code
>       efi: create efi_init()
>       efi: create efi_console_set_mode()
>       efi: create efi_get_gop()
>       efi: create efi_find_gop_mode()
>       efi: create efi_tables()
>       efi: create efi_variables()
>       efi: create efi_set_gop_mode()
>       efi: create efi_exit_boot()
>       x86/efi: create new early memory allocator
>       x86: add multiboot2 protocol support for EFI platforms
> 

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Ian Campbell]

On Fri, 2015-01-30 at 18:54 +0100, Daniel Kiper wrote:
>  xen/arch/x86/Makefile             |   17 ++--
>  xen/arch/x86/boot/Makefile        |    3 +-
>  xen/arch/x86/boot/head.S          |  291 ++++++++++++++++++++++++++++++++++++++++++++++++++----
>  xen/arch/x86/boot/reloc.c         |  219 ++++++++++++++++++++++++++++++++++-------
>  xen/arch/x86/dmi_scan.c           |    4 +-
>  xen/arch/x86/domain_page.c        |    2 +-
>  xen/arch/x86/e820.c               |   29 ++----
>  xen/arch/x86/efi/Makefile         |   12 +--
>  xen/arch/x86/efi/efi-boot.h       |   66 +++++++++++--
>  xen/arch/x86/efi/stub.c           |   41 --------
>  xen/arch/x86/mpparse.c            |    4 +-
>  xen/arch/x86/setup.c              |   30 +++---
>  xen/arch/x86/shutdown.c           |    3 +-
>  xen/arch/x86/time.c               |    2 +-
>  xen/arch/x86/x86_64/asm-offsets.c |    8 ++
>  xen/arch/x86/xen.lds.S            |    2 -
>  xen/common/efi/boot.c             |  441 +++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------
>  xen/common/efi/runtime.c          |   11 ++-
>  xen/drivers/acpi/osl.c            |    2 +-
>  xen/include/xen/efi.h             |    6 +-
>  xen/include/xen/multiboot2.h      |  169 ++++++++++++++++++++++++++++++++
>  21 files changed, 1018 insertions(+), 344 deletions(-)

From the diffstat I'm not sure: is there any ARM impact I should worry
about reviewing? Any patches in particular my feedback is needed on?

> 
> Daniel Kiper (18):
>       x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags
>       x86/boot/reloc: create generic alloc and copy functions
>       x86/boot: use %ecx instead of %eax
>       xen/x86: add multiboot2 protocol support
>       efi: split efi_enabled to efi_platform and efi_loader
>       x86: remove commented out stale references to efi_enabled
>       efi: run EFI specific code on EFI platform only
>       efi: build xen.gz with EFI code
>       efi: create efi_init()
>       efi: create efi_console_set_mode()
>       efi: create efi_get_gop()
>       efi: create efi_find_gop_mode()
>       efi: create efi_tables()
>       efi: create efi_variables()
>       efi: create efi_set_gop_mode()
>       efi: create efi_exit_boot()
>       x86/efi: create new early memory allocator
>       x86: add multiboot2 protocol support for EFI platforms
> 

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Daniel Kiper]

On Tue, Mar 03, 2015 at 12:10:35PM +0000, Ian Campbell wrote:
> On Fri, 2015-01-30 at 18:54 +0100, Daniel Kiper wrote:
> >  xen/arch/x86/Makefile             |   17 ++--
> >  xen/arch/x86/boot/Makefile        |    3 +-
> >  xen/arch/x86/boot/head.S          |  291 ++++++++++++++++++++++++++++++++++++++++++++++++++----
> >  xen/arch/x86/boot/reloc.c         |  219 ++++++++++++++++++++++++++++++++++-------
> >  xen/arch/x86/dmi_scan.c           |    4 +-
> >  xen/arch/x86/domain_page.c        |    2 +-
> >  xen/arch/x86/e820.c               |   29 ++----
> >  xen/arch/x86/efi/Makefile         |   12 +--
> >  xen/arch/x86/efi/efi-boot.h       |   66 +++++++++++--
> >  xen/arch/x86/efi/stub.c           |   41 --------
> >  xen/arch/x86/mpparse.c            |    4 +-
> >  xen/arch/x86/setup.c              |   30 +++---
> >  xen/arch/x86/shutdown.c           |    3 +-
> >  xen/arch/x86/time.c               |    2 +-
> >  xen/arch/x86/x86_64/asm-offsets.c |    8 ++
> >  xen/arch/x86/xen.lds.S            |    2 -
> >  xen/common/efi/boot.c             |  441 +++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------
> >  xen/common/efi/runtime.c          |   11 ++-
> >  xen/drivers/acpi/osl.c            |    2 +-
> >  xen/include/xen/efi.h             |    6 +-
> >  xen/include/xen/multiboot2.h      |  169 ++++++++++++++++++++++++++++++++
> >  21 files changed, 1018 insertions(+), 344 deletions(-)
>
> From the diffstat I'm not sure: is there any ARM impact I should worry
> about reviewing? Any patches in particular my feedback is needed on?

There are not any functional changes in ARM here. There are some small
changes which are needed to make new x86 stuff coexist with ARM.
Additionally, I thought that you are still interested in x86 things.
Am I right? If you do not have a time right now ignore this patch series.
New thing will appear in 3-4 weeks. Or if you completely not interested in
that stuff just drop me a line and I will drop you from distribution list.

Daniel

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Ian Campbell]

On Tue, 2015-03-03 at 13:36 +0100, Daniel Kiper wrote:
> On Tue, Mar 03, 2015 at 12:10:35PM +0000, Ian Campbell wrote:
> > On Fri, 2015-01-30 at 18:54 +0100, Daniel Kiper wrote:
> > >  xen/arch/x86/Makefile             |   17 ++--
> > >  xen/arch/x86/boot/Makefile        |    3 +-
> > >  xen/arch/x86/boot/head.S          |  291 ++++++++++++++++++++++++++++++++++++++++++++++++++----
> > >  xen/arch/x86/boot/reloc.c         |  219 ++++++++++++++++++++++++++++++++++-------
> > >  xen/arch/x86/dmi_scan.c           |    4 +-
> > >  xen/arch/x86/domain_page.c        |    2 +-
> > >  xen/arch/x86/e820.c               |   29 ++----
> > >  xen/arch/x86/efi/Makefile         |   12 +--
> > >  xen/arch/x86/efi/efi-boot.h       |   66 +++++++++++--
> > >  xen/arch/x86/efi/stub.c           |   41 --------
> > >  xen/arch/x86/mpparse.c            |    4 +-
> > >  xen/arch/x86/setup.c              |   30 +++---
> > >  xen/arch/x86/shutdown.c           |    3 +-
> > >  xen/arch/x86/time.c               |    2 +-
> > >  xen/arch/x86/x86_64/asm-offsets.c |    8 ++
> > >  xen/arch/x86/xen.lds.S            |    2 -
> > >  xen/common/efi/boot.c             |  441 +++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------
> > >  xen/common/efi/runtime.c          |   11 ++-
> > >  xen/drivers/acpi/osl.c            |    2 +-
> > >  xen/include/xen/efi.h             |    6 +-
> > >  xen/include/xen/multiboot2.h      |  169 ++++++++++++++++++++++++++++++++
> > >  21 files changed, 1018 insertions(+), 344 deletions(-)
> >
> > From the diffstat I'm not sure: is there any ARM impact I should worry
> > about reviewing? Any patches in particular my feedback is needed on?
> 
> There are not any functional changes in ARM here. There are some small
> changes which are needed to make new x86 stuff coexist with ARM.
> Additionally, I thought that you are still interested in x86 things.

Not totally disinterested in x86 things, but not especially interested
in x86/EFI/multiboot unless I have to be.

> Am I right? If you do not have a time right now ignore this patch series.
> New thing will appear in 3-4 weeks.

OK, thanks.

> Or if you completely not interested in
> that stuff just drop me a line and I will drop you from distribution list.

If you could just CC me on the bits which impact ARM (or generic code)
that would be ok, but otherwise I can cope with ignoring irrelevant
parts of a series.

Thanks,
Ian.

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Daniel Kiper]

On Tue, Mar 03, 2015 at 12:39:45PM +0000, Ian Campbell wrote:
> On Tue, 2015-03-03 at 13:36 +0100, Daniel Kiper wrote:
> > On Tue, Mar 03, 2015 at 12:10:35PM +0000, Ian Campbell wrote:
> > > On Fri, 2015-01-30 at 18:54 +0100, Daniel Kiper wrote:
> > > >  xen/arch/x86/Makefile             |   17 ++--
> > > >  xen/arch/x86/boot/Makefile        |    3 +-
> > > >  xen/arch/x86/boot/head.S          |  291 ++++++++++++++++++++++++++++++++++++++++++++++++++----
> > > >  xen/arch/x86/boot/reloc.c         |  219 ++++++++++++++++++++++++++++++++++-------
> > > >  xen/arch/x86/dmi_scan.c           |    4 +-
> > > >  xen/arch/x86/domain_page.c        |    2 +-
> > > >  xen/arch/x86/e820.c               |   29 ++----
> > > >  xen/arch/x86/efi/Makefile         |   12 +--
> > > >  xen/arch/x86/efi/efi-boot.h       |   66 +++++++++++--
> > > >  xen/arch/x86/efi/stub.c           |   41 --------
> > > >  xen/arch/x86/mpparse.c            |    4 +-
> > > >  xen/arch/x86/setup.c              |   30 +++---
> > > >  xen/arch/x86/shutdown.c           |    3 +-
> > > >  xen/arch/x86/time.c               |    2 +-
> > > >  xen/arch/x86/x86_64/asm-offsets.c |    8 ++
> > > >  xen/arch/x86/xen.lds.S            |    2 -
> > > >  xen/common/efi/boot.c             |  441 +++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------
> > > >  xen/common/efi/runtime.c          |   11 ++-
> > > >  xen/drivers/acpi/osl.c            |    2 +-
> > > >  xen/include/xen/efi.h             |    6 +-
> > > >  xen/include/xen/multiboot2.h      |  169 ++++++++++++++++++++++++++++++++
> > > >  21 files changed, 1018 insertions(+), 344 deletions(-)
> > >
> > > From the diffstat I'm not sure: is there any ARM impact I should worry
> > > about reviewing? Any patches in particular my feedback is needed on?
> >
> > There are not any functional changes in ARM here. There are some small
> > changes which are needed to make new x86 stuff coexist with ARM.
> > Additionally, I thought that you are still interested in x86 things.
>
> Not totally disinterested in x86 things, but not especially interested
> in x86/EFI/multiboot unless I have to be.

Roger.

> > Am I right? If you do not have a time right now ignore this patch series.
> > New thing will appear in 3-4 weeks.
>
> OK, thanks.
>
> > Or if you completely not interested in
> > that stuff just drop me a line and I will drop you from distribution list.
>
> If you could just CC me on the bits which impact ARM (or generic code)
> that would be ok, but otherwise I can cope with ignoring irrelevant
> parts of a series.

Wilco.

Daniel

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Daniel Kiper]

On Tue, Mar 03, 2015 at 12:39:45PM +0000, Ian Campbell wrote:
> On Tue, 2015-03-03 at 13:36 +0100, Daniel Kiper wrote:
> > On Tue, Mar 03, 2015 at 12:10:35PM +0000, Ian Campbell wrote:
> > > On Fri, 2015-01-30 at 18:54 +0100, Daniel Kiper wrote:
> > > >  xen/arch/x86/Makefile             |   17 ++--
> > > >  xen/arch/x86/boot/Makefile        |    3 +-
> > > >  xen/arch/x86/boot/head.S          |  291 ++++++++++++++++++++++++++++++++++++++++++++++++++----
> > > >  xen/arch/x86/boot/reloc.c         |  219 ++++++++++++++++++++++++++++++++++-------
> > > >  xen/arch/x86/dmi_scan.c           |    4 +-
> > > >  xen/arch/x86/domain_page.c        |    2 +-
> > > >  xen/arch/x86/e820.c               |   29 ++----
> > > >  xen/arch/x86/efi/Makefile         |   12 +--
> > > >  xen/arch/x86/efi/efi-boot.h       |   66 +++++++++++--
> > > >  xen/arch/x86/efi/stub.c           |   41 --------
> > > >  xen/arch/x86/mpparse.c            |    4 +-
> > > >  xen/arch/x86/setup.c              |   30 +++---
> > > >  xen/arch/x86/shutdown.c           |    3 +-
> > > >  xen/arch/x86/time.c               |    2 +-
> > > >  xen/arch/x86/x86_64/asm-offsets.c |    8 ++
> > > >  xen/arch/x86/xen.lds.S            |    2 -
> > > >  xen/common/efi/boot.c             |  441 +++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------
> > > >  xen/common/efi/runtime.c          |   11 ++-
> > > >  xen/drivers/acpi/osl.c            |    2 +-
> > > >  xen/include/xen/efi.h             |    6 +-
> > > >  xen/include/xen/multiboot2.h      |  169 ++++++++++++++++++++++++++++++++
> > > >  21 files changed, 1018 insertions(+), 344 deletions(-)
> > >
> > > From the diffstat I'm not sure: is there any ARM impact I should worry
> > > about reviewing? Any patches in particular my feedback is needed on?
> >
> > There are not any functional changes in ARM here. There are some small
> > changes which are needed to make new x86 stuff coexist with ARM.
> > Additionally, I thought that you are still interested in x86 things.
>
> Not totally disinterested in x86 things, but not especially interested
> in x86/EFI/multiboot unless I have to be.

Roger.

> > Am I right? If you do not have a time right now ignore this patch series.
> > New thing will appear in 3-4 weeks.
>
> OK, thanks.
>
> > Or if you completely not interested in
> > that stuff just drop me a line and I will drop you from distribution list.
>
> If you could just CC me on the bits which impact ARM (or generic code)
> that would be ok, but otherwise I can cope with ignoring irrelevant
> parts of a series.

Wilco.

Daniel

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Ian Campbell]

On Tue, 2015-03-03 at 13:36 +0100, Daniel Kiper wrote:
> On Tue, Mar 03, 2015 at 12:10:35PM +0000, Ian Campbell wrote:
> > On Fri, 2015-01-30 at 18:54 +0100, Daniel Kiper wrote:
> > >  xen/arch/x86/Makefile             |   17 ++--
> > >  xen/arch/x86/boot/Makefile        |    3 +-
> > >  xen/arch/x86/boot/head.S          |  291 ++++++++++++++++++++++++++++++++++++++++++++++++++----
> > >  xen/arch/x86/boot/reloc.c         |  219 ++++++++++++++++++++++++++++++++++-------
> > >  xen/arch/x86/dmi_scan.c           |    4 +-
> > >  xen/arch/x86/domain_page.c        |    2 +-
> > >  xen/arch/x86/e820.c               |   29 ++----
> > >  xen/arch/x86/efi/Makefile         |   12 +--
> > >  xen/arch/x86/efi/efi-boot.h       |   66 +++++++++++--
> > >  xen/arch/x86/efi/stub.c           |   41 --------
> > >  xen/arch/x86/mpparse.c            |    4 +-
> > >  xen/arch/x86/setup.c              |   30 +++---
> > >  xen/arch/x86/shutdown.c           |    3 +-
> > >  xen/arch/x86/time.c               |    2 +-
> > >  xen/arch/x86/x86_64/asm-offsets.c |    8 ++
> > >  xen/arch/x86/xen.lds.S            |    2 -
> > >  xen/common/efi/boot.c             |  441 +++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------
> > >  xen/common/efi/runtime.c          |   11 ++-
> > >  xen/drivers/acpi/osl.c            |    2 +-
> > >  xen/include/xen/efi.h             |    6 +-
> > >  xen/include/xen/multiboot2.h      |  169 ++++++++++++++++++++++++++++++++
> > >  21 files changed, 1018 insertions(+), 344 deletions(-)
> >
> > From the diffstat I'm not sure: is there any ARM impact I should worry
> > about reviewing? Any patches in particular my feedback is needed on?
> 
> There are not any functional changes in ARM here. There are some small
> changes which are needed to make new x86 stuff coexist with ARM.
> Additionally, I thought that you are still interested in x86 things.

Not totally disinterested in x86 things, but not especially interested
in x86/EFI/multiboot unless I have to be.

> Am I right? If you do not have a time right now ignore this patch series.
> New thing will appear in 3-4 weeks.

OK, thanks.

> Or if you completely not interested in
> that stuff just drop me a line and I will drop you from distribution list.

If you could just CC me on the bits which impact ARM (or generic code)
that would be ok, but otherwise I can cope with ignoring irrelevant
parts of a series.

Thanks,
Ian.

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Daniel Kiper]

On Tue, Mar 03, 2015 at 12:10:35PM +0000, Ian Campbell wrote:
> On Fri, 2015-01-30 at 18:54 +0100, Daniel Kiper wrote:
> >  xen/arch/x86/Makefile             |   17 ++--
> >  xen/arch/x86/boot/Makefile        |    3 +-
> >  xen/arch/x86/boot/head.S          |  291 ++++++++++++++++++++++++++++++++++++++++++++++++++----
> >  xen/arch/x86/boot/reloc.c         |  219 ++++++++++++++++++++++++++++++++++-------
> >  xen/arch/x86/dmi_scan.c           |    4 +-
> >  xen/arch/x86/domain_page.c        |    2 +-
> >  xen/arch/x86/e820.c               |   29 ++----
> >  xen/arch/x86/efi/Makefile         |   12 +--
> >  xen/arch/x86/efi/efi-boot.h       |   66 +++++++++++--
> >  xen/arch/x86/efi/stub.c           |   41 --------
> >  xen/arch/x86/mpparse.c            |    4 +-
> >  xen/arch/x86/setup.c              |   30 +++---
> >  xen/arch/x86/shutdown.c           |    3 +-
> >  xen/arch/x86/time.c               |    2 +-
> >  xen/arch/x86/x86_64/asm-offsets.c |    8 ++
> >  xen/arch/x86/xen.lds.S            |    2 -
> >  xen/common/efi/boot.c             |  441 +++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------
> >  xen/common/efi/runtime.c          |   11 ++-
> >  xen/drivers/acpi/osl.c            |    2 +-
> >  xen/include/xen/efi.h             |    6 +-
> >  xen/include/xen/multiboot2.h      |  169 ++++++++++++++++++++++++++++++++
> >  21 files changed, 1018 insertions(+), 344 deletions(-)
>
> From the diffstat I'm not sure: is there any ARM impact I should worry
> about reviewing? Any patches in particular my feedback is needed on?

There are not any functional changes in ARM here. There are some small
changes which are needed to make new x86 stuff coexist with ARM.
Additionally, I thought that you are still interested in x86 things.
Am I right? If you do not have a time right now ignore this patch series.
New thing will appear in 3-4 weeks. Or if you completely not interested in
that stuff just drop me a line and I will drop you from distribution list.

Daniel

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Daniel Kiper]

On Fri, Jan 30, 2015 at 06:54:04PM +0100, Daniel Kiper wrote:
> Hi,
>
> I am sending, long awaited, first version of multiboot2 protocol
> support for legacy BIOS and EFI platforms.

New version with relocatable Xen early boot code is under tests now.
I hope that I will release new version in 2-3 weeks after polishing
some details and taking into account your comments.

Daniel

Re: [PATCH 00/18] x86: multiboot2 protocol support

[Daniel Kiper]

On Fri, Jan 30, 2015 at 06:54:04PM +0100, Daniel Kiper wrote:
> Hi,
>
> I am sending, long awaited, first version of multiboot2 protocol
> support for legacy BIOS and EFI platforms.

New version with relocatable Xen early boot code is under tests now.
I hope that I will release new version in 2-3 weeks after polishing
some details and taking into account your comments.

Daniel