* [PATCH 00/18] x86: multiboot2 protocol support
@ 2015-01-30 17:54 Daniel Kiper
2015-01-30 17:54 ` [PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags Daniel Kiper
` (34 more replies)
0 siblings, 35 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
2015-01-30 17:54 ` [PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions Daniel Kiper
` (32 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
..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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:59 ` [Xen-devel] " Andrew Cooper
2015-01-30 17:59 ` Andrew Cooper
2015-01-30 17:54 ` Daniel Kiper
` (33 subsequent siblings)
34 siblings, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
..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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (2 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 03/18] x86/boot: use %ecx instead of %eax Daniel Kiper
` (30 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
2015-01-30 17:54 ` [PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags Daniel Kiper
2015-01-30 17:54 ` Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 18:02 ` Andrew Cooper
` (3 more replies)
2015-01-30 17:54 ` Daniel Kiper
` (31 subsequent siblings)
34 siblings, 4 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 03/18] x86/boot: use %ecx instead of %eax
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (4 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 03/18] x86/boot: use %ecx instead of %eax Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 04/18] xen/x86: add multiboot2 protocol support Daniel Kiper
` (28 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 03/18] x86/boot: use %ecx instead of %eax
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (3 preceding siblings ...)
2015-01-30 17:54 ` Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-02-03 10:02 ` Jan Beulich
2015-02-03 10:02 ` Jan Beulich
2015-01-30 17:54 ` Daniel Kiper
` (29 subsequent siblings)
34 siblings, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 04/18] xen/x86: add multiboot2 protocol support
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (5 preceding siblings ...)
2015-01-30 17:54 ` Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` Daniel Kiper
` (27 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 04/18] xen/x86: add multiboot2 protocol support
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (6 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 04/18] xen/x86: add multiboot2 protocol support Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 18:11 ` Andrew Cooper
` (2 more replies)
2015-01-30 17:54 ` [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader Daniel Kiper
` (26 subsequent siblings)
34 siblings, 3 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (8 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 06/18] x86: remove commented out stale references to efi_enabled Daniel Kiper
` (24 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (7 preceding siblings ...)
2015-01-30 17:54 ` Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-02-20 16:17 ` Jan Beulich
` (3 more replies)
2015-01-30 17:54 ` Daniel Kiper
` (25 subsequent siblings)
34 siblings, 4 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 06/18] x86: remove commented out stale references to efi_enabled
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (9 preceding siblings ...)
2015-01-30 17:54 ` Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 07/18] efi: run EFI specific code on EFI platform only Daniel Kiper
` (23 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 07/18] efi: run EFI specific code on EFI platform only
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (10 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 06/18] x86: remove commented out stale references to efi_enabled Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-02-20 16:47 ` Jan Beulich
2015-02-20 16:47 ` Jan Beulich
2015-01-30 17:54 ` [PATCH 08/18] efi: build xen.gz with EFI code Daniel Kiper
` (22 subsequent siblings)
34 siblings, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 08/18] efi: build xen.gz with EFI code
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (11 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 07/18] efi: run EFI specific code on EFI platform only Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-03-02 16:14 ` Jan Beulich
2015-03-02 16:14 ` Jan Beulich
2015-01-30 17:54 ` [PATCH 09/18] efi: create efi_init() Daniel Kiper
` (21 subsequent siblings)
34 siblings, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 09/18] efi: create efi_init()
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (12 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 08/18] efi: build xen.gz with EFI code Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 10/18] efi: create efi_console_set_mode() Daniel Kiper
` (20 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
..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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 10/18] efi: create efi_console_set_mode()
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (13 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 09/18] efi: create efi_init() Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 11/18] efi: create efi_get_gop() Daniel Kiper
` (19 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
..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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 11/18] efi: create efi_get_gop()
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (14 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 10/18] efi: create efi_console_set_mode() Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 12/18] efi: create efi_find_gop_mode() Daniel Kiper
` (18 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
..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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 12/18] efi: create efi_find_gop_mode()
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (16 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 12/18] efi: create efi_find_gop_mode() Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 13/18] efi: create efi_tables() Daniel Kiper
` (16 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
..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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 12/18] efi: create efi_find_gop_mode()
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (15 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 11/18] efi: create efi_get_gop() Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` Daniel Kiper
` (17 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
..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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 13/18] efi: create efi_tables()
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (17 preceding siblings ...)
2015-01-30 17:54 ` Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 14/18] efi: create efi_variables() Daniel Kiper
` (15 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
..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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 14/18] efi: create efi_variables()
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (18 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 13/18] efi: create efi_tables() Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 15/18] efi: create efi_set_gop_mode() Daniel Kiper
` (14 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
..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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 15/18] efi: create efi_set_gop_mode()
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (19 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 14/18] efi: create efi_variables() Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 16/18] efi: create efi_exit_boot() Daniel Kiper
` (13 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
..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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 16/18] efi: create efi_exit_boot()
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (20 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 15/18] efi: create efi_set_gop_mode() Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-03-02 16:45 ` Jan Beulich
2015-03-02 16:45 ` Jan Beulich
2015-01-30 17:54 ` [PATCH 17/18] x86/efi: create new early memory allocator Daniel Kiper
` (12 subsequent siblings)
34 siblings, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
..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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 17/18] x86/efi: create new early memory allocator
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (21 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 16/18] efi: create efi_exit_boot() Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-03-02 17:23 ` Jan Beulich
2015-03-02 17:23 ` Jan Beulich
2015-01-30 17:54 ` [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
` (11 subsequent siblings)
34 siblings, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (22 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 17/18] x86/efi: create new early memory allocator Daniel Kiper
@ 2015-01-30 17:54 ` Daniel Kiper
2015-01-30 19:06 ` Andrew Cooper
` (5 more replies)
2015-01-30 18:04 ` [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (10 subsequent siblings)
34 siblings, 6 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 17:54 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply related [flat|nested] 166+ messages in thread
* Re: [PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags
2015-01-30 17:54 ` [PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags Daniel Kiper
2015-01-30 17:59 ` [Xen-devel] " Andrew Cooper
@ 2015-01-30 17:59 ` Andrew Cooper
1 sibling, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-01-30 17:59 UTC (permalink / raw)
To: Daniel Kiper, xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, stefano.stabellini, phcoder,
roy.franz, ning.sun, david.vrabel, jbeulich, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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 |
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [Xen-devel] [PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags
2015-01-30 17:54 ` [PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags Daniel Kiper
@ 2015-01-30 17:59 ` Andrew Cooper
2015-01-30 17:59 ` Andrew Cooper
1 sibling, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-01-30 17:59 UTC (permalink / raw)
To: Daniel Kiper, xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, stefano.stabellini, phcoder,
roy.franz, ning.sun, david.vrabel, jbeulich, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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 |
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions
2015-01-30 17:54 ` [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions Daniel Kiper
2015-01-30 18:02 ` Andrew Cooper
@ 2015-01-30 18:02 ` Andrew Cooper
2015-02-03 10:13 ` Jan Beulich
2015-02-03 10:13 ` Jan Beulich
3 siblings, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-01-30 18:02 UTC (permalink / raw)
To: Daniel Kiper, xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, phcoder, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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 |
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions
2015-01-30 17:54 ` [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions Daniel Kiper
@ 2015-01-30 18:02 ` Andrew Cooper
2015-01-30 18:02 ` Andrew Cooper
` (2 subsequent siblings)
3 siblings, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-01-30 18:02 UTC (permalink / raw)
To: Daniel Kiper, xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, phcoder, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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 |
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (23 preceding siblings ...)
2015-01-30 17:54 ` [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
@ 2015-01-30 18:04 ` Daniel Kiper
2015-01-30 18:04 ` Daniel Kiper
` (9 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 18:04 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (24 preceding siblings ...)
2015-01-30 18:04 ` [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
@ 2015-01-30 18:04 ` Daniel Kiper
2015-01-31 7:22 ` João Jerónimo
` (8 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 18:04 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support
2015-01-30 17:54 ` Daniel Kiper
2015-01-30 18:11 ` Andrew Cooper
@ 2015-01-30 18:11 ` Andrew Cooper
2015-02-20 16:06 ` Jan Beulich
2 siblings, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-01-30 18:11 UTC (permalink / raw)
To: Daniel Kiper, xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, phcoder, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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__ */
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support
2015-01-30 17:54 ` Daniel Kiper
@ 2015-01-30 18:11 ` Andrew Cooper
2015-01-30 18:11 ` Andrew Cooper
2015-02-20 16:06 ` Jan Beulich
2 siblings, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-01-30 18:11 UTC (permalink / raw)
To: Daniel Kiper, xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, phcoder, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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__ */
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-01-30 17:54 ` [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
@ 2015-01-30 19:06 ` Andrew Cooper
2015-01-30 19:06 ` Andrew Cooper
` (4 subsequent siblings)
5 siblings, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-01-30 19:06 UTC (permalink / raw)
To: Daniel Kiper, xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, phcoder, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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;
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-01-30 17:54 ` [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
2015-01-30 19:06 ` Andrew Cooper
@ 2015-01-30 19:06 ` Andrew Cooper
2015-01-30 23:43 ` Daniel Kiper
2015-01-30 23:43 ` Daniel Kiper
2015-02-10 21:27 ` Daniel Kiper
` (3 subsequent siblings)
5 siblings, 2 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-01-30 19:06 UTC (permalink / raw)
To: Daniel Kiper, xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, phcoder, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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;
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-01-30 19:06 ` Andrew Cooper
2015-01-30 23:43 ` Daniel Kiper
@ 2015-01-30 23:43 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 23:43 UTC (permalink / raw)
To: Andrew Cooper
Cc: jgross, grub-devel, keir, ian.campbell, phcoder,
stefano.stabellini, roy.franz, ning.sun, david.vrabel, jbeulich,
xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-01-30 19:06 ` Andrew Cooper
@ 2015-01-30 23:43 ` Daniel Kiper
2015-01-31 0:47 ` Andrew Cooper
2015-01-31 0:47 ` Andrew Cooper
2015-01-30 23:43 ` Daniel Kiper
1 sibling, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-01-30 23:43 UTC (permalink / raw)
To: Andrew Cooper
Cc: jgross, grub-devel, keir, ian.campbell, phcoder,
stefano.stabellini, roy.franz, ning.sun, david.vrabel, jbeulich,
xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-01-30 23:43 ` Daniel Kiper
2015-01-31 0:47 ` Andrew Cooper
@ 2015-01-31 0:47 ` Andrew Cooper
1 sibling, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-01-31 0:47 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, grub-devel, keir, ian.campbell, phcoder,
stefano.stabellini, roy.franz, ning.sun, david.vrabel, jbeulich,
xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-01-30 23:43 ` Daniel Kiper
@ 2015-01-31 0:47 ` Andrew Cooper
2015-01-31 0:47 ` Andrew Cooper
1 sibling, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-01-31 0:47 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, grub-devel, keir, ian.campbell, phcoder,
stefano.stabellini, roy.franz, ning.sun, david.vrabel, jbeulich,
xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (25 preceding siblings ...)
2015-01-30 18:04 ` Daniel Kiper
@ 2015-01-31 7:22 ` João Jerónimo
2015-02-02 9:28 ` Jan Beulich
` (7 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: João Jerónimo @ 2015-01-31 7:22 UTC (permalink / raw)
To: grub-devel
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.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (27 preceding siblings ...)
2015-02-02 9:28 ` Jan Beulich
@ 2015-02-02 9:28 ` Jan Beulich
2015-02-09 17:59 ` Daniel Kiper
` (5 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-02 9:28 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (26 preceding siblings ...)
2015-01-31 7:22 ` João Jerónimo
@ 2015-02-02 9:28 ` Jan Beulich
2015-02-03 17:14 ` Daniel Kiper
2015-02-03 17:14 ` Daniel Kiper
2015-02-02 9:28 ` Jan Beulich
` (6 subsequent siblings)
34 siblings, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-02 9:28 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 03/18] x86/boot: use %ecx instead of %eax
2015-01-30 17:54 ` [PATCH 03/18] x86/boot: use %ecx instead of %eax Daniel Kiper
2015-02-03 10:02 ` Jan Beulich
@ 2015-02-03 10:02 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-03 10:02 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 03/18] x86/boot: use %ecx instead of %eax
2015-01-30 17:54 ` [PATCH 03/18] x86/boot: use %ecx instead of %eax Daniel Kiper
@ 2015-02-03 10:02 ` Jan Beulich
2015-02-03 17:43 ` Daniel Kiper
2015-02-03 17:43 ` Daniel Kiper
2015-02-03 10:02 ` Jan Beulich
1 sibling, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-03 10:02 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions
2015-01-30 17:54 ` [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions Daniel Kiper
` (2 preceding siblings ...)
2015-02-03 10:13 ` Jan Beulich
@ 2015-02-03 10:13 ` Jan Beulich
3 siblings, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-03 10:13 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions
2015-01-30 17:54 ` [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions Daniel Kiper
2015-01-30 18:02 ` Andrew Cooper
2015-01-30 18:02 ` Andrew Cooper
@ 2015-02-03 10:13 ` Jan Beulich
2015-02-03 10:13 ` Jan Beulich
3 siblings, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-03 10:13 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-02-02 9:28 ` Jan Beulich
@ 2015-02-03 17:14 ` Daniel Kiper
2015-02-03 17:14 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-02-03 17:14 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-02-02 9:28 ` Jan Beulich
2015-02-03 17:14 ` Daniel Kiper
@ 2015-02-03 17:14 ` Daniel Kiper
2015-02-04 9:04 ` Andrew Cooper
2015-02-04 9:04 ` Andrew Cooper
1 sibling, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-02-03 17:14 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 03/18] x86/boot: use %ecx instead of %eax
2015-02-03 10:02 ` Jan Beulich
2015-02-03 17:43 ` Daniel Kiper
@ 2015-02-03 17:43 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-02-03 17:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 03/18] x86/boot: use %ecx instead of %eax
2015-02-03 10:02 ` Jan Beulich
@ 2015-02-03 17:43 ` Daniel Kiper
2015-02-03 17:43 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-02-03 17:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-02-03 17:14 ` Daniel Kiper
2015-02-04 9:04 ` Andrew Cooper
@ 2015-02-04 9:04 ` Andrew Cooper
1 sibling, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-02-04 9:04 UTC (permalink / raw)
To: Daniel Kiper, Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, phcoder, roy.franz, ning.sun, david.vrabel,
xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-02-03 17:14 ` Daniel Kiper
@ 2015-02-04 9:04 ` Andrew Cooper
2015-02-04 9:51 ` Jan Beulich
2015-02-04 9:51 ` Jan Beulich
2015-02-04 9:04 ` Andrew Cooper
1 sibling, 2 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-02-04 9:04 UTC (permalink / raw)
To: Daniel Kiper, Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, phcoder, roy.franz, ning.sun, david.vrabel,
xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-02-04 9:04 ` Andrew Cooper
@ 2015-02-04 9:51 ` Jan Beulich
2015-02-04 9:51 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-04 9:51 UTC (permalink / raw)
To: Andrew Cooper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, phcoder, Daniel Kiper, roy.franz, ning.sun,
david.vrabel, xen-devel, qiaowei.ren, richard.l.maliszewski,
gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-02-04 9:04 ` Andrew Cooper
2015-02-04 9:51 ` Jan Beulich
@ 2015-02-04 9:51 ` Jan Beulich
2015-02-05 10:59 ` Andrew Cooper
` (3 more replies)
1 sibling, 4 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-04 9:51 UTC (permalink / raw)
To: Andrew Cooper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, phcoder, Daniel Kiper, roy.franz, ning.sun,
david.vrabel, xen-devel, qiaowei.ren, richard.l.maliszewski,
gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-02-04 9:51 ` Jan Beulich
@ 2015-02-05 10:59 ` Andrew Cooper
2015-02-05 10:59 ` Andrew Cooper
` (2 subsequent siblings)
3 siblings, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-02-05 10:59 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, phcoder, Daniel Kiper, roy.franz, ning.sun,
david.vrabel, xen-devel, qiaowei.ren, richard.l.maliszewski,
gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-02-04 9:51 ` Jan Beulich
2015-02-05 10:59 ` Andrew Cooper
@ 2015-02-05 10:59 ` Andrew Cooper
2015-02-05 11:50 ` Vladimir 'phcoder' Serbinenko
2015-02-05 11:50 ` Vladimir 'phcoder' Serbinenko
3 siblings, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-02-05 10:59 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, phcoder, Daniel Kiper, roy.franz, ning.sun,
david.vrabel, xen-devel, qiaowei.ren, richard.l.maliszewski,
gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-02-04 9:51 ` Jan Beulich
` (2 preceding siblings ...)
2015-02-05 11:50 ` Vladimir 'phcoder' Serbinenko
@ 2015-02-05 11:50 ` Vladimir 'phcoder' Serbinenko
3 siblings, 0 replies; 166+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2015-02-05 11:50 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, Andrew Cooper, Daniel Kiper, roy.franz,
ning.sun, david.vrabel, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
[-- 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-02-04 9:51 ` Jan Beulich
2015-02-05 10:59 ` Andrew Cooper
2015-02-05 10:59 ` Andrew Cooper
@ 2015-02-05 11:50 ` Vladimir 'phcoder' Serbinenko
2015-02-05 12:00 ` Jan Beulich
2015-02-05 12:00 ` Jan Beulich
2015-02-05 11:50 ` Vladimir 'phcoder' Serbinenko
3 siblings, 2 replies; 166+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2015-02-05 11:50 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, Andrew Cooper, Daniel Kiper, roy.franz,
ning.sun, david.vrabel, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
[-- 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 --]
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-02-05 11:50 ` Vladimir 'phcoder' Serbinenko
2015-02-05 12:00 ` Jan Beulich
@ 2015-02-05 12:00 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-05 12:00 UTC (permalink / raw)
To: Vladimir 'phcoder' Serbinenko
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, Andrew Cooper, Daniel Kiper, roy.franz,
ning.sun, david.vrabel, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-02-05 11:50 ` Vladimir 'phcoder' Serbinenko
@ 2015-02-05 12:00 ` Jan Beulich
2015-02-05 12:00 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-05 12:00 UTC (permalink / raw)
To: Vladimir 'phcoder' Serbinenko
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, Andrew Cooper, Daniel Kiper, roy.franz,
ning.sun, david.vrabel, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (28 preceding siblings ...)
2015-02-02 9:28 ` Jan Beulich
@ 2015-02-09 17:59 ` Daniel Kiper
2015-02-09 17:59 ` Daniel Kiper
` (4 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-02-09 17:59 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (29 preceding siblings ...)
2015-02-09 17:59 ` Daniel Kiper
@ 2015-02-09 17:59 ` Daniel Kiper
2015-02-10 9:05 ` Jan Beulich
2015-02-10 9:05 ` Jan Beulich
2015-03-03 12:10 ` Ian Campbell
` (3 subsequent siblings)
34 siblings, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-02-09 17:59 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-02-09 17:59 ` Daniel Kiper
2015-02-10 9:05 ` Jan Beulich
@ 2015-02-10 9:05 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-10 9:05 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-02-09 17:59 ` Daniel Kiper
@ 2015-02-10 9:05 ` Jan Beulich
2015-02-10 9:05 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-10 9:05 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-01-30 17:54 ` [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
2015-01-30 19:06 ` Andrew Cooper
2015-01-30 19:06 ` Andrew Cooper
@ 2015-02-10 21:27 ` Daniel Kiper
2015-02-10 21:27 ` Daniel Kiper
` (2 subsequent siblings)
5 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-02-10 21:27 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-01-30 17:54 ` [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
` (2 preceding siblings ...)
2015-02-10 21:27 ` Daniel Kiper
@ 2015-02-10 21:27 ` Daniel Kiper
2015-02-10 22:41 ` Andrew Cooper
` (3 more replies)
2015-03-17 10:32 ` Jan Beulich
2015-03-17 10:32 ` Jan Beulich
5 siblings, 4 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-02-10 21:27 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-02-10 21:27 ` Daniel Kiper
2015-02-10 22:41 ` Andrew Cooper
@ 2015-02-10 22:41 ` Andrew Cooper
2015-02-11 8:20 ` Jan Beulich
2015-02-11 8:20 ` Jan Beulich
3 siblings, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-02-10 22:41 UTC (permalink / raw)
To: Daniel Kiper, xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, phcoder, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-02-10 21:27 ` Daniel Kiper
@ 2015-02-10 22:41 ` Andrew Cooper
2015-02-10 22:41 ` Andrew Cooper
` (2 subsequent siblings)
3 siblings, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-02-10 22:41 UTC (permalink / raw)
To: Daniel Kiper, xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, phcoder, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-02-10 21:27 ` Daniel Kiper
2015-02-10 22:41 ` Andrew Cooper
2015-02-10 22:41 ` Andrew Cooper
@ 2015-02-11 8:20 ` Jan Beulich
2015-02-11 8:20 ` Jan Beulich
3 siblings, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-11 8:20 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-02-10 21:27 ` Daniel Kiper
` (2 preceding siblings ...)
2015-02-11 8:20 ` Jan Beulich
@ 2015-02-11 8:20 ` Jan Beulich
2015-02-14 17:23 ` Andrei Borzenkov
2015-02-14 17:23 ` Andrei Borzenkov
3 siblings, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-11 8:20 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-02-11 8:20 ` Jan Beulich
2015-02-14 17:23 ` Andrei Borzenkov
@ 2015-02-14 17:23 ` Andrei Borzenkov
1 sibling, 0 replies; 166+ messages in thread
From: Andrei Borzenkov @ 2015-02-14 17:23 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, Daniel Kiper, roy.franz,
ning.sun, david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
В 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-02-11 8:20 ` Jan Beulich
@ 2015-02-14 17:23 ` Andrei Borzenkov
2015-02-15 21:00 ` Daniel Kiper
2015-02-15 21:00 ` Daniel Kiper
2015-02-14 17:23 ` Andrei Borzenkov
1 sibling, 2 replies; 166+ messages in thread
From: Andrei Borzenkov @ 2015-02-14 17:23 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, Daniel Kiper, roy.franz,
ning.sun, david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
В 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-02-14 17:23 ` Andrei Borzenkov
@ 2015-02-15 21:00 ` Daniel Kiper
2015-02-15 21:00 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-02-15 21:00 UTC (permalink / raw)
To: Andrei Borzenkov
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, Jan Beulich, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-02-14 17:23 ` Andrei Borzenkov
2015-02-15 21:00 ` Daniel Kiper
@ 2015-02-15 21:00 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-02-15 21:00 UTC (permalink / raw)
To: Andrei Borzenkov
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, Jan Beulich, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support
2015-01-30 17:54 ` Daniel Kiper
2015-01-30 18:11 ` Andrew Cooper
2015-01-30 18:11 ` Andrew Cooper
@ 2015-02-20 16:06 ` Jan Beulich
2015-03-27 10:56 ` Daniel Kiper
2015-03-27 10:56 ` Daniel Kiper
2 siblings, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-20 16:06 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-01-30 17:54 ` [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader Daniel Kiper
@ 2015-02-20 16:17 ` Jan Beulich
2015-02-20 16:17 ` Jan Beulich
` (2 subsequent siblings)
3 siblings, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-20 16:17 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-01-30 17:54 ` [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader Daniel Kiper
2015-02-20 16:17 ` Jan Beulich
@ 2015-02-20 16:17 ` Jan Beulich
2015-03-27 13:32 ` Daniel Kiper
2015-03-27 13:32 ` Daniel Kiper
2015-03-02 17:21 ` Stefano Stabellini
2015-03-02 17:21 ` Stefano Stabellini
3 siblings, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-20 16:17 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 07/18] efi: run EFI specific code on EFI platform only
2015-01-30 17:54 ` [PATCH 07/18] efi: run EFI specific code on EFI platform only Daniel Kiper
2015-02-20 16:47 ` Jan Beulich
@ 2015-02-20 16:47 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-20 16:47 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 07/18] efi: run EFI specific code on EFI platform only
2015-01-30 17:54 ` [PATCH 07/18] efi: run EFI specific code on EFI platform only Daniel Kiper
@ 2015-02-20 16:47 ` Jan Beulich
2015-02-20 16:47 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-20 16:47 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 08/18] efi: build xen.gz with EFI code
2015-01-30 17:54 ` [PATCH 08/18] efi: build xen.gz with EFI code Daniel Kiper
@ 2015-03-02 16:14 ` Jan Beulich
2015-03-02 16:14 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-02 16:14 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 08/18] efi: build xen.gz with EFI code
2015-01-30 17:54 ` [PATCH 08/18] efi: build xen.gz with EFI code Daniel Kiper
2015-03-02 16:14 ` Jan Beulich
@ 2015-03-02 16:14 ` Jan Beulich
2015-03-27 11:14 ` Daniel Kiper
2015-03-27 11:14 ` Daniel Kiper
1 sibling, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-02 16:14 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 16/18] efi: create efi_exit_boot()
2015-01-30 17:54 ` [PATCH 16/18] efi: create efi_exit_boot() Daniel Kiper
2015-03-02 16:45 ` Jan Beulich
@ 2015-03-02 16:45 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-02 16:45 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 16/18] efi: create efi_exit_boot()
2015-01-30 17:54 ` [PATCH 16/18] efi: create efi_exit_boot() Daniel Kiper
@ 2015-03-02 16:45 ` Jan Beulich
2015-03-27 12:00 ` Daniel Kiper
2015-03-27 12:00 ` Daniel Kiper
2015-03-02 16:45 ` Jan Beulich
1 sibling, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-02 16:45 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-01-30 17:54 ` [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader Daniel Kiper
2015-02-20 16:17 ` Jan Beulich
2015-02-20 16:17 ` Jan Beulich
@ 2015-03-02 17:21 ` Stefano Stabellini
2015-03-02 17:21 ` Stefano Stabellini
3 siblings, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-03-02 17:21 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, grub-devel, keir, ian.campbell, andrew.cooper3,
stefano.stabellini, roy.franz, ning.sun, david.vrabel, jbeulich,
phcoder, xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei,
fu.wei
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
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-01-30 17:54 ` [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader Daniel Kiper
` (2 preceding siblings ...)
2015-03-02 17:21 ` Stefano Stabellini
@ 2015-03-02 17:21 ` Stefano Stabellini
2015-03-02 18:43 ` Roy Franz
3 siblings, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-03-02 17:21 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, grub-devel, keir, ian.campbell, andrew.cooper3,
stefano.stabellini, roy.franz, ning.sun, david.vrabel, jbeulich,
phcoder, xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei,
fu.wei
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
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 17/18] x86/efi: create new early memory allocator
2015-01-30 17:54 ` [PATCH 17/18] x86/efi: create new early memory allocator Daniel Kiper
2015-03-02 17:23 ` Jan Beulich
@ 2015-03-02 17:23 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-02 17:23 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 17/18] x86/efi: create new early memory allocator
2015-01-30 17:54 ` [PATCH 17/18] x86/efi: create new early memory allocator Daniel Kiper
@ 2015-03-02 17:23 ` Jan Beulich
2015-03-02 20:25 ` Roy Franz
` (2 more replies)
2015-03-02 17:23 ` Jan Beulich
1 sibling, 3 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-02 17:23 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-02 17:21 ` Stefano Stabellini
@ 2015-03-02 18:43 ` Roy Franz
2015-03-02 23:40 ` Roy Franz
2015-03-02 23:40 ` Roy Franz
0 siblings, 2 replies; 166+ messages in thread
From: Roy Franz @ 2015-03-02 18:43 UTC (permalink / raw)
To: Stefano Stabellini
Cc: jgross, grub-devel, keir, Ian Campbell, Andrew Cooper,
Daniel Kiper, ning.sun, david.vrabel, Jan Beulich, phcoder,
xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei, Fu Wei
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
>>
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 17/18] x86/efi: create new early memory allocator
2015-03-02 17:23 ` Jan Beulich
@ 2015-03-02 20:25 ` Roy Franz
2015-03-03 8:04 ` Jan Beulich
2015-03-03 8:04 ` Jan Beulich
2015-03-27 12:57 ` Daniel Kiper
2015-03-27 12:57 ` Daniel Kiper
2 siblings, 2 replies; 166+ messages in thread
From: Roy Franz @ 2015-03-02 20:25 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, Ian Campbell,
Stefano Stabellini, Andrew Cooper, Daniel Kiper, ning.sun,
david.vrabel, Vladimir Serbinenko, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, Fu Wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-02 18:43 ` Roy Franz
@ 2015-03-02 23:40 ` Roy Franz
2015-03-02 23:40 ` Roy Franz
1 sibling, 0 replies; 166+ messages in thread
From: Roy Franz @ 2015-03-02 23:40 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Juergen Gross, grub-devel, keir, Ian Campbell, Andrew Cooper,
Daniel Kiper, ning.sun, david.vrabel, Jan Beulich,
Vladimir Serbinenko, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, Fu Wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-02 18:43 ` Roy Franz
2015-03-02 23:40 ` Roy Franz
@ 2015-03-02 23:40 ` Roy Franz
2015-03-03 8:49 ` Jan Beulich
2015-03-03 8:49 ` Jan Beulich
1 sibling, 2 replies; 166+ messages in thread
From: Roy Franz @ 2015-03-02 23:40 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Juergen Gross, grub-devel, keir, Ian Campbell, Andrew Cooper,
Daniel Kiper, ning.sun, david.vrabel, Jan Beulich,
Vladimir Serbinenko, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, Fu Wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 17/18] x86/efi: create new early memory allocator
2015-03-02 20:25 ` Roy Franz
@ 2015-03-03 8:04 ` Jan Beulich
2015-03-03 8:04 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-03 8:04 UTC (permalink / raw)
To: Roy Franz
Cc: Juergen Gross, grub-devel, keir, Ian Campbell,
Stefano Stabellini, Andrew Cooper, Daniel Kiper, ning.sun,
david.vrabel, Vladimir Serbinenko, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, Fu Wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 17/18] x86/efi: create new early memory allocator
2015-03-02 20:25 ` Roy Franz
2015-03-03 8:04 ` Jan Beulich
@ 2015-03-03 8:04 ` Jan Beulich
2015-03-03 9:39 ` Daniel Kiper
2015-03-03 9:39 ` Daniel Kiper
1 sibling, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-03 8:04 UTC (permalink / raw)
To: Roy Franz
Cc: Juergen Gross, grub-devel, keir, Ian Campbell,
Stefano Stabellini, Andrew Cooper, Daniel Kiper, ning.sun,
david.vrabel, Vladimir Serbinenko, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, Fu Wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-02 23:40 ` Roy Franz
2015-03-03 8:49 ` Jan Beulich
@ 2015-03-03 8:49 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-03 8:49 UTC (permalink / raw)
To: Roy Franz
Cc: Juergen Gross, grub-devel, keir, Ian Campbell,
Stefano Stabellini, Andrew Cooper, Daniel Kiper, ning.sun,
david.vrabel, Vladimir Serbinenko, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, Fu Wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-02 23:40 ` Roy Franz
@ 2015-03-03 8:49 ` Jan Beulich
2015-03-03 8:49 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-03 8:49 UTC (permalink / raw)
To: Roy Franz
Cc: Juergen Gross, grub-devel, keir, Ian Campbell,
Stefano Stabellini, Andrew Cooper, Daniel Kiper, ning.sun,
david.vrabel, Vladimir Serbinenko, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, Fu Wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 17/18] x86/efi: create new early memory allocator
2015-03-03 8:04 ` Jan Beulich
@ 2015-03-03 9:39 ` Daniel Kiper
2015-03-03 9:39 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-03 9:39 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, Ian Campbell,
Stefano Stabellini, Andrew Cooper, Roy Franz, ning.sun,
david.vrabel, Vladimir Serbinenko, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, Fu Wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 17/18] x86/efi: create new early memory allocator
2015-03-03 8:04 ` Jan Beulich
2015-03-03 9:39 ` Daniel Kiper
@ 2015-03-03 9:39 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-03 9:39 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, Ian Campbell,
Stefano Stabellini, Andrew Cooper, Roy Franz, ning.sun,
david.vrabel, Vladimir Serbinenko, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, Fu Wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (30 preceding siblings ...)
2015-02-09 17:59 ` Daniel Kiper
@ 2015-03-03 12:10 ` Ian Campbell
2015-03-03 12:10 ` Ian Campbell
` (2 subsequent siblings)
34 siblings, 0 replies; 166+ messages in thread
From: Ian Campbell @ 2015-03-03 12:10 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, grub-devel, keir, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder, xen-devel,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (31 preceding siblings ...)
2015-03-03 12:10 ` Ian Campbell
@ 2015-03-03 12:10 ` Ian Campbell
2015-03-03 12:36 ` Daniel Kiper
2015-03-03 12:36 ` Daniel Kiper
2015-03-27 10:59 ` Daniel Kiper
2015-03-27 10:59 ` Daniel Kiper
34 siblings, 2 replies; 166+ messages in thread
From: Ian Campbell @ 2015-03-03 12:10 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, grub-devel, keir, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder, xen-devel,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-03-03 12:10 ` Ian Campbell
2015-03-03 12:36 ` Daniel Kiper
@ 2015-03-03 12:36 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-03 12:36 UTC (permalink / raw)
To: Ian Campbell
Cc: jgross, grub-devel, keir, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder, xen-devel,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-03-03 12:10 ` Ian Campbell
@ 2015-03-03 12:36 ` Daniel Kiper
2015-03-03 12:39 ` Ian Campbell
2015-03-03 12:39 ` Ian Campbell
2015-03-03 12:36 ` Daniel Kiper
1 sibling, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-03 12:36 UTC (permalink / raw)
To: Ian Campbell
Cc: jgross, grub-devel, keir, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder, xen-devel,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-03-03 12:36 ` Daniel Kiper
2015-03-03 12:39 ` Ian Campbell
@ 2015-03-03 12:39 ` Ian Campbell
1 sibling, 0 replies; 166+ messages in thread
From: Ian Campbell @ 2015-03-03 12:39 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, grub-devel, keir, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder, xen-devel,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-03-03 12:36 ` Daniel Kiper
@ 2015-03-03 12:39 ` Ian Campbell
2015-03-03 12:51 ` Daniel Kiper
2015-03-03 12:51 ` Daniel Kiper
2015-03-03 12:39 ` Ian Campbell
1 sibling, 2 replies; 166+ messages in thread
From: Ian Campbell @ 2015-03-03 12:39 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, grub-devel, keir, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder, xen-devel,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-03-03 12:39 ` Ian Campbell
2015-03-03 12:51 ` Daniel Kiper
@ 2015-03-03 12:51 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-03 12:51 UTC (permalink / raw)
To: Ian Campbell
Cc: jgross, grub-devel, keir, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder, xen-devel,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-03-03 12:39 ` Ian Campbell
@ 2015-03-03 12:51 ` Daniel Kiper
2015-03-03 12:51 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-03 12:51 UTC (permalink / raw)
To: Ian Campbell
Cc: jgross, grub-devel, keir, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder, xen-devel,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-01-30 17:54 ` [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
` (3 preceding siblings ...)
2015-02-10 21:27 ` Daniel Kiper
@ 2015-03-17 10:32 ` Jan Beulich
2015-03-17 10:32 ` Jan Beulich
5 siblings, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-17 10:32 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-01-30 17:54 ` [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
` (4 preceding siblings ...)
2015-03-17 10:32 ` Jan Beulich
@ 2015-03-17 10:32 ` Jan Beulich
2015-03-17 12:47 ` Daniel Kiper
` (3 more replies)
5 siblings, 4 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-17 10:32 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-17 10:32 ` Jan Beulich
@ 2015-03-17 12:47 ` Daniel Kiper
2015-03-17 12:47 ` Daniel Kiper
` (2 subsequent siblings)
3 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-17 12:47 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-17 10:32 ` Jan Beulich
2015-03-17 12:47 ` Daniel Kiper
@ 2015-03-17 12:47 ` Daniel Kiper
2015-03-27 13:06 ` Daniel Kiper
2015-03-27 13:06 ` Daniel Kiper
3 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-17 12:47 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support
2015-02-20 16:06 ` Jan Beulich
2015-03-27 10:56 ` Daniel Kiper
@ 2015-03-27 10:56 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 10:56 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support
2015-02-20 16:06 ` Jan Beulich
@ 2015-03-27 10:56 ` Daniel Kiper
2015-03-27 11:20 ` Jan Beulich
2015-03-27 11:20 ` Jan Beulich
2015-03-27 10:56 ` Daniel Kiper
1 sibling, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 10:56 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (33 preceding siblings ...)
2015-03-27 10:59 ` Daniel Kiper
@ 2015-03-27 10:59 ` Daniel Kiper
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 10:59 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 00/18] x86: multiboot2 protocol support
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
` (32 preceding siblings ...)
2015-03-03 12:10 ` Ian Campbell
@ 2015-03-27 10:59 ` Daniel Kiper
2015-03-27 10:59 ` Daniel Kiper
34 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 10:59 UTC (permalink / raw)
To: xen-devel, grub-devel
Cc: jgross, keir, ian.campbell, andrew.cooper3, stefano.stabellini,
roy.franz, ning.sun, david.vrabel, jbeulich, phcoder,
qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 08/18] efi: build xen.gz with EFI code
2015-03-02 16:14 ` Jan Beulich
2015-03-27 11:14 ` Daniel Kiper
@ 2015-03-27 11:14 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 11:14 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 08/18] efi: build xen.gz with EFI code
2015-03-02 16:14 ` Jan Beulich
@ 2015-03-27 11:14 ` Daniel Kiper
2015-03-27 11:46 ` Jan Beulich
2015-03-27 11:46 ` Jan Beulich
2015-03-27 11:14 ` Daniel Kiper
1 sibling, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 11:14 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support
2015-03-27 10:56 ` Daniel Kiper
2015-03-27 11:20 ` Jan Beulich
@ 2015-03-27 11:20 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 11:20 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support
2015-03-27 10:56 ` Daniel Kiper
@ 2015-03-27 11:20 ` Jan Beulich
2015-03-27 12:22 ` Daniel Kiper
2015-03-27 12:22 ` Daniel Kiper
2015-03-27 11:20 ` Jan Beulich
1 sibling, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 11:20 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 08/18] efi: build xen.gz with EFI code
2015-03-27 11:14 ` Daniel Kiper
@ 2015-03-27 11:46 ` Jan Beulich
2015-03-27 11:46 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 11:46 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 08/18] efi: build xen.gz with EFI code
2015-03-27 11:14 ` Daniel Kiper
2015-03-27 11:46 ` Jan Beulich
@ 2015-03-27 11:46 ` Jan Beulich
2015-03-27 11:54 ` Andrew Cooper
2015-03-27 11:54 ` Andrew Cooper
1 sibling, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 11:46 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 08/18] efi: build xen.gz with EFI code
2015-03-27 11:46 ` Jan Beulich
2015-03-27 11:54 ` Andrew Cooper
@ 2015-03-27 11:54 ` Andrew Cooper
1 sibling, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-03-27 11:54 UTC (permalink / raw)
To: Jan Beulich, Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, phcoder, roy.franz, ning.sun, david.vrabel,
xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 08/18] efi: build xen.gz with EFI code
2015-03-27 11:46 ` Jan Beulich
@ 2015-03-27 11:54 ` Andrew Cooper
2015-03-27 11:54 ` Andrew Cooper
1 sibling, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-03-27 11:54 UTC (permalink / raw)
To: Jan Beulich, Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, phcoder, roy.franz, ning.sun, david.vrabel,
xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 16/18] efi: create efi_exit_boot()
2015-03-02 16:45 ` Jan Beulich
2015-03-27 12:00 ` Daniel Kiper
@ 2015-03-27 12:00 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 12:00 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 16/18] efi: create efi_exit_boot()
2015-03-02 16:45 ` Jan Beulich
@ 2015-03-27 12:00 ` Daniel Kiper
2015-03-27 12:10 ` Jan Beulich
2015-03-27 12:10 ` Jan Beulich
2015-03-27 12:00 ` Daniel Kiper
1 sibling, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 12:00 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 16/18] efi: create efi_exit_boot()
2015-03-27 12:00 ` Daniel Kiper
2015-03-27 12:10 ` Jan Beulich
@ 2015-03-27 12:10 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 12:10 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 16/18] efi: create efi_exit_boot()
2015-03-27 12:00 ` Daniel Kiper
@ 2015-03-27 12:10 ` Jan Beulich
2015-03-27 12:43 ` Daniel Kiper
2015-03-27 12:43 ` Daniel Kiper
2015-03-27 12:10 ` Jan Beulich
1 sibling, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 12:10 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support
2015-03-27 11:20 ` Jan Beulich
2015-03-27 12:22 ` Daniel Kiper
@ 2015-03-27 12:22 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 12:22 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support
2015-03-27 11:20 ` Jan Beulich
@ 2015-03-27 12:22 ` Daniel Kiper
2015-03-27 12:42 ` Jan Beulich
2015-03-27 12:42 ` Jan Beulich
2015-03-27 12:22 ` Daniel Kiper
1 sibling, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 12:22 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support
2015-03-27 12:22 ` Daniel Kiper
2015-03-27 12:42 ` Jan Beulich
@ 2015-03-27 12:42 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 12:42 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 04/18] xen/x86: add multiboot2 protocol support
2015-03-27 12:22 ` Daniel Kiper
@ 2015-03-27 12:42 ` Jan Beulich
2015-03-27 12:42 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 12:42 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 16/18] efi: create efi_exit_boot()
2015-03-27 12:10 ` Jan Beulich
@ 2015-03-27 12:43 ` Daniel Kiper
2015-03-27 12:43 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 12:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 16/18] efi: create efi_exit_boot()
2015-03-27 12:10 ` Jan Beulich
2015-03-27 12:43 ` Daniel Kiper
@ 2015-03-27 12:43 ` Daniel Kiper
2015-03-27 13:17 ` Ian Campbell
2015-03-27 13:17 ` Ian Campbell
1 sibling, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 12:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 17/18] x86/efi: create new early memory allocator
2015-03-02 17:23 ` Jan Beulich
2015-03-02 20:25 ` Roy Franz
@ 2015-03-27 12:57 ` Daniel Kiper
2015-03-27 12:57 ` Daniel Kiper
2 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 12:57 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 17/18] x86/efi: create new early memory allocator
2015-03-02 17:23 ` Jan Beulich
2015-03-02 20:25 ` Roy Franz
2015-03-27 12:57 ` Daniel Kiper
@ 2015-03-27 12:57 ` Daniel Kiper
2015-03-27 13:35 ` Jan Beulich
2015-03-27 13:35 ` Jan Beulich
2 siblings, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 12:57 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-17 10:32 ` Jan Beulich
` (2 preceding siblings ...)
2015-03-27 13:06 ` Daniel Kiper
@ 2015-03-27 13:06 ` Daniel Kiper
3 siblings, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 13:06 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-17 10:32 ` Jan Beulich
2015-03-17 12:47 ` Daniel Kiper
2015-03-17 12:47 ` Daniel Kiper
@ 2015-03-27 13:06 ` Daniel Kiper
2015-03-27 13:36 ` Jan Beulich
2015-03-27 13:36 ` Jan Beulich
2015-03-27 13:06 ` Daniel Kiper
3 siblings, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 13:06 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 16/18] efi: create efi_exit_boot()
2015-03-27 12:43 ` Daniel Kiper
2015-03-27 13:17 ` Ian Campbell
@ 2015-03-27 13:17 ` Ian Campbell
1 sibling, 0 replies; 166+ messages in thread
From: Ian Campbell @ 2015-03-27 13:17 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, stefano.stabellini,
andrew.cooper3, roy.franz, ning.sun, david.vrabel, Jan Beulich,
phcoder, xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei,
fu.wei
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.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 16/18] efi: create efi_exit_boot()
2015-03-27 12:43 ` Daniel Kiper
@ 2015-03-27 13:17 ` Ian Campbell
2015-03-27 13:17 ` Ian Campbell
1 sibling, 0 replies; 166+ messages in thread
From: Ian Campbell @ 2015-03-27 13:17 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, stefano.stabellini,
andrew.cooper3, roy.franz, ning.sun, david.vrabel, Jan Beulich,
phcoder, xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei,
fu.wei
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.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-02-20 16:17 ` Jan Beulich
@ 2015-03-27 13:32 ` Daniel Kiper
2015-03-27 13:32 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 13:32 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-02-20 16:17 ` Jan Beulich
2015-03-27 13:32 ` Daniel Kiper
@ 2015-03-27 13:32 ` Daniel Kiper
2015-03-27 13:43 ` Jan Beulich
2015-03-27 13:43 ` Jan Beulich
1 sibling, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 13:32 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 17/18] x86/efi: create new early memory allocator
2015-03-27 12:57 ` Daniel Kiper
2015-03-27 13:35 ` Jan Beulich
@ 2015-03-27 13:35 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 13:35 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 17/18] x86/efi: create new early memory allocator
2015-03-27 12:57 ` Daniel Kiper
@ 2015-03-27 13:35 ` Jan Beulich
2015-03-27 14:28 ` Daniel Kiper
2015-03-27 14:28 ` Daniel Kiper
2015-03-27 13:35 ` Jan Beulich
1 sibling, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 13:35 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-27 13:06 ` Daniel Kiper
2015-03-27 13:36 ` Jan Beulich
@ 2015-03-27 13:36 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 13:36 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-27 13:06 ` Daniel Kiper
@ 2015-03-27 13:36 ` Jan Beulich
2015-03-27 14:26 ` Daniel Kiper
2015-03-27 14:26 ` Daniel Kiper
2015-03-27 13:36 ` Jan Beulich
1 sibling, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 13:36 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-27 13:32 ` Daniel Kiper
@ 2015-03-27 13:43 ` Jan Beulich
2015-03-27 13:43 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 13:43 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-27 13:32 ` Daniel Kiper
2015-03-27 13:43 ` Jan Beulich
@ 2015-03-27 13:43 ` Jan Beulich
2015-03-27 13:53 ` Andrew Cooper
2015-03-27 13:53 ` Andrew Cooper
1 sibling, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 13:43 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-27 13:43 ` Jan Beulich
@ 2015-03-27 13:53 ` Andrew Cooper
2015-03-27 13:53 ` Andrew Cooper
1 sibling, 0 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-03-27 13:53 UTC (permalink / raw)
To: Jan Beulich, Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, phcoder, roy.franz, ning.sun, david.vrabel,
xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-27 13:43 ` Jan Beulich
2015-03-27 13:53 ` Andrew Cooper
@ 2015-03-27 13:53 ` Andrew Cooper
2015-03-27 14:04 ` Jan Beulich
2015-03-27 14:04 ` Jan Beulich
1 sibling, 2 replies; 166+ messages in thread
From: Andrew Cooper @ 2015-03-27 13:53 UTC (permalink / raw)
To: Jan Beulich, Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, phcoder, roy.franz, ning.sun, david.vrabel,
xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-27 13:53 ` Andrew Cooper
2015-03-27 14:04 ` Jan Beulich
@ 2015-03-27 14:04 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 14:04 UTC (permalink / raw)
To: Andrew Cooper, Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, phcoder, roy.franz, ning.sun, david.vrabel,
xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-27 13:53 ` Andrew Cooper
@ 2015-03-27 14:04 ` Jan Beulich
2015-03-27 14:09 ` Lennart Sorensen
2015-03-27 14:09 ` Lennart Sorensen
2015-03-27 14:04 ` Jan Beulich
1 sibling, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 14:04 UTC (permalink / raw)
To: Andrew Cooper, Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, phcoder, roy.franz, ning.sun, david.vrabel,
xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-27 14:04 ` Jan Beulich
@ 2015-03-27 14:09 ` Lennart Sorensen
2015-03-27 14:09 ` Lennart Sorensen
1 sibling, 0 replies; 166+ messages in thread
From: Lennart Sorensen @ 2015-03-27 14:09 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Juergen Gross, keir, ian.campbell, stefano.stabellini,
Andrew Cooper, Daniel Kiper, roy.franz, ning.sun, david.vrabel,
phcoder, xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei,
fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-27 14:04 ` Jan Beulich
2015-03-27 14:09 ` Lennart Sorensen
@ 2015-03-27 14:09 ` Lennart Sorensen
2015-03-27 14:19 ` Jan Beulich
2015-03-27 14:19 ` [Xen-devel] " Jan Beulich
1 sibling, 2 replies; 166+ messages in thread
From: Lennart Sorensen @ 2015-03-27 14:09 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Juergen Gross, keir, ian.campbell, stefano.stabellini,
Andrew Cooper, Daniel Kiper, roy.franz, ning.sun, david.vrabel,
phcoder, xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei,
fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-27 14:09 ` Lennart Sorensen
@ 2015-03-27 14:19 ` Jan Beulich
2015-03-27 14:19 ` [Xen-devel] " Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 14:19 UTC (permalink / raw)
To: Lennart Sorensen
Cc: Juergen Gross, The development of GNU GRUB, keir, ian.campbell,
stefano.stabellini, Andrew Cooper, Daniel Kiper, roy.franz,
ning.sun, david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [Xen-devel] [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-27 14:09 ` Lennart Sorensen
2015-03-27 14:19 ` Jan Beulich
@ 2015-03-27 14:19 ` Jan Beulich
2015-03-27 14:21 ` Lennart Sorensen
2015-03-27 14:21 ` [Xen-devel] " Lennart Sorensen
1 sibling, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 14:19 UTC (permalink / raw)
To: Lennart Sorensen
Cc: Juergen Gross, The development of GNU GRUB, keir, ian.campbell,
stefano.stabellini, Andrew Cooper, Daniel Kiper, roy.franz,
ning.sun, david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-27 14:19 ` [Xen-devel] " Jan Beulich
@ 2015-03-27 14:21 ` Lennart Sorensen
2015-03-27 14:21 ` [Xen-devel] " Lennart Sorensen
1 sibling, 0 replies; 166+ messages in thread
From: Lennart Sorensen @ 2015-03-27 14:21 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Juergen Gross, keir, ian.campbell, stefano.stabellini,
Andrew Cooper, Daniel Kiper, roy.franz, ning.sun, david.vrabel,
phcoder, xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei,
fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [Xen-devel] [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader
2015-03-27 14:19 ` [Xen-devel] " Jan Beulich
2015-03-27 14:21 ` Lennart Sorensen
@ 2015-03-27 14:21 ` Lennart Sorensen
1 sibling, 0 replies; 166+ messages in thread
From: Lennart Sorensen @ 2015-03-27 14:21 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Juergen Gross, keir, ian.campbell, stefano.stabellini,
Andrew Cooper, Daniel Kiper, roy.franz, ning.sun, david.vrabel,
phcoder, xen-devel, qiaowei.ren, richard.l.maliszewski, gang.wei,
fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-27 13:36 ` Jan Beulich
@ 2015-03-27 14:26 ` Daniel Kiper
2015-03-27 14:26 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 14:26 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-27 13:36 ` Jan Beulich
2015-03-27 14:26 ` Daniel Kiper
@ 2015-03-27 14:26 ` Daniel Kiper
2015-03-27 14:34 ` Jan Beulich
1 sibling, 1 reply; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 14:26 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 17/18] x86/efi: create new early memory allocator
2015-03-27 13:35 ` Jan Beulich
@ 2015-03-27 14:28 ` Daniel Kiper
2015-03-27 14:28 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 14:28 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 17/18] x86/efi: create new early memory allocator
2015-03-27 13:35 ` Jan Beulich
2015-03-27 14:28 ` Daniel Kiper
@ 2015-03-27 14:28 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 14:28 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-27 14:26 ` Daniel Kiper
@ 2015-03-27 14:34 ` Jan Beulich
2015-03-27 14:57 ` Daniel Kiper
2015-03-27 14:57 ` Daniel Kiper
0 siblings, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 14:34 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-27 14:34 ` Jan Beulich
@ 2015-03-27 14:57 ` Daniel Kiper
2015-03-27 14:57 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 14:57 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-27 14:34 ` Jan Beulich
2015-03-27 14:57 ` Daniel Kiper
@ 2015-03-27 14:57 ` Daniel Kiper
2015-03-27 15:06 ` Jan Beulich
2015-03-27 15:06 ` Jan Beulich
1 sibling, 2 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 14:57 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-27 14:57 ` Daniel Kiper
@ 2015-03-27 15:06 ` Jan Beulich
2015-03-27 15:06 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 15:06 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-27 14:57 ` Daniel Kiper
2015-03-27 15:06 ` Jan Beulich
@ 2015-03-27 15:06 ` Jan Beulich
2015-03-27 15:10 ` Daniel Kiper
2015-03-27 15:10 ` Daniel Kiper
1 sibling, 2 replies; 166+ messages in thread
From: Jan Beulich @ 2015-03-27 15:06 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
>>> 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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-27 15:06 ` Jan Beulich
2015-03-27 15:10 ` Daniel Kiper
@ 2015-03-27 15:10 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 15:10 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms
2015-03-27 15:06 ` Jan Beulich
@ 2015-03-27 15:10 ` Daniel Kiper
2015-03-27 15:10 ` Daniel Kiper
1 sibling, 0 replies; 166+ messages in thread
From: Daniel Kiper @ 2015-03-27 15:10 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, grub-devel, keir, ian.campbell,
stefano.stabellini, andrew.cooper3, roy.franz, ning.sun,
david.vrabel, phcoder, xen-devel, qiaowei.ren,
richard.l.maliszewski, gang.wei, fu.wei
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
^ permalink raw reply [flat|nested] 166+ messages in thread
end of thread, other threads:[~2015-03-27 15:11 UTC | newest]
Thread overview: 166+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-30 17:54 [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
2015-01-30 17:54 ` [PATCH 01/18] x86/boot/reloc: mask out MBI_BOOTDEV from mbi flags Daniel Kiper
2015-01-30 17:59 ` [Xen-devel] " Andrew Cooper
2015-01-30 17:59 ` Andrew Cooper
2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 02/18] x86/boot/reloc: create generic alloc and copy functions Daniel Kiper
2015-01-30 18:02 ` Andrew Cooper
2015-01-30 18:02 ` Andrew Cooper
2015-02-03 10:13 ` Jan Beulich
2015-02-03 10:13 ` Jan Beulich
2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 03/18] x86/boot: use %ecx instead of %eax Daniel Kiper
2015-02-03 10:02 ` Jan Beulich
2015-02-03 17:43 ` Daniel Kiper
2015-02-03 17:43 ` Daniel Kiper
2015-02-03 10:02 ` Jan Beulich
2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 04/18] xen/x86: add multiboot2 protocol support Daniel Kiper
2015-01-30 17:54 ` Daniel Kiper
2015-01-30 18:11 ` Andrew Cooper
2015-01-30 18:11 ` Andrew Cooper
2015-02-20 16:06 ` Jan Beulich
2015-03-27 10:56 ` Daniel Kiper
2015-03-27 11:20 ` Jan Beulich
2015-03-27 12:22 ` Daniel Kiper
2015-03-27 12:42 ` Jan Beulich
2015-03-27 12:42 ` Jan Beulich
2015-03-27 12:22 ` Daniel Kiper
2015-03-27 11:20 ` Jan Beulich
2015-03-27 10:56 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader Daniel Kiper
2015-02-20 16:17 ` Jan Beulich
2015-02-20 16:17 ` Jan Beulich
2015-03-27 13:32 ` Daniel Kiper
2015-03-27 13:32 ` Daniel Kiper
2015-03-27 13:43 ` Jan Beulich
2015-03-27 13:43 ` Jan Beulich
2015-03-27 13:53 ` Andrew Cooper
2015-03-27 13:53 ` Andrew Cooper
2015-03-27 14:04 ` Jan Beulich
2015-03-27 14:09 ` Lennart Sorensen
2015-03-27 14:09 ` Lennart Sorensen
2015-03-27 14:19 ` Jan Beulich
2015-03-27 14:19 ` [Xen-devel] " Jan Beulich
2015-03-27 14:21 ` Lennart Sorensen
2015-03-27 14:21 ` [Xen-devel] " Lennart Sorensen
2015-03-27 14:04 ` Jan Beulich
2015-03-02 17:21 ` Stefano Stabellini
2015-03-02 17:21 ` Stefano Stabellini
2015-03-02 18:43 ` Roy Franz
2015-03-02 23:40 ` Roy Franz
2015-03-02 23:40 ` Roy Franz
2015-03-03 8:49 ` Jan Beulich
2015-03-03 8:49 ` Jan Beulich
2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 06/18] x86: remove commented out stale references to efi_enabled Daniel Kiper
2015-01-30 17:54 ` [PATCH 07/18] efi: run EFI specific code on EFI platform only Daniel Kiper
2015-02-20 16:47 ` Jan Beulich
2015-02-20 16:47 ` Jan Beulich
2015-01-30 17:54 ` [PATCH 08/18] efi: build xen.gz with EFI code Daniel Kiper
2015-03-02 16:14 ` Jan Beulich
2015-03-02 16:14 ` Jan Beulich
2015-03-27 11:14 ` Daniel Kiper
2015-03-27 11:46 ` Jan Beulich
2015-03-27 11:46 ` Jan Beulich
2015-03-27 11:54 ` Andrew Cooper
2015-03-27 11:54 ` Andrew Cooper
2015-03-27 11:14 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 09/18] efi: create efi_init() Daniel Kiper
2015-01-30 17:54 ` [PATCH 10/18] efi: create efi_console_set_mode() Daniel Kiper
2015-01-30 17:54 ` [PATCH 11/18] efi: create efi_get_gop() Daniel Kiper
2015-01-30 17:54 ` [PATCH 12/18] efi: create efi_find_gop_mode() Daniel Kiper
2015-01-30 17:54 ` Daniel Kiper
2015-01-30 17:54 ` [PATCH 13/18] efi: create efi_tables() Daniel Kiper
2015-01-30 17:54 ` [PATCH 14/18] efi: create efi_variables() Daniel Kiper
2015-01-30 17:54 ` [PATCH 15/18] efi: create efi_set_gop_mode() Daniel Kiper
2015-01-30 17:54 ` [PATCH 16/18] efi: create efi_exit_boot() Daniel Kiper
2015-03-02 16:45 ` Jan Beulich
2015-03-27 12:00 ` Daniel Kiper
2015-03-27 12:10 ` Jan Beulich
2015-03-27 12:43 ` Daniel Kiper
2015-03-27 12:43 ` Daniel Kiper
2015-03-27 13:17 ` Ian Campbell
2015-03-27 13:17 ` Ian Campbell
2015-03-27 12:10 ` Jan Beulich
2015-03-27 12:00 ` Daniel Kiper
2015-03-02 16:45 ` Jan Beulich
2015-01-30 17:54 ` [PATCH 17/18] x86/efi: create new early memory allocator Daniel Kiper
2015-03-02 17:23 ` Jan Beulich
2015-03-02 20:25 ` Roy Franz
2015-03-03 8:04 ` Jan Beulich
2015-03-03 8:04 ` Jan Beulich
2015-03-03 9:39 ` Daniel Kiper
2015-03-03 9:39 ` Daniel Kiper
2015-03-27 12:57 ` Daniel Kiper
2015-03-27 12:57 ` Daniel Kiper
2015-03-27 13:35 ` Jan Beulich
2015-03-27 14:28 ` Daniel Kiper
2015-03-27 14:28 ` Daniel Kiper
2015-03-27 13:35 ` Jan Beulich
2015-03-02 17:23 ` Jan Beulich
2015-01-30 17:54 ` [PATCH 18/18] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
2015-01-30 19:06 ` Andrew Cooper
2015-01-30 19:06 ` Andrew Cooper
2015-01-30 23:43 ` Daniel Kiper
2015-01-31 0:47 ` Andrew Cooper
2015-01-31 0:47 ` Andrew Cooper
2015-01-30 23:43 ` Daniel Kiper
2015-02-10 21:27 ` Daniel Kiper
2015-02-10 21:27 ` Daniel Kiper
2015-02-10 22:41 ` Andrew Cooper
2015-02-10 22:41 ` Andrew Cooper
2015-02-11 8:20 ` Jan Beulich
2015-02-11 8:20 ` Jan Beulich
2015-02-14 17:23 ` Andrei Borzenkov
2015-02-15 21:00 ` Daniel Kiper
2015-02-15 21:00 ` Daniel Kiper
2015-02-14 17:23 ` Andrei Borzenkov
2015-03-17 10:32 ` Jan Beulich
2015-03-17 10:32 ` Jan Beulich
2015-03-17 12:47 ` Daniel Kiper
2015-03-17 12:47 ` Daniel Kiper
2015-03-27 13:06 ` Daniel Kiper
2015-03-27 13:36 ` Jan Beulich
2015-03-27 14:26 ` Daniel Kiper
2015-03-27 14:26 ` Daniel Kiper
2015-03-27 14:34 ` Jan Beulich
2015-03-27 14:57 ` Daniel Kiper
2015-03-27 14:57 ` Daniel Kiper
2015-03-27 15:06 ` Jan Beulich
2015-03-27 15:06 ` Jan Beulich
2015-03-27 15:10 ` Daniel Kiper
2015-03-27 15:10 ` Daniel Kiper
2015-03-27 13:36 ` Jan Beulich
2015-03-27 13:06 ` Daniel Kiper
2015-01-30 18:04 ` [PATCH 00/18] x86: multiboot2 protocol support Daniel Kiper
2015-01-30 18:04 ` Daniel Kiper
2015-01-31 7:22 ` João Jerónimo
2015-02-02 9:28 ` Jan Beulich
2015-02-03 17:14 ` Daniel Kiper
2015-02-03 17:14 ` Daniel Kiper
2015-02-04 9:04 ` Andrew Cooper
2015-02-04 9:51 ` Jan Beulich
2015-02-04 9:51 ` Jan Beulich
2015-02-05 10:59 ` Andrew Cooper
2015-02-05 10:59 ` Andrew Cooper
2015-02-05 11:50 ` Vladimir 'phcoder' Serbinenko
2015-02-05 12:00 ` Jan Beulich
2015-02-05 12:00 ` Jan Beulich
2015-02-05 11:50 ` Vladimir 'phcoder' Serbinenko
2015-02-04 9:04 ` Andrew Cooper
2015-02-02 9:28 ` Jan Beulich
2015-02-09 17:59 ` Daniel Kiper
2015-02-09 17:59 ` Daniel Kiper
2015-02-10 9:05 ` Jan Beulich
2015-02-10 9:05 ` Jan Beulich
2015-03-03 12:10 ` Ian Campbell
2015-03-03 12:10 ` Ian Campbell
2015-03-03 12:36 ` Daniel Kiper
2015-03-03 12:39 ` Ian Campbell
2015-03-03 12:51 ` Daniel Kiper
2015-03-03 12:51 ` Daniel Kiper
2015-03-03 12:39 ` Ian Campbell
2015-03-03 12:36 ` Daniel Kiper
2015-03-27 10:59 ` Daniel Kiper
2015-03-27 10:59 ` Daniel Kiper
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.