* [PATCH v12 01/10] x86/boot: implement early command line parser in C
2017-01-20 1:34 [PATCH v12 00/10] x86: multiboot2 protocol support Daniel Kiper
@ 2017-01-20 1:34 ` Daniel Kiper
2017-01-20 16:37 ` Doug Goldstein
2017-01-20 1:34 ` [PATCH v12 02/10] x86: add multiboot2 protocol support Daniel Kiper
` (10 subsequent siblings)
11 siblings, 1 reply; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 1:34 UTC (permalink / raw)
To: xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, jbeulich, qiaowei.ren,
gang.wei, fu.wei
Current early command line parser implementation in assembler
is very difficult to change to relocatable stuff using segment
registers. This requires a lot of changes in very weird and
fragile code. So, reimplement this functionality in C. This
way code will be relocatable out of the box (without playing
with segment registers) and much easier to maintain.
Additionally, put all common cmdline.c and reloc.c definitions
into defs.h header. This way we do not duplicate needlessly
some stuff.
And finally remove unused xen/include/asm-x86/config.h
header from reloc.c dependencies.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
---
v7 - suggestions/fixes:
- add min() macro
(suggested by Jan Beulich),
- add padding to early_boot_opts_t
in more standard way
(suggested by Jan Beulich),
- simplify defs.h dependencies
(suggested by Jan Beulich).
v6 - suggestions/fixes:
- put common cmdline.c and reloc.c
definitions into defs.h header
(suggested by Jan Beulich),
- use xen/include/xen/stdbool.h
and bool type from it instead
of own defined bool_t
(suggested by Jan Beulich),
- define delim_chars as constant
(suggested by Jan Beulich),
- properly align trampoline.S:early_boot_opts struct
(suggested by Jan Beulich),
- fix overflow check in strtoui()
(suggested by Jan Beulich),
- remove unused xen/include/asm-x86/config.h
header from reloc.c dependencies,
- improve commit message.
v4 - suggestions/fixes:
- move to stdcall calling convention
(suggested by Jan Beulich),
- define bool_t and use it properly
(suggested by Jan Beulich),
- put list of delimiter chars into
static const char[]
(suggested by Jan Beulich),
- use strlen() instead of strlen_opt()
(suggested by Jan Beulich),
- change strtoi() to strtoui() and
optimize it a bit
(suggested by Jan Beulich),
- define strchr() and use it in strtoui()
(suggested by Jan Beulich),
- optimize vga_parse()
(suggested by Jan Beulich),
- move !cmdline check from assembly to C
(suggested by Jan Beulich),
- remove my name from copyright (Oracle requirement)
(suggested by Konrad Rzeszutek Wilk).
v3 - suggestions/fixes:
- optimize some code
(suggested by Jan Beulich),
- put VESA data into early_boot_opts_t members
(suggested by Jan Beulich),
- rename some functions and variables
(suggested by Jan Beulich),
- move around video.h include in xen/arch/x86/boot/trampoline.S
(suggested by Jan Beulich),
- fix coding style
(suggested by Jan Beulich),
- fix build with older GCC
(suggested by Konrad Rzeszutek Wilk),
- remove redundant comments
(suggested by Jan Beulich),
- add some comments
- improve commit message
(suggested by Jan Beulich).
---
.gitignore | 5 +-
xen/arch/x86/Makefile | 2 +-
xen/arch/x86/boot/Makefile | 11 +-
xen/arch/x86/boot/build32.mk | 2 +
xen/arch/x86/boot/cmdline.S | 367 ----------------------------------------
xen/arch/x86/boot/cmdline.c | 340 +++++++++++++++++++++++++++++++++++++
xen/arch/x86/boot/defs.h | 58 +++++++
xen/arch/x86/boot/edd.S | 3 -
xen/arch/x86/boot/head.S | 9 +
xen/arch/x86/boot/reloc.c | 9 +-
xen/arch/x86/boot/trampoline.S | 15 ++
xen/arch/x86/boot/video.S | 7 -
12 files changed, 438 insertions(+), 390 deletions(-)
delete mode 100644 xen/arch/x86/boot/cmdline.S
create mode 100644 xen/arch/x86/boot/cmdline.c
create mode 100644 xen/arch/x86/boot/defs.h
diff --git a/.gitignore b/.gitignore
index 7689596..f41c3d0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -252,9 +252,10 @@ xen/arch/arm/xen.lds
xen/arch/x86/asm-offsets.s
xen/arch/x86/boot/mkelf32
xen/arch/x86/xen.lds
+xen/arch/x86/boot/cmdline.S
xen/arch/x86/boot/reloc.S
-xen/arch/x86/boot/reloc.bin
-xen/arch/x86/boot/reloc.lnk
+xen/arch/x86/boot/*.bin
+xen/arch/x86/boot/*.lnk
xen/arch/x86/efi.lds
xen/arch/x86/efi/check.efi
xen/arch/x86/efi/disabled
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 7f6b5d7..007dced 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -220,5 +220,5 @@ clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi efi/disabled efi/mkreloc
- rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin
+ rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
rm -f note.o
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 5fdb5ae..6d20646 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,8 +1,15 @@
obj-bin-y += head.o
-RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h
+DEFS_H_DEPS = defs.h $(BASEDIR)/include/xen/stdbool.h
-head.o: reloc.S
+CMDLINE_DEPS = $(DEFS_H_DEPS) video.h
+
+RELOC_DEPS = $(DEFS_H_DEPS) $(BASEDIR)/include/xen/multiboot.h
+
+head.o: cmdline.S reloc.S
+
+cmdline.S: cmdline.c $(CMDLINE_DEPS)
+ $(MAKE) -f build32.mk $@ CMDLINE_DEPS="$(CMDLINE_DEPS)"
reloc.S: reloc.c $(RELOC_DEPS)
$(MAKE) -f build32.mk $@ RELOC_DEPS="$(RELOC_DEPS)"
diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk
index 272d942..f7e8ebe 100644
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -32,6 +32,8 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
%.o: %.c
$(CC) $(CFLAGS) -c -fpic $< -o $@
+cmdline.o: cmdline.c $(CMDLINE_DEPS)
+
reloc.o: reloc.c $(RELOC_DEPS)
.PRECIOUS: %.bin %.lnk
diff --git a/xen/arch/x86/boot/cmdline.S b/xen/arch/x86/boot/cmdline.S
deleted file mode 100644
index 00687eb..0000000
--- a/xen/arch/x86/boot/cmdline.S
+++ /dev/null
@@ -1,367 +0,0 @@
-/******************************************************************************
- * cmdline.S
- *
- * Early command-line parsing.
- */
-
- .code32
-
-#include "video.h"
-
-# NB. String pointer on stack is modified to point past parsed digits.
-.Latoi:
- push %ebx
- push %ecx
- push %edx
- push %esi
- xor %ebx,%ebx /* %ebx = accumulator */
- mov $10,%ecx /* %ecx = base (default base 10) */
- mov 16+4(%esp),%esi /* %esi = pointer into ascii string. */
- lodsb
- cmpb $'0',%al
- jne 2f
- mov $8,%ecx /* Prefix '0' => octal (base 8) */
- lodsb
- cmpb $'x',%al
- jne 2f
- mov $16,%ecx /* Prefix '0x' => hex (base 16) */
-1: lodsb
-2: sub $'0',%al
- jb 4f
- cmp $9,%al
- jbe 3f
- sub $'A'-'0'-10,%al
- jb 4f
- cmp $15,%al
- jbe 3f
- sub $'a'-'A',%al
- jb 4f
-3: cmp %cl,%al
- jae 4f
- movzbl %al,%eax
- xchg %eax,%ebx
- mul %ecx
- xchg %eax,%ebx
- add %eax,%ebx
- jmp 1b
-4: mov %ebx,%eax
- dec %esi
- mov %esi,16+4(%esp)
- pop %esi
- pop %edx
- pop %ecx
- pop %ebx
- ret
-
-.Lstrstr:
- push %ecx
- push %edx
- push %esi
- push %edi
- xor %eax,%eax
- xor %ecx,%ecx
- not %ecx
- mov 16+4(%esp),%esi
- mov 16+8(%esp),%edi
- repne scasb
- not %ecx
- dec %ecx
- mov %ecx,%edx
-1: mov 16+8(%esp),%edi
- mov %esi,%eax
- mov %edx,%ecx
- repe cmpsb
- je 2f
- xchg %eax,%esi
- inc %esi
- cmpb $0,-1(%eax)
- jne 1b
- xor %eax,%eax
-2: pop %edi
- pop %esi
- pop %edx
- pop %ecx
- ret
-
-.Lstr_prefix:
- push %esi
- push %edi
- mov 8+4(%esp),%esi /* 1st arg is prefix string */
- mov 8+8(%esp),%edi /* 2nd arg is main string */
-1: lodsb
- test %al,%al
- jz 2f
- scasb
- je 1b
- sbb %eax,%eax
- or $1,%al
- jmp 3f
-2: xor %eax,%eax
-3: pop %edi
- pop %esi
- ret
-
-.Lstrlen:
- push %ecx
- push %esi
- push %edi
- xor %eax,%eax
- xor %ecx,%ecx
- not %ecx
- mov 12+4(%esp),%edi
- repne scasb
- not %ecx
- dec %ecx
- mov %ecx,%eax
- pop %edi
- pop %esi
- pop %ecx
- ret
-
-.Lfind_option:
- mov 4(%esp),%eax
- dec %eax
- push %ebx
-1: pushl 4+8(%esp)
- inc %eax
- push %eax
- call .Lstrstr
- add $8,%esp
- test %eax,%eax
- jz 3f
- cmp %eax,4+4(%esp)
- je 2f
- cmpb $' ',-1(%eax)
- jne 1b
-2: mov %eax,%ebx
- pushl 4+8(%esp)
- call .Lstrlen
- add $4,%esp
- xadd %eax,%ebx
- /* NUL check (as $'\0' == 0x30 in GAS) */
- cmpb $0,(%ebx)
- je 3f
- cmpb $' ',(%ebx)
- je 3f
- cmpb $'=',(%ebx)
- jne 1b
-3: pop %ebx
- ret
-
-cmdline_parse_early:
- pusha
-
- /* Bail if there is no command line to parse. */
- mov sym_phys(multiboot_ptr),%ebx
- mov MB_flags(%ebx),%eax
- test $4,%al
- jz .Lcmdline_exit
- mov MB_cmdline(%ebx),%eax
- test %eax,%eax
- jz .Lcmdline_exit
-
- /* Check for 'no-real-mode' command-line option. */
- pushl $sym_phys(.Lno_rm_opt)
- pushl MB_cmdline(%ebx)
- call .Lfind_option
- test %eax,%eax
- setnz %al
- or %al,sym_phys(skip_realmode)
-
- /* Check for 'tboot=' command-line option. */
- movl $sym_phys(.Ltboot_opt),4(%esp)
- call .Lfind_option
- test %eax,%eax
- setnz %al
- or %al,sym_phys(skip_realmode) /* tboot= implies no-real-mode */
-
-.Lparse_edd:
- /* Check for 'edd=' command-line option. */
- movl $sym_phys(.Ledd_opt),4(%esp)
- call .Lfind_option
- test %eax,%eax
- jz .Lparse_edid
- cmpb $'=',3(%eax)
- jne .Lparse_edid
- add $4,%eax
- movb $2,sym_phys(opt_edd) /* opt_edd=2: edd=off */
- cmpw $0x666f,(%eax) /* 0x666f == "of" */
- je .Lparse_edid
- decb sym_phys(opt_edd) /* opt_edd=1: edd=skipmbr */
- cmpw $0x6b73,(%eax) /* 0x6b73 == "sk" */
- je .Lparse_edid
- decb sym_phys(opt_edd) /* opt_edd=0: edd=on (default) */
-
-.Lparse_edid:
- /* Check for 'edid=' command-line option. */
- movl $sym_phys(.Ledid_opt),4(%esp)
- call .Lfind_option
- test %eax,%eax
- jz .Lparse_vga
- cmpb $'=',4(%eax)
- jne .Lparse_vga
- add $5,%eax
- mov %eax,%ebx
- push %ebx
- pushl $sym_phys(.Ledid_force)
- call .Lstr_prefix
- add $8,%esp
- movb $2,sym_phys(opt_edid) /* opt_edid=2: edid=force */
- test %eax,%eax
- jz .Lparse_vga
- push %ebx
- pushl $sym_phys(.Ledid_no)
- call .Lstr_prefix
- add $8,%esp
- decb sym_phys(opt_edid) /* opt_edid=1: edid=no */
- test %eax,%eax
- jz .Lparse_vga
- decb sym_phys(opt_edid) /* opt_edid=0: default */
-
-.Lparse_vga:
- /* Check for 'vga=' command-line option. */
- movl $sym_phys(.Lvga_opt),4(%esp)
- call .Lfind_option
- add $8,%esp
- test %eax,%eax
- jz .Lcmdline_exit
- cmpb $'=',3(%eax)
- jne .Lcmdline_exit
- add $4,%eax
-
- /* Found the 'vga=' option. Default option is to display vga menu. */
- movw $ASK_VGA,sym_phys(boot_vid_mode)
-
- /* Check for 'vga=text-80x<rows>. */
- mov %eax,%ebx
- push %ebx
- pushl $sym_phys(.Lvga_text80)
- call .Lstr_prefix
- add $8,%esp
- test %eax,%eax
- jnz .Lparse_vga_gfx
-
- /* We have 'vga=text-80x<rows>'. */
- add $8,%ebx
- push %ebx
- call .Latoi
- add $4,%esp
- mov %ax,%bx
- lea sym_phys(.Lvga_text_modes),%esi
-1: lodsw
- test %ax,%ax
- jz .Lcmdline_exit
- cmp %ax,%bx
- lodsw
- jne 1b
- mov %ax,sym_phys(boot_vid_mode)
- jmp .Lcmdline_exit
-
-.Lparse_vga_gfx:
- /* Check for 'vga=gfx-<width>x<height>x<depth>'. */
- push %ebx
- pushl $sym_phys(.Lvga_gfx)
- call .Lstr_prefix
- add $8,%esp
- test %eax,%eax
- jnz .Lparse_vga_mode
-
- /* We have 'vga=gfx-<width>x<height>x<depth>'. */
- /* skip 'gfx-' */
- add $4,%ebx
- /* parse <width> */
- push %ebx
- call .Latoi
- pop %esi
- mov %ax,sym_phys(vesa_size)+0
- /* skip 'x' */
- lodsb
- cmpb $'x',%al
- jne .Lcmdline_exit
- /* parse <height> */
- push %esi
- call .Latoi
- pop %esi
- mov %ax,sym_phys(vesa_size)+2
- /* skip 'x' */
- lodsb
- cmpb $'x',%al
- jne .Lcmdline_exit
- /* parse <depth> */
- push %esi
- call .Latoi
- pop %esi
- mov %ax,sym_phys(vesa_size)+4
- /* commit to vesa mode */
- movw $VIDEO_VESA_BY_SIZE,sym_phys(boot_vid_mode)
- jmp .Lcmdline_exit
-
-.Lparse_vga_mode:
- /* Check for 'vga=mode-<mode>'. */
- push %ebx
- pushl $sym_phys(.Lvga_mode)
- call .Lstr_prefix
- add $8,%esp
- test %eax,%eax
- jnz .Lparse_vga_current
-
- /* We have 'vga=mode-<mode>'. */
- add $5,%ebx
- push %ebx
- call .Latoi
- add $4,%esp
- mov %ax,sym_phys(boot_vid_mode)
- jmp .Lcmdline_exit
-
-.Lparse_vga_current:
- /* Check for 'vga=current'. */
- push %ebx
- pushl $sym_phys(.Lvga_current)
- call .Lstr_prefix
- add $8,%esp
- test %eax,%eax
- jnz .Lcmdline_exit
-
- /* We have 'vga=current'. */
- movw $VIDEO_CURRENT_MODE,sym_phys(boot_vid_mode)
-
-.Lcmdline_exit:
- popa
- ret
-
- .pushsection .init.rodata, "a", @progbits
-
-.Lvga_text_modes: /* rows, mode_number */
- .word 25,VIDEO_80x25
- .word 50,VIDEO_80x50
- .word 43,VIDEO_80x43
- .word 28,VIDEO_80x28
- .word 30,VIDEO_80x30
- .word 34,VIDEO_80x34
- .word 60,VIDEO_80x60
- .word 0
-
-.Lvga_opt:
- .asciz "vga"
-.Lvga_text80:
- .asciz "text-80x"
-.Lvga_gfx:
- .asciz "gfx-"
-.Lvga_mode:
- .asciz "mode-"
-.Lvga_current:
- .asciz "current"
-.Lno_rm_opt:
- .asciz "no-real-mode"
-.Ltboot_opt:
- .asciz "tboot"
-.Ledid_opt:
- .asciz "edid"
-.Ledid_force:
- .asciz "force"
-.Ledid_no:
- .asciz "no"
-.Ledd_opt:
- .asciz "edd"
-
- .popsection
diff --git a/xen/arch/x86/boot/cmdline.c b/xen/arch/x86/boot/cmdline.c
new file mode 100644
index 0000000..06aa064
--- /dev/null
+++ b/xen/arch/x86/boot/cmdline.c
@@ -0,0 +1,340 @@
+/*
+ * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ * strlen(), strncmp(), strchr(), strspn() and strcspn() were copied from
+ * Linux kernel source (linux/lib/string.c).
+ */
+
+/*
+ * This entry point is entered from xen/arch/x86/boot/head.S with:
+ * - 0x4(%esp) = &cmdline,
+ * - 0x8(%esp) = &early_boot_opts.
+ */
+asm (
+ " .text \n"
+ " .globl _start \n"
+ "_start: \n"
+ " jmp cmdline_parse_early \n"
+ );
+
+#include "defs.h"
+#include "video.h"
+
+/* Keep in sync with trampoline.S:early_boot_opts label! */
+typedef struct __packed {
+ u8 skip_realmode;
+ u8 opt_edd;
+ u8 opt_edid;
+ u8 padding;
+ u16 boot_vid_mode;
+ u16 vesa_width;
+ u16 vesa_height;
+ u16 vesa_depth;
+} early_boot_opts_t;
+
+/*
+ * Space and TAB are obvious delimiters. However, I am
+ * adding "\n" and "\r" here too. Just in case when
+ * crazy bootloader/user puts them somewhere.
+ */
+static const char delim_chars_comma[] = ", \n\r\t";
+
+#define delim_chars (delim_chars_comma + 1)
+
+static size_t strlen(const char *s)
+{
+ const char *sc;
+
+ for ( sc = s; *sc != '\0'; ++sc )
+ /* nothing */;
+ return sc - s;
+}
+
+static int strncmp(const char *cs, const char *ct, size_t count)
+{
+ unsigned char c1, c2;
+
+ while ( count )
+ {
+ c1 = *cs++;
+ c2 = *ct++;
+ if ( c1 != c2 )
+ return c1 < c2 ? -1 : 1;
+ if ( !c1 )
+ break;
+ count--;
+ }
+ return 0;
+}
+
+static char *strchr(const char *s, int c)
+{
+ for ( ; *s != (char)c; ++s )
+ if ( *s == '\0' )
+ return NULL;
+ return (char *)s;
+}
+
+static size_t strspn(const char *s, const char *accept)
+{
+ const char *p;
+ const char *a;
+ size_t count = 0;
+
+ for ( p = s; *p != '\0'; ++p )
+ {
+ for ( a = accept; *a != '\0'; ++a )
+ {
+ if ( *p == *a )
+ break;
+ }
+ if ( *a == '\0' )
+ return count;
+ ++count;
+ }
+ return count;
+}
+
+static size_t strcspn(const char *s, const char *reject)
+{
+ const char *p;
+ const char *r;
+ size_t count = 0;
+
+ for ( p = s; *p != '\0'; ++p )
+ {
+ for ( r = reject; *r != '\0'; ++r )
+ {
+ if ( *p == *r )
+ return count;
+ }
+ ++count;
+ }
+ return count;
+}
+
+static unsigned int strtoui(const char *s, const char *stop, const char **next)
+{
+ char base = 10, l;
+ unsigned long long res = 0;
+
+ if ( *s == '0' )
+ base = (tolower(*++s) == 'x') ? (++s, 16) : 8;
+
+ for ( ; *s != '\0'; ++s )
+ {
+ if ( stop && strchr(stop, *s) )
+ goto out;
+
+ if ( *s < '0' || (*s > '7' && base == 8) )
+ {
+ res = UINT_MAX;
+ goto out;
+ }
+
+ l = tolower(*s);
+
+ if ( *s > '9' && (base != 16 || l < 'a' || l > 'f') )
+ {
+ res = UINT_MAX;
+ goto out;
+ }
+
+ res *= base;
+ res += (l >= 'a') ? (l - 'a' + 10) : (*s - '0');
+
+ if ( res >= UINT_MAX )
+ {
+ res = UINT_MAX;
+ goto out;
+ }
+ }
+
+ out:
+ if ( next )
+ *next = s;
+
+ return res;
+}
+
+static int strmaxcmp(const char *cs, const char *ct, const char *_delim_chars)
+{
+ return strncmp(cs, ct, max(strcspn(cs, _delim_chars), strlen(ct)));
+}
+
+static int strsubcmp(const char *cs, const char *ct)
+{
+ return strncmp(cs, ct, strlen(ct));
+}
+
+static const char *find_opt(const char *cmdline, const char *opt, bool arg)
+{
+ size_t lc, lo;
+
+ lo = strlen(opt);
+
+ for ( ; ; )
+ {
+ cmdline += strspn(cmdline, delim_chars);
+
+ if ( *cmdline == '\0' )
+ return NULL;
+
+ if ( !strmaxcmp(cmdline, "--", delim_chars) )
+ return NULL;
+
+ lc = strcspn(cmdline, delim_chars);
+
+ if ( !strncmp(cmdline, opt, arg ? lo : max(lc, lo)) )
+ return cmdline + lo;
+
+ cmdline += lc;
+ }
+}
+
+static bool skip_realmode(const char *cmdline)
+{
+ return find_opt(cmdline, "no-real-mode", false) || find_opt(cmdline, "tboot=", true);
+}
+
+static u8 edd_parse(const char *cmdline)
+{
+ const char *c;
+
+ c = find_opt(cmdline, "edd=", true);
+
+ if ( !c )
+ return 0;
+
+ if ( !strmaxcmp(c, "off", delim_chars) )
+ return 2;
+
+ return !strmaxcmp(c, "skipmbr", delim_chars);
+}
+
+static u8 edid_parse(const char *cmdline)
+{
+ const char *c;
+
+ c = find_opt(cmdline, "edid=", true);
+
+ if ( !c )
+ return 0;
+
+ if ( !strmaxcmp(c, "force", delim_chars) )
+ return 2;
+
+ return !strmaxcmp(c, "no", delim_chars);
+}
+
+static u16 rows2vmode(unsigned int rows)
+{
+ switch ( rows )
+ {
+ case 25:
+ return VIDEO_80x25;
+
+ case 28:
+ return VIDEO_80x28;
+
+ case 30:
+ return VIDEO_80x30;
+
+ case 34:
+ return VIDEO_80x34;
+
+ case 43:
+ return VIDEO_80x43;
+
+ case 50:
+ return VIDEO_80x50;
+
+ case 60:
+ return VIDEO_80x60;
+
+ default:
+ return ASK_VGA;
+ }
+}
+
+static void vga_parse(const char *cmdline, early_boot_opts_t *ebo)
+{
+ const char *c;
+ unsigned int tmp, vesa_depth, vesa_height, vesa_width;
+
+ c = find_opt(cmdline, "vga=", true);
+
+ if ( !c )
+ return;
+
+ ebo->boot_vid_mode = ASK_VGA;
+
+ if ( !strmaxcmp(c, "current", delim_chars_comma) )
+ ebo->boot_vid_mode = VIDEO_CURRENT_MODE;
+ else if ( !strsubcmp(c, "text-80x") )
+ {
+ c += strlen("text-80x");
+ ebo->boot_vid_mode = rows2vmode(strtoui(c, delim_chars_comma, NULL));
+ }
+ else if ( !strsubcmp(c, "gfx-") )
+ {
+ vesa_width = strtoui(c + strlen("gfx-"), "x", &c);
+
+ if ( vesa_width > U16_MAX )
+ return;
+
+ /*
+ * Increment c outside of strtoui() because otherwise some
+ * compiler may complain with following message:
+ * warning: operation on 'c' may be undefined.
+ */
+ ++c;
+ vesa_height = strtoui(c, "x", &c);
+
+ if ( vesa_height > U16_MAX )
+ return;
+
+ vesa_depth = strtoui(++c, delim_chars_comma, NULL);
+
+ if ( vesa_depth > U16_MAX )
+ return;
+
+ ebo->vesa_width = vesa_width;
+ ebo->vesa_height = vesa_height;
+ ebo->vesa_depth = vesa_depth;
+ ebo->boot_vid_mode = VIDEO_VESA_BY_SIZE;
+ }
+ else if ( !strsubcmp(c, "mode-") )
+ {
+ tmp = strtoui(c + strlen("mode-"), delim_chars_comma, NULL);
+
+ if ( tmp > U16_MAX )
+ return;
+
+ ebo->boot_vid_mode = tmp;
+ }
+}
+
+void __stdcall cmdline_parse_early(const char *cmdline, early_boot_opts_t *ebo)
+{
+ if ( !cmdline )
+ return;
+
+ ebo->skip_realmode = skip_realmode(cmdline);
+ ebo->opt_edd = edd_parse(cmdline);
+ ebo->opt_edid = edid_parse(cmdline);
+ vga_parse(cmdline, ebo);
+}
diff --git a/xen/arch/x86/boot/defs.h b/xen/arch/x86/boot/defs.h
new file mode 100644
index 0000000..6abdc15
--- /dev/null
+++ b/xen/arch/x86/boot/defs.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ * max() was copied from xen/xen/include/xen/kernel.h.
+ */
+
+#ifndef __BOOT_DEFS_H__
+#define __BOOT_DEFS_H__
+
+#include "../../../include/xen/stdbool.h"
+
+#define __packed __attribute__((__packed__))
+#define __stdcall __attribute__((__stdcall__))
+
+#define NULL ((void *)0)
+
+#define ALIGN_UP(arg, align) \
+ (((arg) + (align) - 1) & ~((typeof(arg))(align) - 1))
+
+#define min(x,y) ({ \
+ const typeof(x) _x = (x); \
+ const typeof(y) _y = (y); \
+ (void) (&_x == &_y); \
+ _x < _y ? _x : _y; })
+
+#define max(x,y) ({ \
+ const typeof(x) _x = (x); \
+ const typeof(y) _y = (y); \
+ (void) (&_x == &_y); \
+ _x > _y ? _x : _y; })
+
+#define _p(val) ((void *)(unsigned long)(val))
+
+#define tolower(c) ((c) | 0x20)
+
+typedef unsigned char u8;
+typedef unsigned short u16;
+typedef unsigned int u32;
+typedef unsigned long long u64;
+typedef unsigned int size_t;
+
+#define U16_MAX ((u16)(~0U))
+#define UINT_MAX (~0U)
+
+#endif /* __BOOT_DEFS_H__ */
diff --git a/xen/arch/x86/boot/edd.S b/xen/arch/x86/boot/edd.S
index 5c80da6..73371f9 100644
--- a/xen/arch/x86/boot/edd.S
+++ b/xen/arch/x86/boot/edd.S
@@ -142,9 +142,6 @@ edd_next:
edd_done:
ret
-opt_edd:
- .byte 0 # edd=on/off/skipmbr
-
GLOBAL(boot_edd_info_nr)
.byte 0
GLOBAL(boot_mbr_signature_nr)
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 6f2c668..126e2e2 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -183,8 +183,16 @@ __start:
cmp $sym_phys(__trampoline_seg_stop),%edi
jb 1b
+ /* Bail if there is no command line to parse. */
+ mov sym_phys(multiboot_ptr),%ebx
+ testl $MBI_CMDLINE,MB_flags(%ebx)
+ jz 1f
+
+ pushl $sym_phys(early_boot_opts)
+ pushl MB_cmdline(%ebx)
call cmdline_parse_early
+1:
/* Switch to low-memory stack. */
mov sym_phys(trampoline_phys),%edi
lea 0x10000(%edi),%esp
@@ -200,6 +208,7 @@ __start:
/* Jump into the relocated trampoline. */
lret
+cmdline_parse_early:
#include "cmdline.S"
reloc:
diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index ea8cb37..91405e9 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -22,16 +22,9 @@ asm (
" jmp reloc \n"
);
-typedef unsigned int u32;
+#include "defs.h"
#include "../../../include/xen/multiboot.h"
-#define __stdcall __attribute__((__stdcall__))
-
-#define ALIGN_UP(arg, align) \
- (((arg) + (align) - 1) & ~((typeof(arg))(align) - 1))
-
-#define _p(val) ((void *)(unsigned long)(val))
-
static u32 alloc;
static u32 alloc_mem(u32 bytes)
diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index b013614..2715d17 100644
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -220,8 +220,23 @@ trampoline_boot_cpu_entry:
/* Jump to the common bootstrap entry point. */
jmp trampoline_protmode_entry
+#include "video.h"
+
+ .align 2
+/* Keep in sync with cmdline.c:early_boot_opts_t type! */
+early_boot_opts:
skip_realmode:
.byte 0
+opt_edd:
+ .byte 0 /* edd=on/off/skipmbr */
+opt_edid:
+ .byte 0 /* EDID parsing option (force/no/default). */
+/* Padding. */
+ .byte 0
+GLOBAL(boot_vid_mode)
+ .word VIDEO_80x25 /* If we don't run at all, assume basic video mode 3 at 80x25. */
+vesa_size:
+ .word 0,0,0 /* width x depth x height */
GLOBAL(kbd_shift_flags)
.byte 0
diff --git a/xen/arch/x86/boot/video.S b/xen/arch/x86/boot/video.S
index 2aafbeb..335a51c 100644
--- a/xen/arch/x86/boot/video.S
+++ b/xen/arch/x86/boot/video.S
@@ -945,7 +945,6 @@ store_edid:
#endif
ret
-opt_edid: .byte 0 # EDID parsing option (force/no/default)
mt_end: .word 0 # End of video mode table if built
edit_buf: .space 6 # Line editor buffer
card_name: .word 0 # Pointer to adapter name
@@ -991,12 +990,6 @@ name_bann: .asciz "Video adapter: "
force_size: .word 0 # Use this size instead of the one in BIOS vars
-vesa_size: .word 0,0,0 # width x depth x height
-
-/* If we don't run at all, assume basic video mode 3 at 80x25. */
- .align 2
-GLOBAL(boot_vid_mode)
- .word VIDEO_80x25
GLOBAL(boot_vid_info)
.byte 0, 0 /* orig_x, orig_y */
.byte 3 /* text mode 3 */
--
1.7.10.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 51+ messages in thread* Re: [PATCH v12 01/10] x86/boot: implement early command line parser in C
2017-01-20 1:34 ` [PATCH v12 01/10] x86/boot: implement early command line parser in C Daniel Kiper
@ 2017-01-20 16:37 ` Doug Goldstein
2017-01-20 16:41 ` Doug Goldstein
0 siblings, 1 reply; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 16:37 UTC (permalink / raw)
To: Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 897 bytes --]
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
> index 5fdb5ae..6d20646 100644
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -1,8 +1,15 @@
> obj-bin-y += head.o
>
> -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h
> +DEFS_H_DEPS = defs.h $(BASEDIR)/include/xen/stdbool.h
>
> -head.o: reloc.S
> +CMDLINE_DEPS = $(DEFS_H_DEPS) video.h
> +
> +RELOC_DEPS = $(DEFS_H_DEPS) $(BASEDIR)/include/xen/multiboot.h
So when this was patch 8 this previously had:
+RELOC_DEPS = $(DEFS_H_DEPS) $(BASEDIR)/include/xen/multiboot.h \
+ $(BASEDIR)/include/xen/multiboot2.h
Which its now moved to patch 1 so obviously can't include multiboot2.h
but then patch 2 in this series fails to add this and patch 5 fails to
add this.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 01/10] x86/boot: implement early command line parser in C
2017-01-20 16:37 ` Doug Goldstein
@ 2017-01-20 16:41 ` Doug Goldstein
0 siblings, 0 replies; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 16:41 UTC (permalink / raw)
To: Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 1028 bytes --]
On 1/20/17 11:37 AM, Doug Goldstein wrote:
> On 1/19/17 8:34 PM, Daniel Kiper wrote:
>> diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
>> index 5fdb5ae..6d20646 100644
>> --- a/xen/arch/x86/boot/Makefile
>> +++ b/xen/arch/x86/boot/Makefile
>> @@ -1,8 +1,15 @@
>> obj-bin-y += head.o
>>
>> -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h
>> +DEFS_H_DEPS = defs.h $(BASEDIR)/include/xen/stdbool.h
>>
>> -head.o: reloc.S
>> +CMDLINE_DEPS = $(DEFS_H_DEPS) video.h
>> +
>> +RELOC_DEPS = $(DEFS_H_DEPS) $(BASEDIR)/include/xen/multiboot.h
>
> So when this was patch 8 this previously had:
>
> +RELOC_DEPS = $(DEFS_H_DEPS) $(BASEDIR)/include/xen/multiboot.h \
> + $(BASEDIR)/include/xen/multiboot2.h
>
> Which its now moved to patch 1 so obviously can't include multiboot2.h
> but then patch 2 in this series fails to add this and patch 5 fails to
> add this.
>
Ignore this. I missed it in patch 2 at first.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* [PATCH v12 02/10] x86: add multiboot2 protocol support
2017-01-20 1:34 [PATCH v12 00/10] x86: multiboot2 protocol support Daniel Kiper
2017-01-20 1:34 ` [PATCH v12 01/10] x86/boot: implement early command line parser in C Daniel Kiper
@ 2017-01-20 1:34 ` Daniel Kiper
2017-01-20 16:52 ` Andrew Cooper
2017-01-20 19:01 ` Doug Goldstein
2017-01-20 1:34 ` [PATCH v12 03/10] efi: build xen.gz with EFI code Daniel Kiper
` (9 subsequent siblings)
11 siblings, 2 replies; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 1:34 UTC (permalink / raw)
To: xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, jbeulich, qiaowei.ren,
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>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
---
v12 - suggestions/fixes:
- replace TABs with spaces in xen/include/xen/multiboot2.h
(suggested by Doug Goldstein).
v9 - suggestions/fixes:
- use .L label instead of numeric one in multiboot2 data scanning loop;
I hope that this change does not invalidate Jan's Reviewed-by
(suggested by Jan Beulich).
v8 - suggestions/fixes:
- use sizeof(<var>/<expr>) instead of sizeof(<type>)
if it is possible
(suggested by Jan Beulich).
v7 - suggestions/fixes:
- rename mbi_mbi/mbi2_mbi to mbi_reloc/mbi2_reloc respectively
(suggested by Jan Beulich),
- initialize mbi_out->flags using "|=" instead of "="
(suggested by Jan Beulich),
- use sizeof(*mmap_dst) instead of sizeof(memory_map_t)
if it makes sense
(suggested by Jan Beulich).
v6 - suggestions/fixes:
- properly index multiboot2_tag_mmap_t.entries[]
(suggested by Jan Beulich),
- do not index mbi_out_mods[] beyond its end
(suggested by Andrew Cooper),
- reduce number of casts
(suggested by Andrew Cooper and Jan Beulich),
- add braces to increase code readability
(suggested by Andrew Cooper).
v5 - suggestions/fixes:
- check multiboot2_tag_mmap_t.entry_size before
multiboot2_tag_mmap_t.entries[] use
(suggested by Jan Beulich),
- properly index multiboot2_tag_mmap_t.entries[]
(suggested by Jan Beulich),
- use "type name[]" instad of "type name[0]"
in xen/include/xen/multiboot2.h
(suggested by Jan Beulich),
- remove unneeded comment
(suggested by Jan Beulich).
v4 - suggestions/fixes:
- avoid assembly usage in xen/arch/x86/boot/reloc.c,
- fix boundary check issue and optimize
for() loops in mbi2_mbi(),
- move to stdcall calling convention,
- remove unneeded typeof() from ALIGN_UP() macro
(suggested by Jan Beulich),
- add and use NULL definition in xen/arch/x86/boot/reloc.c
(suggested by Jan Beulich),
- do not read data beyond the end of multiboot2
information in xen/arch/x86/boot/head.S
(suggested by Jan Beulich),
- add :req to some .macro arguments
(suggested by Jan Beulich),
- use cmovcc if possible,
- add .L to multiboot2_header_end label
(suggested by Jan Beulich),
- add .L to multiboot2_proto label
(suggested by Jan Beulich),
- improve label names
(suggested by Jan Beulich).
v3 - suggestions/fixes:
- reorder reloc() arguments
(suggested by Jan Beulich),
- remove .L from multiboot2 header labels
(suggested by Andrew Cooper, Jan Beulich and Konrad Rzeszutek Wilk),
- take into account alignment when skipping multiboot2 fixed part
(suggested by Konrad Rzeszutek Wilk),
- create modules data if modules count != 0
(suggested by Jan Beulich),
- improve macros
(suggested by Jan Beulich),
- reduce number of casts
(suggested by Jan Beulich),
- use const if possible
(suggested by Jan Beulich),
- drop static and __used__ attribute from reloc()
(suggested by Jan Beulich),
- remove isolated/stray __packed attribute from
multiboot2_memory_map_t type definition
(suggested by Jan Beulich),
- reformat xen/include/xen/multiboot2.h
(suggested by Konrad Rzeszutek Wilk),
- improve comments
(suggested by Konrad Rzeszutek Wilk),
- remove hard tabs
(suggested by Jan Beulich and Konrad Rzeszutek Wilk).
v2 - suggestions/fixes:
- generate multiboot2 header using macros
(suggested by Jan Beulich),
- improve comments
(suggested by Jan Beulich),
- simplify assembly in xen/arch/x86/boot/head.S
(suggested by Jan Beulich),
- do not include include/xen/compiler.h
in xen/arch/x86/boot/reloc.c
(suggested by Jan Beulich),
- do not read data beyond the end of multiboot2 information
(suggested by Jan Beulich).
v2 - not fixed yet:
- dynamic dependency generation for xen/arch/x86/boot/reloc.S;
this requires more work; I am not sure that it pays because
potential patch requires more changes than addition of just
multiboot2.h to Makefile
(suggested by Jan Beulich),
- isolated/stray __packed attribute usage for multiboot2_memory_map_t
(suggested by Jan Beulich).
---
xen/arch/x86/boot/Makefile | 3 +-
xen/arch/x86/boot/head.S | 107 ++++++++++++++++++++++-
xen/arch/x86/boot/reloc.c | 144 +++++++++++++++++++++++++++++--
xen/arch/x86/x86_64/asm-offsets.c | 9 ++
xen/include/xen/multiboot2.h | 169 +++++++++++++++++++++++++++++++++++++
5 files changed, 422 insertions(+), 10 deletions(-)
create mode 100644 xen/include/xen/multiboot2.h
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 6d20646..c6246c8 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -4,7 +4,8 @@ DEFS_H_DEPS = defs.h $(BASEDIR)/include/xen/stdbool.h
CMDLINE_DEPS = $(DEFS_H_DEPS) video.h
-RELOC_DEPS = $(DEFS_H_DEPS) $(BASEDIR)/include/xen/multiboot.h
+RELOC_DEPS = $(DEFS_H_DEPS) $(BASEDIR)/include/xen/multiboot.h \
+ $(BASEDIR)/include/xen/multiboot2.h
head.o: cmdline.S reloc.S
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 126e2e2..84cf44d 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>
@@ -19,6 +20,28 @@
#define BOOT_PSEUDORM_CS 0x0020
#define BOOT_PSEUDORM_DS 0x0028
+#define MB2_HT(name) (MULTIBOOT2_HEADER_TAG_##name)
+#define MB2_TT(name) (MULTIBOOT2_TAG_TYPE_##name)
+
+ .macro mb2ht_args arg:req, args:vararg
+ .long \arg
+ .ifnb \args
+ mb2ht_args \args
+ .endif
+ .endm
+
+ .macro mb2ht_init type:req, req:req, args:vararg
+ .align MULTIBOOT2_TAG_ALIGN
+.Lmb2ht_init_start\@:
+ .short \type
+ .short \req
+ .long .Lmb2ht_init_end\@ - .Lmb2ht_init_start\@
+ .ifnb \args
+ mb2ht_args \args
+ .endif
+.Lmb2ht_init_end\@:
+ .endm
+
ENTRY(start)
jmp __start
@@ -34,6 +57,42 @@ multiboot1_header_start: /*** MULTIBOOT1 HEADER ****/
.long -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
multiboot1_header_end:
+/*** MULTIBOOT2 HEADER ****/
+/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S file. */
+ .align MULTIBOOT2_HEADER_ALIGN
+
+multiboot2_header_start:
+ /* Magic number indicating a Multiboot2 header. */
+ .long MULTIBOOT2_HEADER_MAGIC
+ /* Architecture: i386. */
+ .long MULTIBOOT2_ARCHITECTURE_I386
+ /* Multiboot2 header length. */
+ .long .Lmultiboot2_header_end - multiboot2_header_start
+ /* Multiboot2 header checksum. */
+ .long -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
+ (.Lmultiboot2_header_end - multiboot2_header_start))
+
+ /* Multiboot2 information request tag. */
+ mb2ht_init MB2_HT(INFORMATION_REQUEST), MB2_HT(REQUIRED), \
+ MB2_TT(BASIC_MEMINFO), MB2_TT(MMAP)
+
+ /* Align modules at page boundry. */
+ mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
+
+ /* Console flags tag. */
+ mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
+ MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
+
+ /* Framebuffer tag. */
+ mb2ht_init MB2_HT(FRAMEBUFFER), MB2_HT(OPTIONAL), \
+ 0, /* Number of the columns - no preference. */ \
+ 0, /* Number of the lines - no preference. */ \
+ 0 /* Number of bits per pixel - no preference. */
+
+ /* Multiboot2 header end tag. */
+ mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
+.Lmultiboot2_header_end:
+
.section .init.rodata, "a", @progbits
.align 4
@@ -82,10 +141,52 @@ __start:
mov %ecx,%es
mov %ecx,%ss
- /* Check for Multiboot bootloader */
+ /* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
+ xor %edx,%edx
+
+ /* Check for Multiboot2 bootloader. */
+ cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
+ je .Lmultiboot2_proto
+
+ /* Check for Multiboot bootloader. */
cmp $MULTIBOOT_BOOTLOADER_MAGIC,%eax
jne not_multiboot
+ /* Get mem_lower from Multiboot information. */
+ testb $MBI_MEMLIMITS,MB_flags(%ebx)
+
+ /* Not available? BDA value will be fine. */
+ cmovnz MB_mem_lower(%ebx),%edx
+ jmp trampoline_setup
+
+.Lmultiboot2_proto:
+ /* Skip Multiboot2 information fixed part. */
+ lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%ebx),%ecx
+ and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
+
+.Lmb2_tsize:
+ /* Check Multiboot2 information total size. */
+ mov %ecx,%edi
+ sub %ebx,%edi
+ cmp %edi,MB2_fixed_total_size(%ebx)
+ jbe trampoline_setup
+
+ /* Get mem_lower from Multiboot2 information. */
+ cmpl $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
+ cmove MB2_mem_lower(%ecx),%edx
+ je trampoline_setup
+
+ /* Is it the end of Multiboot2 information? */
+ cmpl $MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%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 .Lmb2_tsize
+
+trampoline_setup:
/* Set up trampoline segment 64k below EBDA */
movzwl 0x40e,%ecx /* EBDA segment */
cmp $0xa000,%ecx /* sanity check (high) */
@@ -100,9 +201,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
@@ -121,6 +219,7 @@ __start:
mov $sym_phys(cpu0_stack)+1024,%esp
push %ecx /* Boot trampoline address. */
push %ebx /* Multiboot information address. */
+ push %eax /* Multiboot magic. */
call reloc
mov %eax,sym_phys(multiboot_ptr)
diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 91405e9..0f2e372 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -5,15 +5,18 @@
* and modules. This is most easily done early with paging disabled.
*
* Copyright (c) 2009, Citrix Systems, Inc.
+ * Copyright (c) 2013-2016 Oracle and/or its affiliates. All rights reserved.
*
* Authors:
* Keir Fraser <keir@xen.org>
+ * Daniel Kiper <daniel.kiper@oracle.com>
*/
/*
* This entry point is entered from xen/arch/x86/boot/head.S with:
- * - 0x4(%esp) = MULTIBOOT_INFORMATION_ADDRESS,
- * - 0x8(%esp) = BOOT_TRAMPOLINE_ADDRESS.
+ * - 0x4(%esp) = MULTIBOOT_MAGIC,
+ * - 0x8(%esp) = MULTIBOOT_INFORMATION_ADDRESS,
+ * - 0xc(%esp) = BOOT_TRAMPOLINE_ADDRESS.
*/
asm (
" .text \n"
@@ -24,6 +27,10 @@ asm (
#include "defs.h"
#include "../../../include/xen/multiboot.h"
+#include "../../../include/xen/multiboot2.h"
+
+#define get_mb2_data(tag, type, member) (((multiboot2_tag_##type##_t *)(tag))->member)
+#define get_mb2_string(tag, type, member) ((u32)get_mb2_data(tag, type, member))
static u32 alloc;
@@ -32,6 +39,12 @@ static u32 alloc_mem(u32 bytes)
return alloc -= ALIGN_UP(bytes, 16);
}
+static void zero_mem(u32 s, u32 bytes)
+{
+ while ( bytes-- )
+ *(char *)s++ = 0;
+}
+
static u32 copy_mem(u32 src, u32 bytes)
{
u32 dst, dst_ret;
@@ -58,13 +71,11 @@ static u32 copy_string(u32 src)
return copy_mem(src, p - src + 1);
}
-multiboot_info_t __stdcall *reloc(u32 mbi_in, u32 trampoline)
+static multiboot_info_t *mbi_reloc(u32 mbi_in)
{
int i;
multiboot_info_t *mbi_out;
- alloc = trampoline;
-
mbi_out = _p(copy_mem(mbi_in, sizeof(*mbi_out)));
if ( mbi_out->flags & MBI_CMDLINE )
@@ -101,3 +112,126 @@ multiboot_info_t __stdcall *reloc(u32 mbi_in, u32 trampoline)
return mbi_out;
}
+
+static multiboot_info_t *mbi2_reloc(u32 mbi_in)
+{
+ const multiboot2_fixed_t *mbi_fix = _p(mbi_in);
+ const multiboot2_memory_map_t *mmap_src;
+ const multiboot2_tag_t *tag;
+ module_t *mbi_out_mods = NULL;
+ memory_map_t *mmap_dst;
+ multiboot_info_t *mbi_out;
+ u32 ptr;
+ unsigned int i, mod_idx = 0;
+
+ ptr = alloc_mem(sizeof(*mbi_out));
+ mbi_out = _p(ptr);
+ zero_mem(ptr, sizeof(*mbi_out));
+
+ /* Skip Multiboot2 information fixed part. */
+ ptr = ALIGN_UP(mbi_in + sizeof(*mbi_fix), MULTIBOOT2_TAG_ALIGN);
+
+ /* Get the number of modules. */
+ for ( tag = _p(ptr); (u32)tag - mbi_in < mbi_fix->total_size;
+ tag = _p(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN)) )
+ {
+ if ( tag->type == MULTIBOOT2_TAG_TYPE_MODULE )
+ ++mbi_out->mods_count;
+ else if ( tag->type == MULTIBOOT2_TAG_TYPE_END )
+ break;
+ }
+
+ if ( mbi_out->mods_count )
+ {
+ mbi_out->flags |= MBI_MODULES;
+ mbi_out->mods_addr = alloc_mem(mbi_out->mods_count * sizeof(*mbi_out_mods));
+ mbi_out_mods = _p(mbi_out->mods_addr);
+ }
+
+ /* Skip Multiboot2 information fixed part. */
+ ptr = ALIGN_UP(mbi_in + sizeof(*mbi_fix), MULTIBOOT2_TAG_ALIGN);
+
+ /* Put all needed data into mbi_out. */
+ for ( tag = _p(ptr); (u32)tag - mbi_in < mbi_fix->total_size;
+ tag = _p(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN)) )
+ switch ( tag->type )
+ {
+ case MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME:
+ mbi_out->flags |= MBI_LOADERNAME;
+ ptr = get_mb2_string(tag, string, string);
+ mbi_out->boot_loader_name = copy_string(ptr);
+ break;
+
+ case MULTIBOOT2_TAG_TYPE_CMDLINE:
+ mbi_out->flags |= MBI_CMDLINE;
+ ptr = get_mb2_string(tag, string, 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, basic_meminfo, mem_lower);
+ mbi_out->mem_upper = get_mb2_data(tag, basic_meminfo, mem_upper);
+ break;
+
+ case MULTIBOOT2_TAG_TYPE_MMAP:
+ if ( get_mb2_data(tag, mmap, entry_size) < sizeof(*mmap_src) )
+ break;
+
+ mbi_out->flags |= MBI_MEMMAP;
+ mbi_out->mmap_length = get_mb2_data(tag, mmap, size);
+ mbi_out->mmap_length -= sizeof(multiboot2_tag_mmap_t);
+ mbi_out->mmap_length /= get_mb2_data(tag, mmap, entry_size);
+ mbi_out->mmap_length *= sizeof(*mmap_dst);
+
+ mbi_out->mmap_addr = alloc_mem(mbi_out->mmap_length);
+
+ mmap_src = get_mb2_data(tag, mmap, entries);
+ mmap_dst = _p(mbi_out->mmap_addr);
+
+ for ( i = 0; i < mbi_out->mmap_length / sizeof(*mmap_dst); i++ )
+ {
+ /* Init size member properly. */
+ mmap_dst[i].size = sizeof(*mmap_dst);
+ mmap_dst[i].size -= sizeof(mmap_dst[i].size);
+ /* Now copy a given region data. */
+ mmap_dst[i].base_addr_low = (u32)mmap_src->addr;
+ mmap_dst[i].base_addr_high = (u32)(mmap_src->addr >> 32);
+ mmap_dst[i].length_low = (u32)mmap_src->len;
+ mmap_dst[i].length_high = (u32)(mmap_src->len >> 32);
+ mmap_dst[i].type = mmap_src->type;
+ mmap_src = _p(mmap_src) + get_mb2_data(tag, mmap, entry_size);
+ }
+ break;
+
+ case MULTIBOOT2_TAG_TYPE_MODULE:
+ if ( mod_idx >= mbi_out->mods_count )
+ break;
+
+ mbi_out_mods[mod_idx].mod_start = get_mb2_data(tag, module, mod_start);
+ mbi_out_mods[mod_idx].mod_end = get_mb2_data(tag, module, mod_end);
+ ptr = get_mb2_string(tag, module, 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;
+ }
+
+ return mbi_out;
+}
+
+multiboot_info_t __stdcall *reloc(u32 mb_magic, u32 mbi_in, u32 trampoline)
+{
+ alloc = trampoline;
+
+ if ( mb_magic == MULTIBOOT2_BOOTLOADER_MAGIC )
+ return mbi2_reloc(mbi_in);
+ else
+ return mbi_reloc(mbi_in);
+}
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index 0e1f09d..92f5d81 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 " */<==\"" \
@@ -167,6 +168,14 @@ 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_fixed_total_size, multiboot2_fixed_t, total_size);
+ OFFSET(MB2_tag_type, multiboot2_tag_t, type);
+ OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+ OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
+ BLANK();
OFFSET(DOMAIN_vm_assist, struct domain, vm_assist);
}
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
new file mode 100644
index 0000000..a3e3119
--- /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[];
+} multiboot2_tag_string_t;
+
+typedef struct {
+ u32 type;
+ u32 size;
+ u32 mem_lower;
+ u32 mem_upper;
+} multiboot2_tag_basic_meminfo_t;
+
+typedef struct {
+ 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[];
+} 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[];
+} multiboot2_tag_module_t;
+#endif /* __ASSEMBLY__ */
+
+#endif /* __MULTIBOOT2_H__ */
--
1.7.10.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 51+ messages in thread* Re: [PATCH v12 02/10] x86: add multiboot2 protocol support
2017-01-20 1:34 ` [PATCH v12 02/10] x86: add multiboot2 protocol support Daniel Kiper
@ 2017-01-20 16:52 ` Andrew Cooper
2017-01-20 17:24 ` Daniel Kiper
2017-01-20 19:01 ` Doug Goldstein
1 sibling, 1 reply; 51+ messages in thread
From: Andrew Cooper @ 2017-01-20 16:52 UTC (permalink / raw)
To: Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, cardoe, pgnet.dev, ning.sun,
julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
On 20/01/17 01:34, Daniel Kiper wrote:
> @@ -101,3 +112,126 @@ multiboot_info_t __stdcall *reloc(u32 mbi_in, u32 trampoline)
>
> return mbi_out;
> }
> +
> +static multiboot_info_t *mbi2_reloc(u32 mbi_in)
> +{
> + const multiboot2_fixed_t *mbi_fix = _p(mbi_in);
> + const multiboot2_memory_map_t *mmap_src;
> + const multiboot2_tag_t *tag;
> + module_t *mbi_out_mods = NULL;
> + memory_map_t *mmap_dst;
> + multiboot_info_t *mbi_out;
> + u32 ptr;
> + unsigned int i, mod_idx = 0;
> +
> + ptr = alloc_mem(sizeof(*mbi_out));
> + mbi_out = _p(ptr);
> + zero_mem(ptr, sizeof(*mbi_out));
> +
> + /* Skip Multiboot2 information fixed part. */
> + ptr = ALIGN_UP(mbi_in + sizeof(*mbi_fix), MULTIBOOT2_TAG_ALIGN);
> +
> + /* Get the number of modules. */
> + for ( tag = _p(ptr); (u32)tag - mbi_in < mbi_fix->total_size;
> + tag = _p(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN)) )
> + {
> + if ( tag->type == MULTIBOOT2_TAG_TYPE_MODULE )
> + ++mbi_out->mods_count;
> + else if ( tag->type == MULTIBOOT2_TAG_TYPE_END )
> + break;
> + }
> +
> + if ( mbi_out->mods_count )
> + {
> + mbi_out->flags |= MBI_MODULES;
> + mbi_out->mods_addr = alloc_mem(mbi_out->mods_count * sizeof(*mbi_out_mods));
> + mbi_out_mods = _p(mbi_out->mods_addr);
> + }
> +
> + /* Skip Multiboot2 information fixed part. */
> + ptr = ALIGN_UP(mbi_in + sizeof(*mbi_fix), MULTIBOOT2_TAG_ALIGN);
> +
> + /* Put all needed data into mbi_out. */
> + for ( tag = _p(ptr); (u32)tag - mbi_in < mbi_fix->total_size;
> + tag = _p(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN)) )
> + switch ( tag->type )
> + {
> + case MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME:
> + mbi_out->flags |= MBI_LOADERNAME;
> + ptr = get_mb2_string(tag, string, string);
> + mbi_out->boot_loader_name = copy_string(ptr);
> + break;
> +
> + case MULTIBOOT2_TAG_TYPE_CMDLINE:
> + mbi_out->flags |= MBI_CMDLINE;
> + ptr = get_mb2_string(tag, string, 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, basic_meminfo, mem_lower);
> + mbi_out->mem_upper = get_mb2_data(tag, basic_meminfo, mem_upper);
> + break;
> +
> + case MULTIBOOT2_TAG_TYPE_MMAP:
> + if ( get_mb2_data(tag, mmap, entry_size) < sizeof(*mmap_src) )
> + break;
> +
> + mbi_out->flags |= MBI_MEMMAP;
> + mbi_out->mmap_length = get_mb2_data(tag, mmap, size);
> + mbi_out->mmap_length -= sizeof(multiboot2_tag_mmap_t);
> + mbi_out->mmap_length /= get_mb2_data(tag, mmap, entry_size);
> + mbi_out->mmap_length *= sizeof(*mmap_dst);
> +
> + mbi_out->mmap_addr = alloc_mem(mbi_out->mmap_length);
> +
> + mmap_src = get_mb2_data(tag, mmap, entries);
> + mmap_dst = _p(mbi_out->mmap_addr);
> +
> + for ( i = 0; i < mbi_out->mmap_length / sizeof(*mmap_dst); i++ )
> + {
> + /* Init size member properly. */
> + mmap_dst[i].size = sizeof(*mmap_dst);
> + mmap_dst[i].size -= sizeof(mmap_dst[i].size);
> + /* Now copy a given region data. */
> + mmap_dst[i].base_addr_low = (u32)mmap_src->addr;
> + mmap_dst[i].base_addr_high = (u32)(mmap_src->addr >> 32);
> + mmap_dst[i].length_low = (u32)mmap_src->len;
> + mmap_dst[i].length_high = (u32)(mmap_src->len >> 32);
> + mmap_dst[i].type = mmap_src->type;
> + mmap_src = _p(mmap_src) + get_mb2_data(tag, mmap, entry_size);
> + }
> + break;
> +
> + case MULTIBOOT2_TAG_TYPE_MODULE:
> + if ( mod_idx >= mbi_out->mods_count )
> + break;
> +
> + mbi_out_mods[mod_idx].mod_start = get_mb2_data(tag, module, mod_start);
> + mbi_out_mods[mod_idx].mod_end = get_mb2_data(tag, module, mod_end);
> + ptr = get_mb2_string(tag, module, 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;
> + }
> +
> + return mbi_out;
> +}
> +
> +multiboot_info_t __stdcall *reloc(u32 mb_magic, u32 mbi_in, u32 trampoline)
> +{
> + alloc = trampoline;
> +
> + if ( mb_magic == MULTIBOOT2_BOOTLOADER_MAGIC )
> + return mbi2_reloc(mbi_in);
> + else
> + return mbi_reloc(mbi_in);
> +}
Can we get a
/*
* Local
variables:
* mode:
C
* c-file-style:
"BSD"
* c-basic-offset:
4
* indent-tabs-mode:
nil
*
End:
*/
here please?
With this, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
With this patch present, should legacy booting with MB2 work properly?
If so, I have a good mind to take the patch now so it can get better
testing (at which point I can fix up this one issue).
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [PATCH v12 02/10] x86: add multiboot2 protocol support
2017-01-20 16:52 ` Andrew Cooper
@ 2017-01-20 17:24 ` Daniel Kiper
2017-01-20 18:07 ` Andrew Cooper
0 siblings, 1 reply; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 17:24 UTC (permalink / raw)
To: Andrew Cooper
Cc: jgross, sstabellini, konrad.wilk, cardoe, pgnet.dev, ning.sun,
julien.grall, jbeulich, xen-devel, qiaowei.ren, gang.wei, fu.wei
On Fri, Jan 20, 2017 at 04:52:30PM +0000, Andrew Cooper wrote:
> On 20/01/17 01:34, Daniel Kiper wrote:
> > @@ -101,3 +112,126 @@ multiboot_info_t __stdcall *reloc(u32 mbi_in, u32 trampoline)
> >
> > return mbi_out;
> > }
> > +
> > +static multiboot_info_t *mbi2_reloc(u32 mbi_in)
> > +{
> > + const multiboot2_fixed_t *mbi_fix = _p(mbi_in);
> > + const multiboot2_memory_map_t *mmap_src;
> > + const multiboot2_tag_t *tag;
> > + module_t *mbi_out_mods = NULL;
> > + memory_map_t *mmap_dst;
> > + multiboot_info_t *mbi_out;
> > + u32 ptr;
> > + unsigned int i, mod_idx = 0;
> > +
> > + ptr = alloc_mem(sizeof(*mbi_out));
> > + mbi_out = _p(ptr);
> > + zero_mem(ptr, sizeof(*mbi_out));
> > +
> > + /* Skip Multiboot2 information fixed part. */
> > + ptr = ALIGN_UP(mbi_in + sizeof(*mbi_fix), MULTIBOOT2_TAG_ALIGN);
> > +
> > + /* Get the number of modules. */
> > + for ( tag = _p(ptr); (u32)tag - mbi_in < mbi_fix->total_size;
> > + tag = _p(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN)) )
> > + {
> > + if ( tag->type == MULTIBOOT2_TAG_TYPE_MODULE )
> > + ++mbi_out->mods_count;
> > + else if ( tag->type == MULTIBOOT2_TAG_TYPE_END )
> > + break;
> > + }
> > +
> > + if ( mbi_out->mods_count )
> > + {
> > + mbi_out->flags |= MBI_MODULES;
> > + mbi_out->mods_addr = alloc_mem(mbi_out->mods_count * sizeof(*mbi_out_mods));
> > + mbi_out_mods = _p(mbi_out->mods_addr);
> > + }
> > +
> > + /* Skip Multiboot2 information fixed part. */
> > + ptr = ALIGN_UP(mbi_in + sizeof(*mbi_fix), MULTIBOOT2_TAG_ALIGN);
> > +
> > + /* Put all needed data into mbi_out. */
> > + for ( tag = _p(ptr); (u32)tag - mbi_in < mbi_fix->total_size;
> > + tag = _p(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN)) )
> > + switch ( tag->type )
> > + {
> > + case MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME:
> > + mbi_out->flags |= MBI_LOADERNAME;
> > + ptr = get_mb2_string(tag, string, string);
> > + mbi_out->boot_loader_name = copy_string(ptr);
> > + break;
> > +
> > + case MULTIBOOT2_TAG_TYPE_CMDLINE:
> > + mbi_out->flags |= MBI_CMDLINE;
> > + ptr = get_mb2_string(tag, string, 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, basic_meminfo, mem_lower);
> > + mbi_out->mem_upper = get_mb2_data(tag, basic_meminfo, mem_upper);
> > + break;
> > +
> > + case MULTIBOOT2_TAG_TYPE_MMAP:
> > + if ( get_mb2_data(tag, mmap, entry_size) < sizeof(*mmap_src) )
> > + break;
> > +
> > + mbi_out->flags |= MBI_MEMMAP;
> > + mbi_out->mmap_length = get_mb2_data(tag, mmap, size);
> > + mbi_out->mmap_length -= sizeof(multiboot2_tag_mmap_t);
> > + mbi_out->mmap_length /= get_mb2_data(tag, mmap, entry_size);
> > + mbi_out->mmap_length *= sizeof(*mmap_dst);
> > +
> > + mbi_out->mmap_addr = alloc_mem(mbi_out->mmap_length);
> > +
> > + mmap_src = get_mb2_data(tag, mmap, entries);
> > + mmap_dst = _p(mbi_out->mmap_addr);
> > +
> > + for ( i = 0; i < mbi_out->mmap_length / sizeof(*mmap_dst); i++ )
> > + {
> > + /* Init size member properly. */
> > + mmap_dst[i].size = sizeof(*mmap_dst);
> > + mmap_dst[i].size -= sizeof(mmap_dst[i].size);
> > + /* Now copy a given region data. */
> > + mmap_dst[i].base_addr_low = (u32)mmap_src->addr;
> > + mmap_dst[i].base_addr_high = (u32)(mmap_src->addr >> 32);
> > + mmap_dst[i].length_low = (u32)mmap_src->len;
> > + mmap_dst[i].length_high = (u32)(mmap_src->len >> 32);
> > + mmap_dst[i].type = mmap_src->type;
> > + mmap_src = _p(mmap_src) + get_mb2_data(tag, mmap, entry_size);
> > + }
> > + break;
> > +
> > + case MULTIBOOT2_TAG_TYPE_MODULE:
> > + if ( mod_idx >= mbi_out->mods_count )
> > + break;
> > +
> > + mbi_out_mods[mod_idx].mod_start = get_mb2_data(tag, module, mod_start);
> > + mbi_out_mods[mod_idx].mod_end = get_mb2_data(tag, module, mod_end);
> > + ptr = get_mb2_string(tag, module, 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;
> > + }
> > +
> > + return mbi_out;
> > +}
> > +
> > +multiboot_info_t __stdcall *reloc(u32 mb_magic, u32 mbi_in, u32 trampoline)
> > +{
> > + alloc = trampoline;
> > +
> > + if ( mb_magic == MULTIBOOT2_BOOTLOADER_MAGIC )
> > + return mbi2_reloc(mbi_in);
> > + else
> > + return mbi_reloc(mbi_in);
> > +}
>
> Can we get a
>
> /*
>
> * Local
> variables:
>
> * mode:
> C
>
> * c-file-style:
> "BSD"
>
> * c-basic-offset:
> 4
>
> * indent-tabs-mode:
> nil
>
> *
> End:
>
> */
>
> here please?
Will do.
> With this, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Thanks!
> With this patch present, should legacy booting with MB2 work properly?
> If so, I have a good mind to take the patch now so it can get better
> testing (at which point I can fix up this one issue).
Yep, however, you have to remember that there is no support for
relocatable images here. It is added by subsequent patches.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [PATCH v12 02/10] x86: add multiboot2 protocol support
2017-01-20 17:24 ` Daniel Kiper
@ 2017-01-20 18:07 ` Andrew Cooper
0 siblings, 0 replies; 51+ messages in thread
From: Andrew Cooper @ 2017-01-20 18:07 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, sstabellini, konrad.wilk, cardoe, pgnet.dev, ning.sun,
julien.grall, jbeulich, xen-devel, qiaowei.ren, gang.wei, fu.wei
On 20/01/17 17:24, Daniel Kiper wrote:
> On Fri, Jan 20, 2017 at 04:52:30PM +0000, Andrew Cooper wrote:
>>
>> here please?
> Will do.
>
>> With this, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Thanks!
>
>> With this patch present, should legacy booting with MB2 work properly?
>> If so, I have a good mind to take the patch now so it can get better
>> testing (at which point I can fix up this one issue).
I have confirmed that MB2 seems to work for me, with a few extra
diagnostics in reloc.c
(XEN) Bootloader: GRUB 2.02~beta2, MB protocol 2
> Yep, however, you have to remember that there is no support for
> relocatable images here. It is added by subsequent patches.
Using MB2 as the boot protocol is orthogonal to supporting relocation of
the images. The former a useful piece of functionality to have even in
the absence of the latter.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 02/10] x86: add multiboot2 protocol support
2017-01-20 1:34 ` [PATCH v12 02/10] x86: add multiboot2 protocol support Daniel Kiper
2017-01-20 16:52 ` Andrew Cooper
@ 2017-01-20 19:01 ` Doug Goldstein
1 sibling, 0 replies; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 19:01 UTC (permalink / raw)
To: Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 14273 bytes --]
On 1/19/17 8:34 PM, 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>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
> ---
> v12 - suggestions/fixes:
> - replace TABs with spaces in xen/include/xen/multiboot2.h
> (suggested by Doug Goldstein).
>
> v9 - suggestions/fixes:
> - use .L label instead of numeric one in multiboot2 data scanning loop;
> I hope that this change does not invalidate Jan's Reviewed-by
> (suggested by Jan Beulich).
>
> v8 - suggestions/fixes:
> - use sizeof(<var>/<expr>) instead of sizeof(<type>)
> if it is possible
> (suggested by Jan Beulich).
>
> v7 - suggestions/fixes:
> - rename mbi_mbi/mbi2_mbi to mbi_reloc/mbi2_reloc respectively
> (suggested by Jan Beulich),
> - initialize mbi_out->flags using "|=" instead of "="
> (suggested by Jan Beulich),
> - use sizeof(*mmap_dst) instead of sizeof(memory_map_t)
> if it makes sense
> (suggested by Jan Beulich).
>
> v6 - suggestions/fixes:
> - properly index multiboot2_tag_mmap_t.entries[]
> (suggested by Jan Beulich),
> - do not index mbi_out_mods[] beyond its end
> (suggested by Andrew Cooper),
> - reduce number of casts
> (suggested by Andrew Cooper and Jan Beulich),
> - add braces to increase code readability
> (suggested by Andrew Cooper).
>
> v5 - suggestions/fixes:
> - check multiboot2_tag_mmap_t.entry_size before
> multiboot2_tag_mmap_t.entries[] use
> (suggested by Jan Beulich),
> - properly index multiboot2_tag_mmap_t.entries[]
> (suggested by Jan Beulich),
> - use "type name[]" instad of "type name[0]"
> in xen/include/xen/multiboot2.h
> (suggested by Jan Beulich),
> - remove unneeded comment
> (suggested by Jan Beulich).
>
> v4 - suggestions/fixes:
> - avoid assembly usage in xen/arch/x86/boot/reloc.c,
> - fix boundary check issue and optimize
> for() loops in mbi2_mbi(),
> - move to stdcall calling convention,
> - remove unneeded typeof() from ALIGN_UP() macro
> (suggested by Jan Beulich),
> - add and use NULL definition in xen/arch/x86/boot/reloc.c
> (suggested by Jan Beulich),
> - do not read data beyond the end of multiboot2
> information in xen/arch/x86/boot/head.S
> (suggested by Jan Beulich),
> - add :req to some .macro arguments
> (suggested by Jan Beulich),
> - use cmovcc if possible,
> - add .L to multiboot2_header_end label
> (suggested by Jan Beulich),
> - add .L to multiboot2_proto label
> (suggested by Jan Beulich),
> - improve label names
> (suggested by Jan Beulich).
>
> v3 - suggestions/fixes:
> - reorder reloc() arguments
> (suggested by Jan Beulich),
> - remove .L from multiboot2 header labels
> (suggested by Andrew Cooper, Jan Beulich and Konrad Rzeszutek Wilk),
> - take into account alignment when skipping multiboot2 fixed part
> (suggested by Konrad Rzeszutek Wilk),
> - create modules data if modules count != 0
> (suggested by Jan Beulich),
> - improve macros
> (suggested by Jan Beulich),
> - reduce number of casts
> (suggested by Jan Beulich),
> - use const if possible
> (suggested by Jan Beulich),
> - drop static and __used__ attribute from reloc()
> (suggested by Jan Beulich),
> - remove isolated/stray __packed attribute from
> multiboot2_memory_map_t type definition
> (suggested by Jan Beulich),
> - reformat xen/include/xen/multiboot2.h
> (suggested by Konrad Rzeszutek Wilk),
> - improve comments
> (suggested by Konrad Rzeszutek Wilk),
> - remove hard tabs
> (suggested by Jan Beulich and Konrad Rzeszutek Wilk).
>
> v2 - suggestions/fixes:
> - generate multiboot2 header using macros
> (suggested by Jan Beulich),
> - improve comments
> (suggested by Jan Beulich),
> - simplify assembly in xen/arch/x86/boot/head.S
> (suggested by Jan Beulich),
> - do not include include/xen/compiler.h
> in xen/arch/x86/boot/reloc.c
> (suggested by Jan Beulich),
> - do not read data beyond the end of multiboot2 information
> (suggested by Jan Beulich).
>
> v2 - not fixed yet:
> - dynamic dependency generation for xen/arch/x86/boot/reloc.S;
> this requires more work; I am not sure that it pays because
> potential patch requires more changes than addition of just
> multiboot2.h to Makefile
> (suggested by Jan Beulich),
> - isolated/stray __packed attribute usage for multiboot2_memory_map_t
> (suggested by Jan Beulich).
> ---
> xen/arch/x86/boot/Makefile | 3 +-
> xen/arch/x86/boot/head.S | 107 ++++++++++++++++++++++-
> xen/arch/x86/boot/reloc.c | 144 +++++++++++++++++++++++++++++--
> xen/arch/x86/x86_64/asm-offsets.c | 9 ++
> xen/include/xen/multiboot2.h | 169 +++++++++++++++++++++++++++++++++++++
> 5 files changed, 422 insertions(+), 10 deletions(-)
> create mode 100644 xen/include/xen/multiboot2.h
>
> diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
> index 6d20646..c6246c8 100644
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -4,7 +4,8 @@ DEFS_H_DEPS = defs.h $(BASEDIR)/include/xen/stdbool.h
>
> CMDLINE_DEPS = $(DEFS_H_DEPS) video.h
>
> -RELOC_DEPS = $(DEFS_H_DEPS) $(BASEDIR)/include/xen/multiboot.h
> +RELOC_DEPS = $(DEFS_H_DEPS) $(BASEDIR)/include/xen/multiboot.h \
> + $(BASEDIR)/include/xen/multiboot2.h
>
> head.o: cmdline.S reloc.S
>
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 126e2e2..84cf44d 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>
> @@ -19,6 +20,28 @@
> #define BOOT_PSEUDORM_CS 0x0020
> #define BOOT_PSEUDORM_DS 0x0028
>
> +#define MB2_HT(name) (MULTIBOOT2_HEADER_TAG_##name)
> +#define MB2_TT(name) (MULTIBOOT2_TAG_TYPE_##name)
> +
> + .macro mb2ht_args arg:req, args:vararg
> + .long \arg
> + .ifnb \args
> + mb2ht_args \args
> + .endif
> + .endm
> +
> + .macro mb2ht_init type:req, req:req, args:vararg
> + .align MULTIBOOT2_TAG_ALIGN
> +.Lmb2ht_init_start\@:
> + .short \type
> + .short \req
> + .long .Lmb2ht_init_end\@ - .Lmb2ht_init_start\@
> + .ifnb \args
> + mb2ht_args \args
> + .endif
> +.Lmb2ht_init_end\@:
> + .endm
> +
> ENTRY(start)
> jmp __start
>
> @@ -34,6 +57,42 @@ multiboot1_header_start: /*** MULTIBOOT1 HEADER ****/
> .long -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
> multiboot1_header_end:
>
> +/*** MULTIBOOT2 HEADER ****/
> +/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S file. */
> + .align MULTIBOOT2_HEADER_ALIGN
> +
> +multiboot2_header_start:
> + /* Magic number indicating a Multiboot2 header. */
> + .long MULTIBOOT2_HEADER_MAGIC
> + /* Architecture: i386. */
> + .long MULTIBOOT2_ARCHITECTURE_I386
> + /* Multiboot2 header length. */
> + .long .Lmultiboot2_header_end - multiboot2_header_start
> + /* Multiboot2 header checksum. */
> + .long -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
> + (.Lmultiboot2_header_end - multiboot2_header_start))
> +
> + /* Multiboot2 information request tag. */
> + mb2ht_init MB2_HT(INFORMATION_REQUEST), MB2_HT(REQUIRED), \
> + MB2_TT(BASIC_MEMINFO), MB2_TT(MMAP)
> +
> + /* Align modules at page boundry. */
> + mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
> +
> + /* Console flags tag. */
> + mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
> + MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
> +
> + /* Framebuffer tag. */
> + mb2ht_init MB2_HT(FRAMEBUFFER), MB2_HT(OPTIONAL), \
> + 0, /* Number of the columns - no preference. */ \
> + 0, /* Number of the lines - no preference. */ \
> + 0 /* Number of bits per pixel - no preference. */
> +
> + /* Multiboot2 header end tag. */
> + mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
> +.Lmultiboot2_header_end:
> +
> .section .init.rodata, "a", @progbits
> .align 4
>
> @@ -82,10 +141,52 @@ __start:
> mov %ecx,%es
> mov %ecx,%ss
>
> - /* Check for Multiboot bootloader */
> + /* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
> + xor %edx,%edx
> +
> + /* Check for Multiboot2 bootloader. */
> + cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> + je .Lmultiboot2_proto
> +
> + /* Check for Multiboot bootloader. */
> cmp $MULTIBOOT_BOOTLOADER_MAGIC,%eax
> jne not_multiboot
>
> + /* Get mem_lower from Multiboot information. */
> + testb $MBI_MEMLIMITS,MB_flags(%ebx)
> +
> + /* Not available? BDA value will be fine. */
> + cmovnz MB_mem_lower(%ebx),%edx
> + jmp trampoline_setup
> +
> +.Lmultiboot2_proto:
> + /* Skip Multiboot2 information fixed part. */
> + lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%ebx),%ecx
> + and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +
> +.Lmb2_tsize:
> + /* Check Multiboot2 information total size. */
> + mov %ecx,%edi
> + sub %ebx,%edi
> + cmp %edi,MB2_fixed_total_size(%ebx)
> + jbe trampoline_setup
> +
> + /* Get mem_lower from Multiboot2 information. */
> + cmpl $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
> + cmove MB2_mem_lower(%ecx),%edx
> + je trampoline_setup
> +
> + /* Is it the end of Multiboot2 information? */
> + cmpl $MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%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 .Lmb2_tsize
> +
> +trampoline_setup:
> /* Set up trampoline segment 64k below EBDA */
> movzwl 0x40e,%ecx /* EBDA segment */
> cmp $0xa000,%ecx /* sanity check (high) */
> @@ -100,9 +201,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
> @@ -121,6 +219,7 @@ __start:
> mov $sym_phys(cpu0_stack)+1024,%esp
> push %ecx /* Boot trampoline address. */
> push %ebx /* Multiboot information address. */
> + push %eax /* Multiboot magic. */
> call reloc
> mov %eax,sym_phys(multiboot_ptr)
>
> diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
> index 91405e9..0f2e372 100644
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -5,15 +5,18 @@
> * and modules. This is most easily done early with paging disabled.
> *
> * Copyright (c) 2009, Citrix Systems, Inc.
> + * Copyright (c) 2013-2016 Oracle and/or its affiliates. All rights reserved.
> *
> * Authors:
> * Keir Fraser <keir@xen.org>
> + * Daniel Kiper <daniel.kiper@oracle.com>
> */
>
> /*
> * This entry point is entered from xen/arch/x86/boot/head.S with:
> - * - 0x4(%esp) = MULTIBOOT_INFORMATION_ADDRESS,
> - * - 0x8(%esp) = BOOT_TRAMPOLINE_ADDRESS.
> + * - 0x4(%esp) = MULTIBOOT_MAGIC,
> + * - 0x8(%esp) = MULTIBOOT_INFORMATION_ADDRESS,
> + * - 0xc(%esp) = BOOT_TRAMPOLINE_ADDRESS.
> */
> asm (
> " .text \n"
> @@ -24,6 +27,10 @@ asm (
>
> #include "defs.h"
> #include "../../../include/xen/multiboot.h"
> +#include "../../../include/xen/multiboot2.h"
> +
> +#define get_mb2_data(tag, type, member) (((multiboot2_tag_##type##_t *)(tag))->member)
> +#define get_mb2_string(tag, type, member) ((u32)get_mb2_data(tag, type, member))
>
> static u32 alloc;
>
> @@ -32,6 +39,12 @@ static u32 alloc_mem(u32 bytes)
> return alloc -= ALIGN_UP(bytes, 16);
So this works its way DOWN from the supplied trampoline start address
which is coming from cfg.addr correct? So you set cfg.size to
TRAMPOLINE_SIZE + TRAMPOLINE_STACK_SIZE + MBI_SIZE but rather than
starting at cfg.addr + MBI_SIZE you are growing down into the area
before cfg.addr. You've changed this series to use AllocatePages() now
which is allocating from conventional memory of cfg.size immediately
after a non-conventional memory region. The result is this math is
growing into the non-conventional memory and just blowing it away.
Previously you allocated manually by going to the end of the
conventional region and walking backwards cfg.size. It happened to have
at least MBI_SIZE of space available before it so it caused it to work.
Please someone tell me if my conclusions are incorrect here.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* [PATCH v12 03/10] efi: build xen.gz with EFI code
2017-01-20 1:34 [PATCH v12 00/10] x86: multiboot2 protocol support Daniel Kiper
2017-01-20 1:34 ` [PATCH v12 01/10] x86/boot: implement early command line parser in C Daniel Kiper
2017-01-20 1:34 ` [PATCH v12 02/10] x86: add multiboot2 protocol support Daniel Kiper
@ 2017-01-20 1:34 ` Daniel Kiper
2017-01-20 1:34 ` [PATCH v12 04/10] efi: create new early memory allocator Daniel Kiper
` (8 subsequent siblings)
11 siblings, 0 replies; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 1:34 UTC (permalink / raw)
To: xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, jbeulich, qiaowei.ren,
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 non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file contains
many sections which are not "linear" (one after another without any holes)
or even do not have representation in a file (e.g. BSS). From EFI point
of view everything is OK and works. However, this file layout cannot be
properly interpreted by multiboot protocols family. In theory there is
a chance that we could build proper PE file (from multiboot protocols POV)
using current build system. However, it means that xen.efi further diverge
from Xen ELF file (in terms of contents and build method). On the other
hand ELF has all needed properties. So, it means that this is good starting
point for further development. Additionally, I think that this is also good
starting point for further xen.efi code and build optimizations. It looks
that there is a chance that finally we can generate xen.efi directly from
Xen ELF using just simple objcopy or other tool. This way we will have one
Xen binary which can be loaded by three boot protocols: EFI native loader,
multiboot (v1) and multiboot2.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
---
v6 - suggestions/fixes:
- improve efi_enabled() checks in efi_runtime_call()
(suggested by Jan Beulich).
v5 - suggestions/fixes:
- properly calculate efi symbol address in
xen/arch/x86/xen.lds.S (I hope that this
change does not invalidate Jan's ACK).
v4 - suggestions/fixes:
- functions should return -ENOSYS instead
of -EOPNOTSUPP if EFI runtime services
are not available
(suggested by Jan Beulich),
- remove stale bits from xen/arch/x86/Makefile
(suggested by Jan Beulich).
v3 - suggestions/fixes:
- check for EFI platform in EFI code
(suggested by Jan Beulich),
- fix Makefiles
(suggested by Jan Beulich),
- improve commit message
(suggested by Jan Beulich).
v2 - suggestions/fixes:
- build EFI code only if it is supported in a given build environment
(suggested by Jan Beulich).
---
xen/arch/x86/Makefile | 2 +-
xen/arch/x86/efi/Makefile | 12 ++++--------
xen/arch/x86/xen.lds.S | 4 ++--
xen/common/efi/boot.c | 3 +++
xen/common/efi/runtime.c | 9 +++++++++
5 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 007dced..08e9f7b 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -219,6 +219,6 @@ efi/mkreloc: efi/mkreloc.c
clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
- rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi efi/disabled efi/mkreloc
+ rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
rm -f note.o
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index ad3fdf7..442f3fc 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,18 +1,14 @@
CFLAGS += -fshort-wchar
-obj-y += stub.o
-
-create = test -e $(1) || touch -t 199901010000 $(1)
-
efi := y$(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 buildid.o
+efi := $(if $(efi),$(shell rm disabled)y)
%.o: %.ihex
$(OBJCOPY) -I ihex -O binary $< $@
-stub.o: $(extra-y)
+obj-y := stub.o
+obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
+extra-$(efi) += buildid.o
nogcov-$(efi) += stub.o
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 7676de9..b0b1c9b 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -270,10 +270,10 @@ SECTIONS
.pad : {
. = ALIGN(MB(16));
} :text
-#else
- efi = .;
#endif
+ efi = DEFINED(efi) ? efi : .;
+
/* Sections to be discarded */
/DISCARD/ : {
*(.exit.text)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 3e5e4ab..df8c702 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1251,6 +1251,9 @@ void __init efi_init_memory(void)
} *extra, *extra_head = NULL;
#endif
+ if ( !efi_enabled(EFI_BOOT) )
+ return;
+
printk(XENLOG_INFO "EFI memory map:%s\n",
map_bs ? " (mapping BootServices)" : "");
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 8c44835..25323de 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -196,6 +196,9 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
{
unsigned int i, n;
+ if ( !efi_enabled(EFI_BOOT) )
+ return -ENOSYS;
+
switch ( idx )
{
case XEN_FW_EFI_VERSION:
@@ -331,6 +334,12 @@ int efi_runtime_call(struct xenpf_efi_runtime_call *op)
EFI_STATUS status = EFI_NOT_STARTED;
int rc = 0;
+ if ( !efi_enabled(EFI_BOOT) )
+ return -ENOSYS;
+
+ if ( !efi_enabled(EFI_RS) )
+ return -EOPNOTSUPP;
+
switch ( op->function )
{
case XEN_EFI_get_time:
--
1.7.10.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 51+ messages in thread* [PATCH v12 04/10] efi: create new early memory allocator
2017-01-20 1:34 [PATCH v12 00/10] x86: multiboot2 protocol support Daniel Kiper
` (2 preceding siblings ...)
2017-01-20 1:34 ` [PATCH v12 03/10] efi: build xen.gz with EFI code Daniel Kiper
@ 2017-01-20 1:34 ` Daniel Kiper
2017-01-20 1:34 ` [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
` (7 subsequent siblings)
11 siblings, 0 replies; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 1:34 UTC (permalink / raw)
To: xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, jbeulich, qiaowei.ren,
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 goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory from below of it. So, I tried to use mem_lower
address calculated by GRUB2. However, this solution 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... :-(((
Hence, we need new memory allocator for Xen EFI boot code which is
quite simple and generic and could be used by place_string() and
efi_arch_allocate_mmap_buffer(). I think about following 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
it in e820 memory map and map it in Xen virtual address space. This
means that the code referring to Xen command line, loaded modules and
EFI memory map, mostly in __start_xen(), will be further complicated
and diverge from legacy BIOS cases. Additionally, both former things
have to be placed below 4 GiB because their addresses are stored in
multiboot_info_t structure which has 32-bit relevant members.
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 may 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 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. However, during
discussion on Xen-devel Jan Beulich suggested that just in case we should
use 1 MiB memory pool like it is in original place_string() implementation.
So, let's use 1 MiB as it was proposed. 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().
2a) We could put memory pool into .bss.page_aligned section. Then allocate
memory chunks starting from the lowest address. After init phase we can
free unused portion of the memory pool as in case of .init.text or .init.data
sections. This way we do not need to allocate any space in image file and
freeing of unused area in the memory pool is very simple.
Now #2a solution is implemented because it is quite simple and requires
limited number of changes, especially in __start_xen().
New allocator is quite generic and can be used on ARM platforms too.
Though it is not enabled on ARM yet due to lack of some prereq.
List of them is placed before ebmalloc code.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
---
v11 - suggestions/fixes:
- #ifdef only EBMALLOC_SIZE from ebmalloc machinery
(suggested by Jan Beulich).
v10 - suggestions/fixes:
- remove unneeded ARM free_ebmalloc_unused_mem() stub.
v9 - suggestions/fixes:
- call free_ebmalloc_unused_mem() from efi_init_memory()
instead of xen/arch/arm/setup.c:init_done()
(suggested by Jan Beulich),
- improve comments.
v8 - suggestions/fixes:
- disable whole ebmalloc machinery on ARM platforms,
- add comment saying what should be done before
enabling ebmalloc on ARM,
(suggested by Julien Grall),
- move ebmalloc code before efi-boot.h inclusion and
remove unneeded forward declaration
(suggested by Jan Beulich),
- remove free_ebmalloc_unused_mem() call from
xen/arch/arm/setup.c:init_done()
(suggested by Julien Grall),
- improve commit message.
v7 - suggestions/fixes:
- enable most of ebmalloc machinery on ARM platforms
(suggested by Jan Beulich),
- remove unneeded cast
(suggested by Jan Beulich),
- wrap long line
(suggested by Jan Beulich),
- improve commit message.
v6 - suggestions/fixes:
- optimize ebmalloc allocator,
- move ebmalloc machinery to xen/common/efi/boot.c
(suggested by Jan Beulich),
- enforce PAGE_SIZE ebmalloc_mem alignment
(suggested by Jan Beulich),
- ebmalloc() must allocate properly
aligned memory regions
(suggested by Jan Beulich),
- printk() should use XENLOG_INFO
(suggested by Jan Beulich).
v4 - suggestions/fixes:
- move from #2 solution to #2a solution,
- improve commit message.
---
xen/arch/x86/efi/efi-boot.h | 11 +++-------
xen/arch/x86/setup.c | 3 +--
xen/common/efi/boot.c | 50 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 54 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 388c4ea..62c010e 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -114,7 +114,7 @@ static void __init relocate_trampoline(unsigned long phys)
static void __init place_string(u32 *addr, const char *s)
{
- static char *__initdata alloc = start;
+ char *alloc = NULL;
if ( s && *s )
{
@@ -122,7 +122,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 = ebmalloc(len1 + len2);
/*
* Insert new string before already existing one. This is needed
* for options passed on the command line to override options from
@@ -205,12 +205,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 ebmalloc(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 0ccef1d..d4b7d25 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1124,8 +1124,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(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);
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index df8c702..36dbb71 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -98,6 +98,54 @@ static CHAR16 __initdata newline[] = L"\r\n";
#define PrintStr(s) StdOut->OutputString(StdOut, s)
#define PrintErr(s) StdErr->OutputString(StdErr, s)
+#ifdef CONFIG_ARM
+/*
+ * TODO: Enable EFI boot allocator on ARM.
+ * This code can be common for x86 and ARM.
+ * Things TODO on ARM before enabling ebmalloc:
+ * - estimate required EBMALLOC_SIZE value,
+ * - where (in which section) ebmalloc_mem[] should live; if in
+ * .bss.page_aligned, as it is right now, then whole BSS zeroing
+ * have to be disabled in xen/arch/arm/arm64/head.S; though BSS
+ * should be initialized somehow before use of variables living there,
+ * - use ebmalloc() in ARM/common EFI boot code,
+ * - call free_ebmalloc_unused_mem() somewhere in init code.
+ */
+#define EBMALLOC_SIZE MB(0)
+#else
+#define EBMALLOC_SIZE MB(1)
+#endif
+
+static char __section(".bss.page_aligned") __aligned(PAGE_SIZE)
+ ebmalloc_mem[EBMALLOC_SIZE];
+static unsigned long __initdata ebmalloc_allocated;
+
+/* EFI boot allocator. */
+static void __init __maybe_unused *ebmalloc(size_t size)
+{
+ void *ptr = ebmalloc_mem + ebmalloc_allocated;
+
+ ebmalloc_allocated += (size + sizeof(void *) - 1) & ~(sizeof(void *) - 1);
+
+ if ( ebmalloc_allocated > sizeof(ebmalloc_mem) )
+ blexit(L"Out of static memory\r\n");
+
+ return ptr;
+}
+
+static void __init __maybe_unused free_ebmalloc_unused_mem(void)
+{
+ unsigned long start, end;
+
+ start = (unsigned long)ebmalloc_mem + PAGE_ALIGN(ebmalloc_allocated);
+ end = (unsigned long)ebmalloc_mem + sizeof(ebmalloc_mem);
+
+ destroy_xen_mappings(start, end);
+ init_xenheap_pages(__pa(start), __pa(end));
+
+ printk(XENLOG_INFO "Freed %lukB unused BSS memory\n", (end - start) >> 10);
+}
+
/*
* Include architecture specific implementation here, which references the
* static globals defined above.
@@ -1251,6 +1299,8 @@ void __init efi_init_memory(void)
} *extra, *extra_head = NULL;
#endif
+ free_ebmalloc_unused_mem();
+
if ( !efi_enabled(EFI_BOOT) )
return;
--
1.7.10.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 51+ messages in thread* [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
2017-01-20 1:34 [PATCH v12 00/10] x86: multiboot2 protocol support Daniel Kiper
` (3 preceding siblings ...)
2017-01-20 1:34 ` [PATCH v12 04/10] efi: create new early memory allocator Daniel Kiper
@ 2017-01-20 1:34 ` Daniel Kiper
2017-01-20 4:37 ` Doug Goldstein
` (3 more replies)
2017-01-20 1:34 ` [PATCH v12 06/10] x86: change default load address from 1 MiB to 2 MiB Daniel Kiper
` (6 subsequent siblings)
11 siblings, 4 replies; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 1:34 UTC (permalink / raw)
To: xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, jbeulich, qiaowei.ren,
gang.wei, fu.wei
This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
v12 - suggestions/fixes:
- rename __efi64_start to __efi64_mb2_start
(suggested by Andrew Cooper),
- use efi_arch_memory_setup() machinery as trampoline
et consortes main memory allocator
(suggested by Doug Goldstein),
- allocate space for mbi struct in efi_arch_memory_setup() too;
this thing was not taken into account in earlier releases,
- revert trampoline et consortes fallback memory allocator code
in efi_arch_process_memory_map() to current upstream state
(suggested by Doug Goldstein),
- further simplify efi_arch_pre_exit_boot() code,
- call efi_arch_memory_setup() from efi_multiboot2()
(suggested by Doug Goldstein),
- fix asembly call argument in xen/arch/x86/efi/stub.c
(suggested by Andrew Cooper),
- add ASSERT() for trampoline size
(suggested by Doug Goldstein),
- add KB() macro
(suggested by Doug Goldstein),
- improve comments
(suggested by Andrew Cooper and Doug Goldstein).
v10 - suggestions/fixes:
- replace ljmpl with lretq
(suggested by Andrew Cooper),
- introduce efi_platform to increase code readability
(suggested by Andrew Cooper).
v9 - suggestions/fixes:
- use .L labels instead of numeric ones in multiboot2 data scanning loops
(suggested by Jan Beulich).
v8 - suggestions/fixes:
- use __bss_start(%rip)/__bss_end(%rip) instead of
of .startof.(.bss)(%rip)/$.sizeof.(.bss) because
latter is not tested extensively in different
built environments yet
(suggested by Andrew Cooper),
- fix multiboot2 data scanning loop in x86_32 code
(suggested by Jan Beulich),
- add check for extra mem for mbi data if Xen is loaded
via multiboot2 protocol on EFI platform
(suggested by Jan Beulich),
- improve comments
(suggested by Jan Beulich).
v7 - suggestions/fixes:
- do not allocate twice memory for trampoline if we were
loaded via multiboot2 protocol on EFI platform,
- wrap long line
(suggested by Jan Beulich),
- improve comments
(suggested by Jan Beulich).
v6 - suggestions/fixes:
- improve label names in assembly
error printing code
(suggested by Jan Beulich),
- improve comments
(suggested by Jan Beulich),
- various minor cleanups and fixes
(suggested by Jan Beulich).
v4 - suggestions/fixes:
- remove redundant BSS alignment,
- update BSS alignment check,
- use __set_bit() instead of set_bit() if possible
(suggested by Jan Beulich),
- call efi_arch_cpu() from efi_multiboot2()
even if the same work is done later in
other place right now
(suggested by Jan Beulich),
- xen/arch/x86/efi/stub.c:efi_multiboot2()
fail properly on EFI platforms,
- do not read data beyond the end of multiboot2
information in xen/arch/x86/boot/head.S
(suggested by Jan Beulich),
- use 32-bit registers in x86_64 code if possible
(suggested by Jan Beulich),
- multiboot2 information address is 64-bit
in x86_64 code, so, treat it is as is
(suggested by Jan Beulich),
- use cmovcc if possible,
- leave only one space between rep and stosq
(suggested by Jan Beulich),
- improve error handling,
- improve early error messages,
(suggested by Jan Beulich),
- improve early error messages printing code,
- improve label names
(suggested by Jan Beulich),
- improve comments
(suggested by Jan Beulich),
- various minor cleanups.
v3 - suggestions/fixes:
- take into account alignment when skipping multiboot2 fixed part
(suggested by Konrad Rzeszutek Wilk),
- improve segment registers initialization
(suggested by Jan Beulich),
- improve comments
(suggested by Jan Beulich and Konrad Rzeszutek Wilk),
- improve commit message
(suggested by Jan Beulich).
v2 - suggestions/fixes:
- generate multiboot2 header using macros
(suggested by Jan Beulich),
- switch CPU to x86_32 mode before
jumping to 32-bit code
(suggested by Andrew Cooper),
- reduce code changes to increase patch readability
(suggested by Jan Beulich),
- improve comments
(suggested by Jan Beulich),
- ignore MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag on EFI platform
and find on my own multiboot2.mem_lower value,
- stop execution if EFI platform is detected
in legacy BIOS path.
---
xen/arch/x86/boot/head.S | 268 ++++++++++++++++++++++++++++++++++---
xen/arch/x86/efi/efi-boot.h | 61 ++++++++-
xen/arch/x86/efi/stub.c | 38 ++++++
xen/arch/x86/x86_64/asm-offsets.c | 2 +
xen/arch/x86/xen.lds.S | 7 +-
xen/common/efi/boot.c | 11 ++
xen/include/asm-x86/config.h | 5 +
xen/include/xen/config.h | 1 +
8 files changed, 366 insertions(+), 27 deletions(-)
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 84cf44d..b8f727a 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -89,6 +89,13 @@ multiboot2_header_start:
0, /* Number of the lines - no preference. */ \
0 /* Number of bits per pixel - no preference. */
+ /* Request that ExitBootServices() not be called. */
+ mb2ht_init MB2_HT(EFI_BS), MB2_HT(OPTIONAL)
+
+ /* EFI64 Multiboot2 entry point. */
+ mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
+ sym_phys(__efi64_mb2_start)
+
/* Multiboot2 header end tag. */
mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
.Lmultiboot2_header_end:
@@ -100,20 +107,48 @@ multiboot2_header_start:
gdt_boot_descr:
.word 6*8-1
.long sym_phys(trampoline_gdt)
+ .long 0 /* Needed for 64-bit lgdt */
+
+ .align 4
+vga_text_buffer:
+ .long 0xb8000
+
+efi_platform:
+ .byte 0
.Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
.Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
+.Lbad_ldr_nbs: .asciz "ERR: Bootloader shutdown EFI x64 boot services!"
+.Lbad_ldr_nst: .asciz "ERR: EFI SystemTable is not provided by bootloader!"
+.Lbad_ldr_nih: .asciz "ERR: EFI ImageHandle is not provided by bootloader!"
+.Lbad_efi_msg: .asciz "ERR: EFI IA-32 platforms are not supported!"
.section .init.text, "ax", @progbits
bad_cpu:
mov $(sym_phys(.Lbad_cpu_msg)),%esi # Error message
- jmp print_err
+ jmp .Lget_vtb
not_multiboot:
mov $(sym_phys(.Lbad_ldr_msg)),%esi # Error message
-print_err:
- mov $0xB8000,%edi # VGA framebuffer
-1: mov (%esi),%bl
+ jmp .Lget_vtb
+.Lmb2_no_st:
+ mov $(sym_phys(.Lbad_ldr_nst)),%esi # Error message
+ jmp .Lget_vtb
+.Lmb2_no_ih:
+ mov $(sym_phys(.Lbad_ldr_nih)),%esi # Error message
+ jmp .Lget_vtb
+.Lmb2_no_bs:
+ mov $(sym_phys(.Lbad_ldr_nbs)),%esi # Error message
+ xor %edi,%edi # No VGA text buffer
+ jmp .Lsend_chr
+.Lmb2_efi_ia_32:
+ mov $(sym_phys(.Lbad_efi_msg)),%esi # Error message
+ xor %edi,%edi # No VGA text buffer
+ jmp .Lsend_chr
+.Lget_vtb:
+ mov sym_phys(vga_text_buffer),%edi
+.Lsend_chr:
+ mov (%esi),%bl
test %bl,%bl # Terminate on '\0' sentinel
je .Lhalt
mov $0x3f8+5,%dx # UART Line Status Register
@@ -123,13 +158,186 @@ print_err:
mov $0x3f8+0,%dx # UART Transmit Holding Register
mov %bl,%al
out %al,%dx # Send a character over the serial line
- movsb # Write a character to the VGA framebuffer
+ test %edi,%edi # Is the VGA text buffer available?
+ jz .Lsend_chr
+ movsb # Write a character to the VGA text buffer
mov $7,%al
- stosb # Write an attribute to the VGA framebuffer
- jmp 1b
+ stosb # Write an attribute to the VGA text buffer
+ jmp .Lsend_chr
.Lhalt: hlt
jmp .Lhalt
+ .code64
+
+__efi64_mb2_start:
+ cld
+
+ /* VGA is not available on EFI platforms. */
+ movl $0,vga_text_buffer(%rip)
+
+ /* Check for Multiboot2 bootloader. */
+ cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
+ je .Lefi_multiboot2_proto
+
+ /* Jump to not_multiboot after switching CPU to x86_32 mode. */
+ lea not_multiboot(%rip),%edi
+ jmp x86_32_switch
+
+.Lefi_multiboot2_proto:
+ /* Zero EFI SystemTable and EFI ImageHandle addresses. */
+ xor %esi,%esi
+ xor %edi,%edi
+
+ /* Skip Multiboot2 information fixed part. */
+ lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
+ and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
+
+.Lefi_mb2_tsize:
+ /* Check Multiboot2 information total size. */
+ mov %ecx,%r8d
+ sub %ebx,%r8d
+ cmp %r8d,MB2_fixed_total_size(%rbx)
+ jbe run_bs
+
+ /* Are EFI boot services available? */
+ cmpl $MULTIBOOT2_TAG_TYPE_EFI_BS,MB2_tag_type(%rcx)
+ jne .Lefi_mb2_st
+
+ /* We are on EFI platform and EFI boot services are available. */
+ incb efi_platform(%rip)
+
+ /*
+ * Disable real mode and other legacy stuff which should not
+ * be run on EFI platforms.
+ */
+ incb skip_realmode(%rip)
+ jmp .Lefi_mb2_next_tag
+
+.Lefi_mb2_st:
+ /* Get EFI SystemTable address from Multiboot2 information. */
+ cmpl $MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%rcx)
+ cmove MB2_efi64_st(%rcx),%rsi
+ je .Lefi_mb2_next_tag
+
+ /* Get EFI ImageHandle address from Multiboot2 information. */
+ cmpl $MULTIBOOT2_TAG_TYPE_EFI64_IH,MB2_tag_type(%rcx)
+ cmove MB2_efi64_ih(%rcx),%rdi
+ je .Lefi_mb2_next_tag
+
+ /* Is it the end of Multiboot2 information? */
+ cmpl $MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%rcx)
+ je run_bs
+
+.Lefi_mb2_next_tag:
+ /* Go to next Multiboot2 information tag. */
+ add MB2_tag_size(%rcx),%ecx
+ add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
+ and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
+ jmp .Lefi_mb2_tsize
+
+run_bs:
+ /* Are EFI boot services available? */
+ cmpb $0,efi_platform(%rip)
+ jnz 0f
+
+ /* Jump to .Lmb2_no_bs after switching CPU to x86_32 mode. */
+ lea .Lmb2_no_bs(%rip),%edi
+ jmp x86_32_switch
+
+0:
+ /* Is EFI SystemTable address provided by boot loader? */
+ test %rsi,%rsi
+ jnz 1f
+
+ /* Jump to .Lmb2_no_st after switching CPU to x86_32 mode. */
+ lea .Lmb2_no_st(%rip),%edi
+ jmp x86_32_switch
+
+1:
+ /* Is EFI ImageHandle address provided by boot loader? */
+ test %rdi,%rdi
+ jnz 2f
+
+ /* Jump to .Lmb2_no_ih after switching CPU to x86_32 mode. */
+ lea .Lmb2_no_ih(%rip),%edi
+ jmp x86_32_switch
+
+2:
+ push %rax
+ push %rdi
+
+ /*
+ * Initialize BSS (no nasty surprises!).
+ * It must be done earlier than in BIOS case
+ * because efi_multiboot2() touches it.
+ */
+ lea __bss_start(%rip),%edi
+ lea __bss_end(%rip),%ecx
+ sub %edi,%ecx
+ shr $3,%ecx
+ xor %eax,%eax
+ rep stosq
+
+ pop %rdi
+
+ /*
+ * efi_multiboot2() is called according to System V AMD64 ABI:
+ * - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
+ * - OUT: %rax - highest allocated memory address below 1 MiB;
+ * memory below this address is used for trampoline
+ * stack, trampoline itself and as a storage for
+ * mbi struct created in reloc().
+ *
+ * MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag is not provided
+ * on EFI platforms. Hence, it could not be used like
+ * on legacy BIOS platforms.
+ */
+ call efi_multiboot2
+
+ /* Convert memory address to bytes/16 and store it in safe place. */
+ shr $4,%eax
+ mov %eax,%ecx
+
+ pop %rax
+
+ /* Jump to trampoline_setup after switching CPU to x86_32 mode. */
+ lea trampoline_setup(%rip),%edi
+
+x86_32_switch:
+ cli
+
+ /* Initialize GDTR. */
+ lgdt gdt_boot_descr(%rip)
+
+ /* Reload code selector. */
+ pushq $BOOT_CS32
+ lea cs32_switch(%rip),%edx
+ push %rdx
+ lretq
+
+ .code32
+
+cs32_switch:
+ /* Initialize basic data segments. */
+ mov $BOOT_DS,%edx
+ mov %edx,%ds
+ mov %edx,%es
+ mov %edx,%ss
+ /* %esp is initialized later. */
+
+ /* Load null descriptor to unused segment registers. */
+ xor %edx,%edx
+ mov %edx,%fs
+ mov %edx,%gs
+
+ /* Disable paging. */
+ mov %cr0,%edx
+ and $(~X86_CR0_PG),%edx
+ mov %edx,%cr0
+
+ /* Jump to earlier loaded address. */
+ jmp *%edi
+
__start:
cld
cli
@@ -157,7 +365,7 @@ __start:
/* Not available? BDA value will be fine. */
cmovnz MB_mem_lower(%ebx),%edx
- jmp trampoline_setup
+ jmp trampoline_bios_setup
.Lmultiboot2_proto:
/* Skip Multiboot2 information fixed part. */
@@ -169,24 +377,33 @@ __start:
mov %ecx,%edi
sub %ebx,%edi
cmp %edi,MB2_fixed_total_size(%ebx)
- jbe trampoline_setup
+ jbe trampoline_bios_setup
/* Get mem_lower from Multiboot2 information. */
cmpl $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
cmove MB2_mem_lower(%ecx),%edx
- je trampoline_setup
+ je .Lmb2_next_tag
+
+ /* EFI IA-32 platforms are not supported. */
+ cmpl $MULTIBOOT2_TAG_TYPE_EFI32,MB2_tag_type(%ecx)
+ je .Lmb2_efi_ia_32
+
+ /* Bootloader shutdown EFI x64 boot services. */
+ cmpl $MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%ecx)
+ je .Lmb2_no_bs
/* Is it the end of Multiboot2 information? */
cmpl $MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%ecx)
- je trampoline_setup
+ je trampoline_bios_setup
+.Lmb2_next_tag:
/* 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 .Lmb2_tsize
-trampoline_setup:
+trampoline_bios_setup:
/* Set up trampoline segment 64k below EBDA */
movzwl 0x40e,%ecx /* EBDA segment */
cmp $0xa000,%ecx /* sanity check (high) */
@@ -202,16 +419,19 @@ 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 */
- sub $0x1000,%ecx
+ /* Reserve memory for the trampoline. */
+ sub $((MB_TRAMPOLINE_SIZE+MB_TRAMPOLINE_STACK_SIZE)>>4),%ecx
/* From arch/x86/smpboot.c: start_eip had better be page-aligned! */
xor %cl, %cl
+
+trampoline_setup:
+ /* Save trampoline address for later use. */
shl $4, %ecx
mov %ecx,sym_phys(trampoline_phys)
@@ -223,7 +443,14 @@ trampoline_setup:
call reloc
mov %eax,sym_phys(multiboot_ptr)
- /* Initialize BSS (no nasty surprises!) */
+ /*
+ * Do not zero BSS on EFI platform here.
+ * It was initialized earlier.
+ */
+ cmpb $0,sym_phys(efi_platform)
+ jnz 1f
+
+ /* Initialize BSS (no nasty surprises!). */
mov $sym_phys(__bss_start),%edi
mov $sym_phys(__bss_end),%ecx
sub %edi,%ecx
@@ -231,6 +458,7 @@ trampoline_setup:
shr $2,%ecx
rep stosl
+1:
/* Interrogate CPU extended features via CPUID. */
mov $0x80000000,%eax
cpuid
@@ -282,6 +510,10 @@ trampoline_setup:
cmp $sym_phys(__trampoline_seg_stop),%edi
jb 1b
+ /* Do not parse command line on EFI platform here. */
+ cmpb $0,sym_phys(efi_platform)
+ jnz 1f
+
/* Bail if there is no command line to parse. */
mov sym_phys(multiboot_ptr),%ebx
testl $MBI_CMDLINE,MB_flags(%ebx)
@@ -292,9 +524,9 @@ trampoline_setup:
call cmdline_parse_early
1:
- /* Switch to low-memory stack. */
+ /* Switch to low-memory stack which lives at the end of trampoline region. */
mov sym_phys(trampoline_phys),%edi
- lea 0x10000(%edi),%esp
+ lea MB_TRAMPOLINE_SIZE+MB_TRAMPOLINE_STACK_SIZE(%edi),%esp
lea trampoline_boot_cpu_entry-trampoline_start(%edi),%eax
pushl $BOOT_CS32
push %eax
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 62c010e..c1285ad 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -100,6 +100,9 @@ static void __init relocate_trampoline(unsigned long phys)
{
const s32 *trampoline_ptr;
+ if ( !efi_enabled(EFI_LOADER) || trampoline_phys )
+ return;
+
trampoline_phys = phys;
/* Apply relocations to trampoline. */
for ( trampoline_ptr = __trampoline_rel_start;
@@ -210,12 +213,10 @@ static void *__init efi_arch_allocate_mmap_buffer(UINTN map_size)
static void __init efi_arch_pre_exit_boot(void)
{
- if ( !trampoline_phys )
- {
- if ( !cfg.addr )
- blexit(L"No memory for trampoline");
- relocate_trampoline(cfg.addr);
- }
+ if ( !cfg.addr )
+ blexit(L"No memory for trampoline");
+
+ relocate_trampoline(cfg.addr);
}
static void __init noreturn efi_arch_post_exit_boot(void)
@@ -550,7 +551,12 @@ static void __init efi_arch_memory_setup(void)
/* Allocate space for trampoline (in first Mb). */
cfg.addr = 0x100000;
- cfg.size = trampoline_end - trampoline_start;
+
+ if ( efi_enabled(EFI_LOADER) )
+ cfg.size = trampoline_end - trampoline_start;
+ else
+ cfg.size = MB_TRAMPOLINE_SIZE + MB_TRAMPOLINE_STACK_SIZE + MBI_SIZE;
+
status = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
PFN_UP(cfg.size), &cfg.addr);
if ( status == EFI_SUCCESS )
@@ -561,6 +567,9 @@ static void __init efi_arch_memory_setup(void)
PrintStr(L"Trampoline space cannot be allocated; will try fallback.\r\n");
}
+ if ( !efi_enabled(EFI_LOADER) )
+ return;
+
/* Initialise L2 identity-map and boot-map page table entries (16MB). */
for ( i = 0; i < 8; ++i )
{
@@ -653,6 +662,44 @@ static bool_t __init efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable)
static void efi_arch_flush_dcache_area(const void *vaddr, UINTN size) { }
+paddr_t __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
+{
+ EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
+ UINTN cols, gop_mode = ~0, rows;
+
+ __set_bit(EFI_BOOT, &efi_flags);
+ __set_bit(EFI_RS, &efi_flags);
+
+ 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();
+
+ if ( gop )
+ gop_mode = efi_find_gop_mode(gop, 0, 0, 0);
+
+ efi_arch_edd();
+ efi_arch_cpu();
+
+ efi_tables();
+ setup_efi_pci();
+ efi_variables();
+ efi_arch_memory_setup();
+
+ if ( gop )
+ efi_set_gop_mode(gop, gop_mode);
+
+ efi_exit_boot(ImageHandle, SystemTable);
+
+ /* Return highest allocated memory address below 1 MiB. */
+ return cfg.addr + cfg.size;
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
index 4158124..b81adc0 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -3,6 +3,44 @@
#include <xen/init.h>
#include <xen/lib.h>
#include <asm/page.h>
+#include <asm/efibind.h>
+#include <efi/efidef.h>
+#include <efi/eficapsule.h>
+#include <efi/eficon.h>
+#include <efi/efidevp.h>
+#include <efi/efiapi.h>
+
+/*
+ * Here we are in EFI stub. EFI calls are not supported due to lack
+ * of relevant functionality in compiler and/or linker.
+ *
+ * efi_multiboot2() is an exception. Please look below for more details.
+ */
+
+paddr_t __init noreturn efi_multiboot2(EFI_HANDLE ImageHandle,
+ EFI_SYSTEM_TABLE *SystemTable)
+{
+ CHAR16 *err = L"Xen does not have EFI code build in!!!\r\nSystem halted!!!\r\n";
+ SIMPLE_TEXT_OUTPUT_INTERFACE *StdErr;
+
+ StdErr = SystemTable->StdErr ? SystemTable->StdErr : SystemTable->ConOut;
+
+ /*
+ * Print error message and halt the system.
+ *
+ * We have to open code MS x64 calling convention
+ * in assembly because here this convention may
+ * not be directly supported by C compiler.
+ */
+ asm volatile(
+ " call *%2 \n"
+ "0: hlt \n"
+ " jmp 0b \n"
+ : "+c" (StdErr), "+d" (err) : "g" (StdErr->OutputString)
+ : "rax", "r8", "r9", "r10", "r11", "memory");
+
+ unreachable();
+}
bool efi_enabled(unsigned int feature)
{
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index 92f5d81..f135654 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -175,6 +175,8 @@ void __dummy__(void)
OFFSET(MB2_tag_type, multiboot2_tag_t, type);
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);
BLANK();
OFFSET(DOMAIN_vm_assist, struct domain, vm_assist);
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index b0b1c9b..3a02b2b 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -331,5 +331,8 @@ ASSERT(IS_ALIGNED(__init_end, PAGE_SIZE), "__init_end misaligned")
ASSERT(IS_ALIGNED(trampoline_start, 4), "trampoline_start misaligned")
ASSERT(IS_ALIGNED(trampoline_end, 4), "trampoline_end misaligned")
-ASSERT(IS_ALIGNED(__bss_start, 4), "__bss_start misaligned")
-ASSERT(IS_ALIGNED(__bss_end, 4), "__bss_end misaligned")
+ASSERT(IS_ALIGNED(__bss_start, 8), "__bss_start misaligned")
+ASSERT(IS_ALIGNED(__bss_end, 8), "__bss_end misaligned")
+
+ASSERT((trampoline_end - trampoline_start) < MB_TRAMPOLINE_SIZE,
+ "not enough room for trampoline")
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 36dbb71..b6cbdad 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -79,6 +79,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 UINT32 __initdata efi_bs_revision;
static EFI_HANDLE __initdata efi_ih;
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 6fd84e7..a86ea12 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -73,6 +73,11 @@
#define STACK_ORDER 3
#define STACK_SIZE (PAGE_SIZE << STACK_ORDER)
+#define MB_TRAMPOLINE_STACK_SIZE PAGE_SIZE
+#define MB_TRAMPOLINE_SIZE (KB(64) - MB_TRAMPOLINE_STACK_SIZE)
+
+#define MBI_SIZE (2 * PAGE_SIZE)
+
/* Primary stack is restricted to 8kB by guard pages. */
#define PRIMARY_STACK_SIZE 8192
diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
index 473c5e8..04e4da5 100644
--- a/xen/include/xen/config.h
+++ b/xen/include/xen/config.h
@@ -70,6 +70,7 @@
#define __force
#define __bitwise
+#define KB(_kb) (_AC(_kb, ULL) << 10)
#define MB(_mb) (_AC(_mb, ULL) << 20)
#define GB(_gb) (_AC(_gb, ULL) << 30)
--
1.7.10.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 51+ messages in thread* Re: [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
2017-01-20 1:34 ` [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
@ 2017-01-20 4:37 ` Doug Goldstein
2017-01-20 9:46 ` Jan Beulich
` (2 subsequent siblings)
3 siblings, 0 replies; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 4:37 UTC (permalink / raw)
To: Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 1315 bytes --]
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 84cf44d..b8f727a 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> -2: /* Reserve 64kb for the trampoline */
> - sub $0x1000,%ecx
> + /* Reserve memory for the trampoline. */
/* Reserve memory for the trampoline and the low memory stack */
> + sub $((MB_TRAMPOLINE_SIZE+MB_TRAMPOLINE_STACK_SIZE)>>4),%ecx
>
> /* From arch/x86/smpboot.c: start_eip had better be page-aligned! */
> xor %cl, %cl
> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> index 62c010e..c1285ad 100644
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -550,7 +551,12 @@ static void __init efi_arch_memory_setup(void)
>
> /* Allocate space for trampoline (in first Mb). */
> cfg.addr = 0x100000;
> - cfg.size = trampoline_end - trampoline_start;
> +
> + if ( efi_enabled(EFI_LOADER) )
> + cfg.size = trampoline_end - trampoline_start;
> + else
> + cfg.size = MB_TRAMPOLINE_SIZE + MB_TRAMPOLINE_STACK_SIZE + MBI_SIZE;
Why MBI_SIZE? I don't see that being copied in that region or living there?
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
2017-01-20 1:34 ` [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
2017-01-20 4:37 ` Doug Goldstein
@ 2017-01-20 9:46 ` Jan Beulich
2017-01-20 11:43 ` Daniel Kiper
2017-01-20 19:04 ` Doug Goldstein
2017-01-20 19:34 ` Doug Goldstein
3 siblings, 1 reply; 51+ messages in thread
From: Jan Beulich @ 2017-01-20 9:46 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, xen-devel, qiaowei.ren,
gang.wei, fu.wei
>>> On 20.01.17 at 02:34, <daniel.kiper@oracle.com> wrote:
> @@ -100,20 +107,48 @@ multiboot2_header_start:
> gdt_boot_descr:
> .word 6*8-1
> .long sym_phys(trampoline_gdt)
> + .long 0 /* Needed for 64-bit lgdt */
> +
> + .align 4
> +vga_text_buffer:
> + .long 0xb8000
> +
> +efi_platform:
> + .byte 0
You mean to modify these fields, but you add them to a r/o section.
> +.Lefi_multiboot2_proto:
> + /* Zero EFI SystemTable and EFI ImageHandle addresses. */
> + xor %esi,%esi
> + xor %edi,%edi
> +
> + /* Skip Multiboot2 information fixed part. */
> + lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
In an earlier reply to Andrew's inquiry regarding the possible
truncation here you said that grub can be made obey to such a
load restriction. None of the tags added here or in patch 2
appear to have such an effect, so would you please clarify how
the address restriction is being enforced?
> + and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +
> +.Lefi_mb2_tsize:
> + /* Check Multiboot2 information total size. */
> + mov %ecx,%r8d
> + sub %ebx,%r8d
> + cmp %r8d,MB2_fixed_total_size(%rbx)
> + jbe run_bs
> +
> + /* Are EFI boot services available? */
> + cmpl $MULTIBOOT2_TAG_TYPE_EFI_BS,MB2_tag_type(%rcx)
> + jne .Lefi_mb2_st
> +
> + /* We are on EFI platform and EFI boot services are available. */
> + incb efi_platform(%rip)
> +
> + /*
> + * Disable real mode and other legacy stuff which should not
> + * be run on EFI platforms.
> + */
> + incb skip_realmode(%rip)
> + jmp .Lefi_mb2_next_tag
> +
> +.Lefi_mb2_st:
> + /* Get EFI SystemTable address from Multiboot2 information. */
> + cmpl $MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%rcx)
> + cmove MB2_efi64_st(%rcx),%rsi
> + je .Lefi_mb2_next_tag
> +
> + /* Get EFI ImageHandle address from Multiboot2 information. */
> + cmpl $MULTIBOOT2_TAG_TYPE_EFI64_IH,MB2_tag_type(%rcx)
> + cmove MB2_efi64_ih(%rcx),%rdi
> + je .Lefi_mb2_next_tag
> +
> + /* Is it the end of Multiboot2 information? */
> + cmpl $MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%rcx)
> + je run_bs
> +
> +.Lefi_mb2_next_tag:
> + /* Go to next Multiboot2 information tag. */
> + add MB2_tag_size(%rcx),%ecx
> + add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> + and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> + jmp .Lefi_mb2_tsize
> +
> +run_bs:
.Lrun_bs:
> + /* Are EFI boot services available? */
> + cmpb $0,efi_platform(%rip)
> + jnz 0f
> +
> + /* Jump to .Lmb2_no_bs after switching CPU to x86_32 mode. */
> + lea .Lmb2_no_bs(%rip),%edi
> + jmp x86_32_switch
> +0:
I realize you need to avoid clobbering %rdi in the non-error case,
but the register choice seems sub-optimal: If you used a register
which you can clobber here (e.g. %edx as it seems, using %edi in
its place at x86_32_switch and cs32_switch), you could simplify
this to
cmpb ...
lea ...
je x86_32_switch
at once avoiding all the numeric labels here.
> +2:
> + push %rax
> + push %rdi
> +
> + /*
> + * Initialize BSS (no nasty surprises!).
> + * It must be done earlier than in BIOS case
> + * because efi_multiboot2() touches it.
> + */
> + lea __bss_start(%rip),%edi
> + lea __bss_end(%rip),%ecx
> + sub %edi,%ecx
> + shr $3,%ecx
> + xor %eax,%eax
> + rep stosq
> +
> + pop %rdi
> +
> + /*
> + * efi_multiboot2() is called according to System V AMD64 ABI:
> + * - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> + * - OUT: %rax - highest allocated memory address below 1 MiB;
> + * memory below this address is used for trampoline
> + * stack, trampoline itself and as a storage for
> + * mbi struct created in reloc().
> + *
> + * MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag is not provided
> + * on EFI platforms. Hence, it could not be used like
> + * on legacy BIOS platforms.
> + */
> + call efi_multiboot2
Now that we had a need for commit f6b7fedc89 ("x86/EFI: meet
further spec requirements for runtime calls") I'm worried about stack
alignment here. Does GrUB call or jmp to our entry point (and is that
firmly specified to be the case)? Perhaps it would be a good idea to
align the stack earlier on in any case. Or if not (and if alignment at
this call is ABI conforming), a comment should be left here to warn
people of future modifications to the amount of items pushed onto /
popped off the stack.
> +trampoline_setup:
> + /* Save trampoline address for later use. */
> shl $4, %ecx
> mov %ecx,sym_phys(trampoline_phys)
I don't think this comment is very useful.
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -100,6 +100,9 @@ static void __init relocate_trampoline(unsigned long phys)
> {
> const s32 *trampoline_ptr;
>
> + if ( !efi_enabled(EFI_LOADER) || trampoline_phys )
> + return;
> +
> trampoline_phys = phys;
> /* Apply relocations to trampoline. */
> for ( trampoline_ptr = __trampoline_rel_start;
> @@ -210,12 +213,10 @@ static void *__init efi_arch_allocate_mmap_buffer(UINTN map_size)
>
> static void __init efi_arch_pre_exit_boot(void)
> {
> - if ( !trampoline_phys )
> - {
> - if ( !cfg.addr )
> - blexit(L"No memory for trampoline");
> - relocate_trampoline(cfg.addr);
> - }
> + if ( !cfg.addr )
> + blexit(L"No memory for trampoline");
> +
> + relocate_trampoline(cfg.addr);
> }
Why can't this function be left untouched, and the change to
relocate_trampoline() above also be reduced or even be removed
altogether?
> --- a/xen/arch/x86/efi/stub.c
> +++ b/xen/arch/x86/efi/stub.c
> @@ -3,6 +3,44 @@
> #include <xen/init.h>
> #include <xen/lib.h>
> #include <asm/page.h>
> +#include <asm/efibind.h>
> +#include <efi/efidef.h>
> +#include <efi/eficapsule.h>
> +#include <efi/eficon.h>
> +#include <efi/efidevp.h>
> +#include <efi/efiapi.h>
> +
> +/*
> + * Here we are in EFI stub. EFI calls are not supported due to lack
> + * of relevant functionality in compiler and/or linker.
> + *
> + * efi_multiboot2() is an exception. Please look below for more details.
> + */
> +
> +paddr_t __init noreturn efi_multiboot2(EFI_HANDLE ImageHandle,
> + EFI_SYSTEM_TABLE *SystemTable)
> +{
> + CHAR16 *err = L"Xen does not have EFI code build in!!!\r\nSystem halted!!!\r\n";
static const CHAR16 __initconst err[]
And please reduce the number of exclamation marks.
> + SIMPLE_TEXT_OUTPUT_INTERFACE *StdErr;
> +
> + StdErr = SystemTable->StdErr ? SystemTable->StdErr : SystemTable->ConOut;
> +
> + /*
> + * Print error message and halt the system.
> + *
> + * We have to open code MS x64 calling convention
> + * in assembly because here this convention may
> + * not be directly supported by C compiler.
> + */
> + asm volatile(
> + " call *%2 \n"
> + "0: hlt \n"
> + " jmp 0b \n"
> + : "+c" (StdErr), "+d" (err) : "g" (StdErr->OutputString)
The "g" really wants to be "rm": While the kind of expression doesn't
really allow for an immediate, you still shouldn't give wrong examples
of constraints (with the * now properly added to the call operand, it
doesn't allow for an immediate anymore).
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -73,6 +73,11 @@
> #define STACK_ORDER 3
> #define STACK_SIZE (PAGE_SIZE << STACK_ORDER)
>
> +#define MB_TRAMPOLINE_STACK_SIZE PAGE_SIZE
> +#define MB_TRAMPOLINE_SIZE (KB(64) - MB_TRAMPOLINE_STACK_SIZE)
What's the reason for the MB_ prefixes here? The trampoline is
always the same size, isn't it? Nor am I convinced we really need
two defines - except in the link time assertion you always use
the sum of the two.
> +#define MBI_SIZE (2 * PAGE_SIZE)
On top of Doug's question - if it is needed at all, what does this
match up with, i.e. how come this is 2 pages (and not 1 or 3)?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
2017-01-20 9:46 ` Jan Beulich
@ 2017-01-20 11:43 ` Daniel Kiper
2017-01-20 12:40 ` Jan Beulich
0 siblings, 1 reply; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 11:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, xen-devel, qiaowei.ren,
gang.wei, fu.wei
On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote:
> >>> On 20.01.17 at 02:34, <daniel.kiper@oracle.com> wrote:
> > @@ -100,20 +107,48 @@ multiboot2_header_start:
> > gdt_boot_descr:
> > .word 6*8-1
> > .long sym_phys(trampoline_gdt)
> > + .long 0 /* Needed for 64-bit lgdt */
> > +
> > + .align 4
> > +vga_text_buffer:
> > + .long 0xb8000
> > +
> > +efi_platform:
> > + .byte 0
>
> You mean to modify these fields, but you add them to a r/o section.
Yep. So, I think that we should move them to .init.data. Is it OK for you?
> > +.Lefi_multiboot2_proto:
> > + /* Zero EFI SystemTable and EFI ImageHandle addresses. */
> > + xor %esi,%esi
> > + xor %edi,%edi
> > +
> > + /* Skip Multiboot2 information fixed part. */
> > + lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
>
> In an earlier reply to Andrew's inquiry regarding the possible
> truncation here you said that grub can be made obey to such a
> load restriction. None of the tags added here or in patch 2
> appear to have such an effect, so would you please clarify how
> the address restriction is being enforced?
GRUB2 itself does allocations for all multiboot2 stuff always below 4 GiB.
So, there is no need for extra tags.
Additionally, multiboot2 spec says this:
The bootloader must not load any part of the kernel, the modules, the Multiboot2
information structure, etc. higher than 4 GiB - 1. This requirement is put in
force because most of currently specified tags supports 32-bit addresses only.
Additionally, some kernels, even if they run on EFI 64-bit platform, still
execute some parts of its initialization code in 32-bit mode.
[...]
> > +.Lefi_mb2_next_tag:
> > + /* Go to next Multiboot2 information tag. */
> > + add MB2_tag_size(%rcx),%ecx
> > + add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > + and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > + jmp .Lefi_mb2_tsize
> > +
> > +run_bs:
>
> .Lrun_bs:
OK.
> > + /* Are EFI boot services available? */
> > + cmpb $0,efi_platform(%rip)
> > + jnz 0f
> > +
> > + /* Jump to .Lmb2_no_bs after switching CPU to x86_32 mode. */
> > + lea .Lmb2_no_bs(%rip),%edi
> > + jmp x86_32_switch
> > +0:
>
> I realize you need to avoid clobbering %rdi in the non-error case,
> but the register choice seems sub-optimal: If you used a register
> which you can clobber here (e.g. %edx as it seems, using %edi in
> its place at x86_32_switch and cs32_switch), you could simplify
> this to
>
> cmpb ...
> lea ...
> je x86_32_switch
>
> at once avoiding all the numeric labels here.
If you do not care that it will be always loaded then OK. However, I think
that %r15d is a bit better here because if we need to add another argument
to efi_multiboot2() and we use %edx then we must change code in more places.
Of course we should do "mov %r15d,%edi" after x86_32_switch label then.
> > +2:
> > + push %rax
> > + push %rdi
> > +
> > + /*
> > + * Initialize BSS (no nasty surprises!).
> > + * It must be done earlier than in BIOS case
> > + * because efi_multiboot2() touches it.
> > + */
> > + lea __bss_start(%rip),%edi
> > + lea __bss_end(%rip),%ecx
> > + sub %edi,%ecx
> > + shr $3,%ecx
> > + xor %eax,%eax
> > + rep stosq
> > +
> > + pop %rdi
> > +
> > + /*
> > + * efi_multiboot2() is called according to System V AMD64 ABI:
> > + * - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> > + * - OUT: %rax - highest allocated memory address below 1 MiB;
> > + * memory below this address is used for trampoline
> > + * stack, trampoline itself and as a storage for
> > + * mbi struct created in reloc().
> > + *
> > + * MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag is not provided
> > + * on EFI platforms. Hence, it could not be used like
> > + * on legacy BIOS platforms.
> > + */
> > + call efi_multiboot2
>
> Now that we had a need for commit f6b7fedc89 ("x86/EFI: meet
> further spec requirements for runtime calls") I'm worried about stack
> alignment here. Does GrUB call or jmp to our entry point (and is that
> firmly specified to be the case)? Perhaps it would be a good idea to
> align the stack earlier on in any case. Or if not (and if alignment at
> this call is ABI conforming), a comment should be left here to warn
> people of future modifications to the amount of items pushed onto /
> popped off the stack.
Multiboot2 spec requires that stack, among others, is passed to loaded
image according to UEFI spec. Though, IIRC, there are no extra stack checks
there. Maybe we should add something to GRUB2 if it does not exists.
> > +trampoline_setup:
> > + /* Save trampoline address for later use. */
> > shl $4, %ecx
> > mov %ecx,sym_phys(trampoline_phys)
>
> I don't think this comment is very useful.
I will drop it if you wish.
> > --- a/xen/arch/x86/efi/efi-boot.h
> > +++ b/xen/arch/x86/efi/efi-boot.h
> > @@ -100,6 +100,9 @@ static void __init relocate_trampoline(unsigned long phys)
> > {
> > const s32 *trampoline_ptr;
> >
> > + if ( !efi_enabled(EFI_LOADER) || trampoline_phys )
> > + return;
> > +
> > trampoline_phys = phys;
> > /* Apply relocations to trampoline. */
> > for ( trampoline_ptr = __trampoline_rel_start;
> > @@ -210,12 +213,10 @@ static void *__init efi_arch_allocate_mmap_buffer(UINTN map_size)
> >
> > static void __init efi_arch_pre_exit_boot(void)
> > {
> > - if ( !trampoline_phys )
> > - {
> > - if ( !cfg.addr )
> > - blexit(L"No memory for trampoline");
> > - relocate_trampoline(cfg.addr);
> > - }
> > + if ( !cfg.addr )
> > + blexit(L"No memory for trampoline");
> > +
> > + relocate_trampoline(cfg.addr);
> > }
>
> Why can't this function be left untouched, and the change to
> relocate_trampoline() above also be reduced or even be removed
> altogether?
There is pretty good chance that efi_arch_pre_exit_boot() can be left
untouched though relocate_trampoline() needs at least
if ( !efi_enabled(EFI_LOADER) )
return;
> > --- a/xen/arch/x86/efi/stub.c
> > +++ b/xen/arch/x86/efi/stub.c
> > @@ -3,6 +3,44 @@
> > #include <xen/init.h>
> > #include <xen/lib.h>
> > #include <asm/page.h>
> > +#include <asm/efibind.h>
> > +#include <efi/efidef.h>
> > +#include <efi/eficapsule.h>
> > +#include <efi/eficon.h>
> > +#include <efi/efidevp.h>
> > +#include <efi/efiapi.h>
> > +
> > +/*
> > + * Here we are in EFI stub. EFI calls are not supported due to lack
> > + * of relevant functionality in compiler and/or linker.
> > + *
> > + * efi_multiboot2() is an exception. Please look below for more details.
> > + */
> > +
> > +paddr_t __init noreturn efi_multiboot2(EFI_HANDLE ImageHandle,
> > + EFI_SYSTEM_TABLE *SystemTable)
> > +{
> > + CHAR16 *err = L"Xen does not have EFI code build in!!!\r\nSystem halted!!!\r\n";
>
> static const CHAR16 __initconst err[]
>
> And please reduce the number of exclamation marks.
OK.
> > + SIMPLE_TEXT_OUTPUT_INTERFACE *StdErr;
> > +
> > + StdErr = SystemTable->StdErr ? SystemTable->StdErr : SystemTable->ConOut;
> > +
> > + /*
> > + * Print error message and halt the system.
> > + *
> > + * We have to open code MS x64 calling convention
> > + * in assembly because here this convention may
> > + * not be directly supported by C compiler.
> > + */
> > + asm volatile(
> > + " call *%2 \n"
> > + "0: hlt \n"
> > + " jmp 0b \n"
> > + : "+c" (StdErr), "+d" (err) : "g" (StdErr->OutputString)
>
> The "g" really wants to be "rm": While the kind of expression doesn't
> really allow for an immediate, you still shouldn't give wrong examples
> of constraints (with the * now properly added to the call operand, it
> doesn't allow for an immediate anymore).
I was considering that change once but I was not sure. Though if you
think that it make sense I will do that.
> > --- a/xen/include/asm-x86/config.h
> > +++ b/xen/include/asm-x86/config.h
> > @@ -73,6 +73,11 @@
> > #define STACK_ORDER 3
> > #define STACK_SIZE (PAGE_SIZE << STACK_ORDER)
> >
> > +#define MB_TRAMPOLINE_STACK_SIZE PAGE_SIZE
> > +#define MB_TRAMPOLINE_SIZE (KB(64) - MB_TRAMPOLINE_STACK_SIZE)
>
> What's the reason for the MB_ prefixes here? The trampoline is
> always the same size, isn't it? Nor am I convinced we really need
Please take a look at efi_arch_memory_setup(). Amount of memory allocated
for trampoline and other stuff depends on boot loader type. So, when I use
"MB_" I would like underline that this is relevant for multiboot protocols.
Though I think that we can use the same size for all protocols. However,
I would not like to touch native EFI loader case.
> two defines - except in the link time assertion you always use
> the sum of the two.
>
> > +#define MBI_SIZE (2 * PAGE_SIZE)
>
> On top of Doug's question - if it is needed at all, what does this
Please look around reloc() call in xen/arch/x86/boot/head.S. You quickly
realize that there is following memory layout from top to bottom:
+------------------+
| TRAMPOLINE_STACK |
+------------------+
| TRAMPOLINE |
+------------------+
| mbi struct |
+------------------+
> match up with, i.e. how come this is 2 pages (and not 1 or 3)?
Just thought that 8 KiB will be sufficient for Xen/modules arguments,
memory map and other minor things.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
2017-01-20 11:43 ` Daniel Kiper
@ 2017-01-20 12:40 ` Jan Beulich
2017-01-20 13:46 ` Daniel Kiper
0 siblings, 1 reply; 51+ messages in thread
From: Jan Beulich @ 2017-01-20 12:40 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, xen-devel, qiaowei.ren,
gang.wei, fu.wei
>>> On 20.01.17 at 12:43, <daniel.kiper@oracle.com> wrote:
> On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote:
>> >>> On 20.01.17 at 02:34, <daniel.kiper@oracle.com> wrote:
>> > @@ -100,20 +107,48 @@ multiboot2_header_start:
>> > gdt_boot_descr:
>> > .word 6*8-1
>> > .long sym_phys(trampoline_gdt)
>> > + .long 0 /* Needed for 64-bit lgdt */
>> > +
>> > + .align 4
>> > +vga_text_buffer:
>> > + .long 0xb8000
>> > +
>> > +efi_platform:
>> > + .byte 0
>>
>> You mean to modify these fields, but you add them to a r/o section.
>
> Yep. So, I think that we should move them to .init.data. Is it OK for you?
That's what I'm asking for, yes.
>> > +.Lefi_multiboot2_proto:
>> > + /* Zero EFI SystemTable and EFI ImageHandle addresses. */
>> > + xor %esi,%esi
>> > + xor %edi,%edi
>> > +
>> > + /* Skip Multiboot2 information fixed part. */
>> > + lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
>>
>> In an earlier reply to Andrew's inquiry regarding the possible
>> truncation here you said that grub can be made obey to such a
>> load restriction. None of the tags added here or in patch 2
>> appear to have such an effect, so would you please clarify how
>> the address restriction is being enforced?
>
> GRUB2 itself does allocations for all multiboot2 stuff always below 4 GiB.
> So, there is no need for extra tags.
>
> Additionally, multiboot2 spec says this:
>
> The bootloader must not load any part of the kernel, the modules, the Multiboot2
> information structure, etc. higher than 4 GiB - 1. This requirement is put in
> force because most of currently specified tags supports 32-bit addresses only.
> Additionally, some kernels, even if they run on EFI 64-bit platform, still
> execute some parts of its initialization code in 32-bit mode.
Okay, that's good enough for now, even if it escapes me how that's
supposed to work on systems without any memory below 4Gb.
>> > + /* Are EFI boot services available? */
>> > + cmpb $0,efi_platform(%rip)
>> > + jnz 0f
>> > +
>> > + /* Jump to .Lmb2_no_bs after switching CPU to x86_32 mode. */
>> > + lea .Lmb2_no_bs(%rip),%edi
>> > + jmp x86_32_switch
>> > +0:
>>
>> I realize you need to avoid clobbering %rdi in the non-error case,
>> but the register choice seems sub-optimal: If you used a register
>> which you can clobber here (e.g. %edx as it seems, using %edi in
>> its place at x86_32_switch and cs32_switch), you could simplify
>> this to
>>
>> cmpb ...
>> lea ...
>> je x86_32_switch
>>
>> at once avoiding all the numeric labels here.
>
> If you do not care that it will be always loaded then OK.
That's okay, of course. The main thing is that we should prefer the
one branch variant over the two branches one.
> However, I think
> that %r15d is a bit better here because if we need to add another argument
> to efi_multiboot2() and we use %edx then we must change code in more places.
> Of course we should do "mov %r15d,%edi" after x86_32_switch label then.
As long as all affected code lives outside of the trampoline, using
any of the high 8 registers is certainly fine here.
>> > +2:
>> > + push %rax
>> > + push %rdi
>> > +
>> > + /*
>> > + * Initialize BSS (no nasty surprises!).
>> > + * It must be done earlier than in BIOS case
>> > + * because efi_multiboot2() touches it.
>> > + */
>> > + lea __bss_start(%rip),%edi
>> > + lea __bss_end(%rip),%ecx
>> > + sub %edi,%ecx
>> > + shr $3,%ecx
>> > + xor %eax,%eax
>> > + rep stosq
>> > +
>> > + pop %rdi
>> > +
>> > + /*
>> > + * efi_multiboot2() is called according to System V AMD64 ABI:
>> > + * - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
>> > + * - OUT: %rax - highest allocated memory address below 1 MiB;
>> > + * memory below this address is used for trampoline
>> > + * stack, trampoline itself and as a storage for
>> > + * mbi struct created in reloc().
>> > + *
>> > + * MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag is not provided
>> > + * on EFI platforms. Hence, it could not be used like
>> > + * on legacy BIOS platforms.
>> > + */
>> > + call efi_multiboot2
>>
>> Now that we had a need for commit f6b7fedc89 ("x86/EFI: meet
>> further spec requirements for runtime calls") I'm worried about stack
>> alignment here. Does GrUB call or jmp to our entry point (and is that
>> firmly specified to be the case)? Perhaps it would be a good idea to
>> align the stack earlier on in any case. Or if not (and if alignment at
>> this call is ABI conforming), a comment should be left here to warn
>> people of future modifications to the amount of items pushed onto /
>> popped off the stack.
>
> Multiboot2 spec requires that stack, among others, is passed to loaded
> image according to UEFI spec. Though, IIRC, there are no extra stack checks
> there. Maybe we should add something to GRUB2 if it does not exists.
That would imply they do a call (and not a jmp), which would make
the present code correct afaict. As said, imo there should still be a
warning added here, for anyone wanting to modify the stack layout.
>> > --- a/xen/arch/x86/efi/efi-boot.h
>> > +++ b/xen/arch/x86/efi/efi-boot.h
>> > @@ -100,6 +100,9 @@ static void __init relocate_trampoline(unsigned long phys)
>> > {
>> > const s32 *trampoline_ptr;
>> >
>> > + if ( !efi_enabled(EFI_LOADER) || trampoline_phys )
>> > + return;
>> > +
>> > trampoline_phys = phys;
>> > /* Apply relocations to trampoline. */
>> > for ( trampoline_ptr = __trampoline_rel_start;
>> > @@ -210,12 +213,10 @@ static void *__init efi_arch_allocate_mmap_buffer(UINTN map_size)
>> >
>> > static void __init efi_arch_pre_exit_boot(void)
>> > {
>> > - if ( !trampoline_phys )
>> > - {
>> > - if ( !cfg.addr )
>> > - blexit(L"No memory for trampoline");
>> > - relocate_trampoline(cfg.addr);
>> > - }
>> > + if ( !cfg.addr )
>> > + blexit(L"No memory for trampoline");
>> > +
>> > + relocate_trampoline(cfg.addr);
>> > }
>>
>> Why can't this function be left untouched, and the change to
>> relocate_trampoline() above also be reduced or even be removed
>> altogether?
>
> There is pretty good chance that efi_arch_pre_exit_boot() can be left
> untouched though relocate_trampoline() needs at least
>
> if ( !efi_enabled(EFI_LOADER) )
> return;
Right, hence the "reduced".
>> > + SIMPLE_TEXT_OUTPUT_INTERFACE *StdErr;
>> > +
>> > + StdErr = SystemTable->StdErr ? SystemTable->StdErr : SystemTable->ConOut;
>> > +
>> > + /*
>> > + * Print error message and halt the system.
>> > + *
>> > + * We have to open code MS x64 calling convention
>> > + * in assembly because here this convention may
>> > + * not be directly supported by C compiler.
>> > + */
>> > + asm volatile(
>> > + " call *%2 \n"
>> > + "0: hlt \n"
>> > + " jmp 0b \n"
>> > + : "+c" (StdErr), "+d" (err) : "g" (StdErr->OutputString)
>>
>> The "g" really wants to be "rm": While the kind of expression doesn't
>> really allow for an immediate, you still shouldn't give wrong examples
>> of constraints (with the * now properly added to the call operand, it
>> doesn't allow for an immediate anymore).
>
> I was considering that change once but I was not sure. Though if you
> think that it make sense I will do that.
Yes please.
>> > --- a/xen/include/asm-x86/config.h
>> > +++ b/xen/include/asm-x86/config.h
>> > @@ -73,6 +73,11 @@
>> > #define STACK_ORDER 3
>> > #define STACK_SIZE (PAGE_SIZE << STACK_ORDER)
>> >
>> > +#define MB_TRAMPOLINE_STACK_SIZE PAGE_SIZE
>> > +#define MB_TRAMPOLINE_SIZE (KB(64) - MB_TRAMPOLINE_STACK_SIZE)
>>
>> What's the reason for the MB_ prefixes here? The trampoline is
>> always the same size, isn't it? Nor am I convinced we really need
>
> Please take a look at efi_arch_memory_setup(). Amount of memory allocated
> for trampoline and other stuff depends on boot loader type. So, when I use
> "MB_" I would like underline that this is relevant for multiboot protocols.
> Though I think that we can use the same size for all protocols. However,
> I would not like to touch native EFI loader case.
You already don't touch it, and I see no reason why this should
change. Yet this is orthogonal to the naming of the constants here.
As said, the trampoline itself is always the same, and the stack
portion of it is simply unused in the native EFI loader case. Plus
MB_TRAMPOLINE_SIZE is in no way the size of the trampoline in the
first place. Perhaps TRAMPOLINE_SPACE (and then covering both
parts)?
>> two defines - except in the link time assertion you always use
>> the sum of the two.
>>
>> > +#define MBI_SIZE (2 * PAGE_SIZE)
>>
>> On top of Doug's question - if it is needed at all, what does this
>
> Please look around reloc() call in xen/arch/x86/boot/head.S. You quickly
> realize that there is following memory layout from top to bottom:
>
> +------------------+
> | TRAMPOLINE_STACK |
> +------------------+
> | TRAMPOLINE |
> +------------------+
> | mbi struct |
> +------------------+
>
>> match up with, i.e. how come this is 2 pages (and not 1 or 3)?
>
> Just thought that 8 KiB will be sufficient for Xen/modules arguments,
> memory map and other minor things.
Even with a couple of dozen modules passed? But the primary
question was left unanswered anyway: Does this need placing in
the low megabyte at all? And even if it does, especially if you
limit it to 8k, I don't see why it wouldn't fit inside the 64k
trampoline area.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
2017-01-20 12:40 ` Jan Beulich
@ 2017-01-20 13:46 ` Daniel Kiper
2017-01-20 14:10 ` Jan Beulich
0 siblings, 1 reply; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 13:46 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, xen-devel, qiaowei.ren,
gang.wei, fu.wei
On Fri, Jan 20, 2017 at 05:40:55AM -0700, Jan Beulich wrote:
> >>> On 20.01.17 at 12:43, <daniel.kiper@oracle.com> wrote:
> > On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote:
> >> >>> On 20.01.17 at 02:34, <daniel.kiper@oracle.com> wrote:
[...]
> >> > +.Lefi_multiboot2_proto:
> >> > + /* Zero EFI SystemTable and EFI ImageHandle addresses. */
> >> > + xor %esi,%esi
> >> > + xor %edi,%edi
> >> > +
> >> > + /* Skip Multiboot2 information fixed part. */
> >> > + lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
> >>
> >> In an earlier reply to Andrew's inquiry regarding the possible
> >> truncation here you said that grub can be made obey to such a
> >> load restriction. None of the tags added here or in patch 2
> >> appear to have such an effect, so would you please clarify how
> >> the address restriction is being enforced?
> >
> > GRUB2 itself does allocations for all multiboot2 stuff always below 4 GiB.
> > So, there is no need for extra tags.
> >
> > Additionally, multiboot2 spec says this:
> >
> > The bootloader must not load any part of the kernel, the modules, the Multiboot2
> > information structure, etc. higher than 4 GiB - 1. This requirement is put in
> > force because most of currently specified tags supports 32-bit addresses only.
> > Additionally, some kernels, even if they run on EFI 64-bit platform, still
> > execute some parts of its initialization code in 32-bit mode.
>
> Okay, that's good enough for now, even if it escapes me how that's
> supposed to work on systems without any memory below 4Gb.
If you wish I can add relevant comment somewhere. Anyway, if there is no
mem below 4 GiB at least, IIRC, GRUB2 will fail during image load. So,
no worry. At least right now.
[...]
> >> > + /*
> >> > + * efi_multiboot2() is called according to System V AMD64 ABI:
> >> > + * - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> >> > + * - OUT: %rax - highest allocated memory address below 1 MiB;
> >> > + * memory below this address is used for trampoline
> >> > + * stack, trampoline itself and as a storage for
> >> > + * mbi struct created in reloc().
> >> > + *
> >> > + * MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag is not provided
> >> > + * on EFI platforms. Hence, it could not be used like
> >> > + * on legacy BIOS platforms.
> >> > + */
> >> > + call efi_multiboot2
> >>
> >> Now that we had a need for commit f6b7fedc89 ("x86/EFI: meet
> >> further spec requirements for runtime calls") I'm worried about stack
> >> alignment here. Does GrUB call or jmp to our entry point (and is that
> >> firmly specified to be the case)? Perhaps it would be a good idea to
> >> align the stack earlier on in any case. Or if not (and if alignment at
> >> this call is ABI conforming), a comment should be left here to warn
> >> people of future modifications to the amount of items pushed onto /
> >> popped off the stack.
> >
> > Multiboot2 spec requires that stack, among others, is passed to loaded
> > image according to UEFI spec. Though, IIRC, there are no extra stack checks
> > there. Maybe we should add something to GRUB2 if it does not exists.
>
> That would imply they do a call (and not a jmp), which would make
> the present code correct afaict. As said, imo there should still be a
> warning added here, for anyone wanting to modify the stack layout.
Will do.
[...]
> >> > --- a/xen/include/asm-x86/config.h
> >> > +++ b/xen/include/asm-x86/config.h
> >> > @@ -73,6 +73,11 @@
> >> > #define STACK_ORDER 3
> >> > #define STACK_SIZE (PAGE_SIZE << STACK_ORDER)
> >> >
> >> > +#define MB_TRAMPOLINE_STACK_SIZE PAGE_SIZE
> >> > +#define MB_TRAMPOLINE_SIZE (KB(64) - MB_TRAMPOLINE_STACK_SIZE)
> >>
> >> What's the reason for the MB_ prefixes here? The trampoline is
> >> always the same size, isn't it? Nor am I convinced we really need
> >
> > Please take a look at efi_arch_memory_setup(). Amount of memory allocated
> > for trampoline and other stuff depends on boot loader type. So, when I use
> > "MB_" I would like underline that this is relevant for multiboot protocols.
> > Though I think that we can use the same size for all protocols. However,
> > I would not like to touch native EFI loader case.
>
> You already don't touch it, and I see no reason why this should
> change. Yet this is orthogonal to the naming of the constants here.
OK.
> As said, the trampoline itself is always the same, and the stack
Yep.
> portion of it is simply unused in the native EFI loader case. Plus
Hmmm... That is interesting why? I must take a look at trampoline code.
> MB_TRAMPOLINE_SIZE is in no way the size of the trampoline in the
> first place. Perhaps TRAMPOLINE_SPACE (and then covering both
> parts)?
So, I suppose that TRAMPOLINE_SPACE and TRAMPOLINE_STACK_SPACE is
OK for you? And I can agree that this is better naming.
> >> two defines - except in the link time assertion you always use
> >> the sum of the two.
> >>
> >> > +#define MBI_SIZE (2 * PAGE_SIZE)
> >>
> >> On top of Doug's question - if it is needed at all, what does this
> >
> > Please look around reloc() call in xen/arch/x86/boot/head.S. You quickly
> > realize that there is following memory layout from top to bottom:
> >
> > +------------------+
> > | TRAMPOLINE_STACK |
> > +------------------+
> > | TRAMPOLINE |
> > +------------------+
> > | mbi struct |
> > +------------------+
> >
> >> match up with, i.e. how come this is 2 pages (and not 1 or 3)?
> >
> > Just thought that 8 KiB will be sufficient for Xen/modules arguments,
> > memory map and other minor things.
>
> Even with a couple of dozen modules passed? But the primary
Why not? The biggest thing is memory map. The rest are mostly
command line strings and a few pointers. Modules itself live
in different memory regions.
> question was left unanswered anyway: Does this need placing in
> the low megabyte at all? And even if it does, especially if you
I do not think so. I do not expect that anything in trampoline code
touches it. So, we can put it anywhere below 4 GiB. However, then
we need an allocator to properly allocate mbi struct region. And
at this boot stage this is not an easy thing.
> limit it to 8k, I don't see why it wouldn't fit inside the 64k
> trampoline area.
If you wish why not. Though I think that we should use set of constants
here to avoid currently existing plain numbers mess in assembly. And
I have a feeling that this cleanup/fix should land into separate patch.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
2017-01-20 13:46 ` Daniel Kiper
@ 2017-01-20 14:10 ` Jan Beulich
2017-01-20 14:43 ` Daniel Kiper
0 siblings, 1 reply; 51+ messages in thread
From: Jan Beulich @ 2017-01-20 14:10 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, xen-devel, qiaowei.ren,
gang.wei, fu.wei
>>> On 20.01.17 at 14:46, <daniel.kiper@oracle.com> wrote:
> On Fri, Jan 20, 2017 at 05:40:55AM -0700, Jan Beulich wrote:
>> >>> On 20.01.17 at 12:43, <daniel.kiper@oracle.com> wrote:
>> > On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote:
>> >> >>> On 20.01.17 at 02:34, <daniel.kiper@oracle.com> wrote:
>> >> > --- a/xen/include/asm-x86/config.h
>> >> > +++ b/xen/include/asm-x86/config.h
>> >> > @@ -73,6 +73,11 @@
>> >> > #define STACK_ORDER 3
>> >> > #define STACK_SIZE (PAGE_SIZE << STACK_ORDER)
>> >> >
>> >> > +#define MB_TRAMPOLINE_STACK_SIZE PAGE_SIZE
>> >> > +#define MB_TRAMPOLINE_SIZE (KB(64) - MB_TRAMPOLINE_STACK_SIZE)
>> >>
>> >> What's the reason for the MB_ prefixes here? The trampoline is
>> >> always the same size, isn't it? Nor am I convinced we really need
>> >
>> > Please take a look at efi_arch_memory_setup(). Amount of memory allocated
>> > for trampoline and other stuff depends on boot loader type. So, when I use
>> > "MB_" I would like underline that this is relevant for multiboot protocols.
>> > Though I think that we can use the same size for all protocols. However,
>> > I would not like to touch native EFI loader case.
>>
>> You already don't touch it, and I see no reason why this should
>> change. Yet this is orthogonal to the naming of the constants here.
>
> OK.
>
>> As said, the trampoline itself is always the same, and the stack
>
> Yep.
>
>> portion of it is simply unused in the native EFI loader case. Plus
>
> Hmmm... That is interesting why? I must take a look at trampoline code.
It's a boot time only thing, and the boot path if different for
native EFI.
>> MB_TRAMPOLINE_SIZE is in no way the size of the trampoline in the
>> first place. Perhaps TRAMPOLINE_SPACE (and then covering both
>> parts)?
>
> So, I suppose that TRAMPOLINE_SPACE and TRAMPOLINE_STACK_SPACE is
> OK for you? And I can agree that this is better naming.
Again, I don't see why you would need TRAMPOLINE_STACK_SPACE.
>> >> two defines - except in the link time assertion you always use
>> >> the sum of the two.
>> >>
>> >> > +#define MBI_SIZE (2 * PAGE_SIZE)
>> >>
>> >> On top of Doug's question - if it is needed at all, what does this
>> >
>> > Please look around reloc() call in xen/arch/x86/boot/head.S. You quickly
>> > realize that there is following memory layout from top to bottom:
>> >
>> > +------------------+
>> > | TRAMPOLINE_STACK |
>> > +------------------+
>> > | TRAMPOLINE |
>> > +------------------+
>> > | mbi struct |
>> > +------------------+
>> >
>> >> match up with, i.e. how come this is 2 pages (and not 1 or 3)?
>> >
>> > Just thought that 8 KiB will be sufficient for Xen/modules arguments,
>> > memory map and other minor things.
>>
>> Even with a couple of dozen modules passed? But the primary
>
> Why not? The biggest thing is memory map. The rest are mostly
> command line strings and a few pointers. Modules itself live
> in different memory regions.
Command line string may get lengthy.
>> question was left unanswered anyway: Does this need placing in
>> the low megabyte at all? And even if it does, especially if you
>
> I do not think so. I do not expect that anything in trampoline code
> touches it. So, we can put it anywhere below 4 GiB. However, then
> we need an allocator to properly allocate mbi struct region. And
> at this boot stage this is not an easy thing.
Depending for how long you need that data to stay around, there
may be places to put it without much risk of overflowing anything.
>> limit it to 8k, I don't see why it wouldn't fit inside the 64k
>> trampoline area.
>
> If you wish why not. Though I think that we should use set of constants
> here to avoid currently existing plain numbers mess in assembly. And
> I have a feeling that this cleanup/fix should land into separate patch.
Constants - sure. Separate patch - fine with me.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
2017-01-20 14:10 ` Jan Beulich
@ 2017-01-20 14:43 ` Daniel Kiper
2017-01-20 15:23 ` Jan Beulich
0 siblings, 1 reply; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 14:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, xen-devel, qiaowei.ren,
gang.wei, fu.wei
On Fri, Jan 20, 2017 at 07:10:32AM -0700, Jan Beulich wrote:
> >>> On 20.01.17 at 14:46, <daniel.kiper@oracle.com> wrote:
> > On Fri, Jan 20, 2017 at 05:40:55AM -0700, Jan Beulich wrote:
> >> >>> On 20.01.17 at 12:43, <daniel.kiper@oracle.com> wrote:
> >> > On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote:
> >> >> >>> On 20.01.17 at 02:34, <daniel.kiper@oracle.com> wrote:
> >> MB_TRAMPOLINE_SIZE is in no way the size of the trampoline in the
> >> first place. Perhaps TRAMPOLINE_SPACE (and then covering both
> >> parts)?
> >
> > So, I suppose that TRAMPOLINE_SPACE and TRAMPOLINE_STACK_SPACE is
> > OK for you? And I can agree that this is better naming.
>
> Again, I don't see why you would need TRAMPOLINE_STACK_SPACE.
If we use TRAMPOLINE_SPACE only for both trampoline and its stack
then ASSERT() is not very reliable. There is chance that trampoline
code will fill all space specified in TRAMPOLINE_SPACE and then there
will be no space for stack at all. However, I can agree that chance
is small if we assume 64 KiB space for trampoline and trampoline size
is about 10 KiB right now.
> >> >> two defines - except in the link time assertion you always use
> >> >> the sum of the two.
> >> >>
> >> >> > +#define MBI_SIZE (2 * PAGE_SIZE)
> >> >>
> >> >> On top of Doug's question - if it is needed at all, what does this
> >> >
> >> > Please look around reloc() call in xen/arch/x86/boot/head.S. You quickly
> >> > realize that there is following memory layout from top to bottom:
> >> >
> >> > +------------------+
> >> > | TRAMPOLINE_STACK |
> >> > +------------------+
> >> > | TRAMPOLINE |
> >> > +------------------+
> >> > | mbi struct |
> >> > +------------------+
> >> >
> >> >> match up with, i.e. how come this is 2 pages (and not 1 or 3)?
> >> >
> >> > Just thought that 8 KiB will be sufficient for Xen/modules arguments,
> >> > memory map and other minor things.
> >>
> >> Even with a couple of dozen modules passed? But the primary
> >
> > Why not? The biggest thing is memory map. The rest are mostly
> > command line strings and a few pointers. Modules itself live
> > in different memory regions.
>
> Command line string may get lengthy.
Do you think that we should have more than 8 KiB there? Anyway,
I am more afraid about memory map size here.
> >> question was left unanswered anyway: Does this need placing in
> >> the low megabyte at all? And even if it does, especially if you
> >
> > I do not think so. I do not expect that anything in trampoline code
> > touches it. So, we can put it anywhere below 4 GiB. However, then
> > we need an allocator to properly allocate mbi struct region. And
> > at this boot stage this is not an easy thing.
>
> Depending for how long you need that data to stay around, there
IIRC, it is needed only during init phase. Probably later it can be dropped.
> may be places to put it without much risk of overflowing anything.
I am not sure about which places do you think.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
2017-01-20 14:43 ` Daniel Kiper
@ 2017-01-20 15:23 ` Jan Beulich
0 siblings, 0 replies; 51+ messages in thread
From: Jan Beulich @ 2017-01-20 15:23 UTC (permalink / raw)
To: Daniel Kiper
Cc: Juergen Gross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, xen-devel, qiaowei.ren,
gang.wei, fu.wei
>>> On 20.01.17 at 15:43, <daniel.kiper@oracle.com> wrote:
> On Fri, Jan 20, 2017 at 07:10:32AM -0700, Jan Beulich wrote:
>> >>> On 20.01.17 at 14:46, <daniel.kiper@oracle.com> wrote:
>> > On Fri, Jan 20, 2017 at 05:40:55AM -0700, Jan Beulich wrote:
>> >> >>> On 20.01.17 at 12:43, <daniel.kiper@oracle.com> wrote:
>> >> > On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote:
>> >> >> >>> On 20.01.17 at 02:34, <daniel.kiper@oracle.com> wrote:
>> >> MB_TRAMPOLINE_SIZE is in no way the size of the trampoline in the
>> >> first place. Perhaps TRAMPOLINE_SPACE (and then covering both
>> >> parts)?
>> >
>> > So, I suppose that TRAMPOLINE_SPACE and TRAMPOLINE_STACK_SPACE is
>> > OK for you? And I can agree that this is better naming.
>>
>> Again, I don't see why you would need TRAMPOLINE_STACK_SPACE.
>
> If we use TRAMPOLINE_SPACE only for both trampoline and its stack
> then ASSERT() is not very reliable. There is chance that trampoline
> code will fill all space specified in TRAMPOLINE_SPACE and then there
> will be no space for stack at all. However, I can agree that chance
> is small if we assume 64 KiB space for trampoline and trampoline size
> is about 10 KiB right now.
The ASSERT() is the only place you need the stack size, so just
encode (subtract) it there (like iirc Doug had done).
>> >> >> two defines - except in the link time assertion you always use
>> >> >> the sum of the two.
>> >> >>
>> >> >> > +#define MBI_SIZE (2 * PAGE_SIZE)
>> >> >>
>> >> >> On top of Doug's question - if it is needed at all, what does this
>> >> >
>> >> > Please look around reloc() call in xen/arch/x86/boot/head.S. You quickly
>> >> > realize that there is following memory layout from top to bottom:
>> >> >
>> >> > +------------------+
>> >> > | TRAMPOLINE_STACK |
>> >> > +------------------+
>> >> > | TRAMPOLINE |
>> >> > +------------------+
>> >> > | mbi struct |
>> >> > +------------------+
>> >> >
>> >> >> match up with, i.e. how come this is 2 pages (and not 1 or 3)?
>> >> >
>> >> > Just thought that 8 KiB will be sufficient for Xen/modules arguments,
>> >> > memory map and other minor things.
>> >>
>> >> Even with a couple of dozen modules passed? But the primary
>> >
>> > Why not? The biggest thing is memory map. The rest are mostly
>> > command line strings and a few pointers. Modules itself live
>> > in different memory regions.
>>
>> Command line string may get lengthy.
>
> Do you think that we should have more than 8 KiB there? Anyway,
> I am more afraid about memory map size here.
The question is how flexible we want to be. If the size is fixed,
you need to make your code stop using space beyond that size.
>> >> question was left unanswered anyway: Does this need placing in
>> >> the low megabyte at all? And even if it does, especially if you
>> >
>> > I do not think so. I do not expect that anything in trampoline code
>> > touches it. So, we can put it anywhere below 4 GiB. However, then
>> > we need an allocator to properly allocate mbi struct region. And
>> > at this boot stage this is not an easy thing.
>>
>> Depending for how long you need that data to stay around, there
>
> IIRC, it is needed only during init phase. Probably later it can be dropped.
That's way too imprecise.
>> may be places to put it without much risk of overflowing anything.
>
> I am not sure about which places do you think.
There are a number of relatively large internal buffers which could
be used for this purpose if the uses of the MBI data all live before
the first use of whichever such buffer we would select as victim.
Otherwise, just go down from e.g. trampoline+60k until you reach
trampoline_end.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
2017-01-20 1:34 ` [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
2017-01-20 4:37 ` Doug Goldstein
2017-01-20 9:46 ` Jan Beulich
@ 2017-01-20 19:04 ` Doug Goldstein
2017-01-20 19:05 ` Andrew Cooper
2017-01-20 19:34 ` Doug Goldstein
3 siblings, 1 reply; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 19:04 UTC (permalink / raw)
To: Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 458 bytes --]
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> This way Xen can be loaded on EFI platforms using GRUB2 and
> other boot loaders which support multiboot2 protocol.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
> v12 - suggestions/fixes:
> - rename __efi64_start to __efi64_mb2_start
> (suggested by Andrew Cooper),
Andrew actually asked for __mb2_efi64_start
> +
> +__efi64_mb2_start:
here.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
2017-01-20 19:04 ` Doug Goldstein
@ 2017-01-20 19:05 ` Andrew Cooper
0 siblings, 0 replies; 51+ messages in thread
From: Andrew Cooper @ 2017-01-20 19:05 UTC (permalink / raw)
To: Doug Goldstein, Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, pgnet.dev, ning.sun,
julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
On 20/01/17 19:04, Doug Goldstein wrote:
> On 1/19/17 8:34 PM, Daniel Kiper wrote:
>> This way Xen can be loaded on EFI platforms using GRUB2 and
>> other boot loaders which support multiboot2 protocol.
>>
>> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>> ---
>> v12 - suggestions/fixes:
>> - rename __efi64_start to __efi64_mb2_start
>> (suggested by Andrew Cooper),
> Andrew actually asked for __mb2_efi64_start
I can't say that I am overly fussed which way around this ends up. I
certainly won't insist on changing.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
2017-01-20 1:34 ` [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
` (2 preceding siblings ...)
2017-01-20 19:04 ` Doug Goldstein
@ 2017-01-20 19:34 ` Doug Goldstein
2017-01-20 21:42 ` Daniel Kiper
3 siblings, 1 reply; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 19:34 UTC (permalink / raw)
To: Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 923 bytes --]
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> index 62c010e..c1285ad 100644
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> +
> + efi_exit_boot(ImageHandle, SystemTable);
> +
> + /* Return highest allocated memory address below 1 MiB. */
> + return cfg.addr + cfg.size;
So my comment about overwriting memory on 02/10 was spot on but made the
incorrect conclusion that it was before hand and not after. And here's
the issue. I believe what you meant to do was:
return cfg.addr + MBI_SIZE;
I can't see how this booted for you with OVMF because for all the
different versions I've tried with the original code its writing over
reserved memory that QEMU uses for the graphics buffers. Which
immediately results in the trampolines being overwritten with console data.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
2017-01-20 19:34 ` Doug Goldstein
@ 2017-01-20 21:42 ` Daniel Kiper
0 siblings, 0 replies; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 21:42 UTC (permalink / raw)
To: Doug Goldstein
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, xen-devel, qiaowei.ren,
gang.wei, fu.wei
On Fri, Jan 20, 2017 at 02:34:35PM -0500, Doug Goldstein wrote:
> On 1/19/17 8:34 PM, Daniel Kiper wrote:
> > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> > index 62c010e..c1285ad 100644
> > --- a/xen/arch/x86/efi/efi-boot.h
> > +++ b/xen/arch/x86/efi/efi-boot.h
>
> > +
> > + efi_exit_boot(ImageHandle, SystemTable);
> > +
> > + /* Return highest allocated memory address below 1 MiB. */
> > + return cfg.addr + cfg.size;
>
> So my comment about overwriting memory on 02/10 was spot on but made the
> incorrect conclusion that it was before hand and not after. And here's
> the issue. I believe what you meant to do was:
>
> return cfg.addr + MBI_SIZE;
Errr... Sorry, this is the issue which I knew but I forgot to fix in v12.
> I can't see how this booted for you with OVMF because for all the
> different versions I've tried with the original code its writing over
> reserved memory that QEMU uses for the graphics buffers. Which
> immediately results in the trampolines being overwritten with console data.
It booted without any complain...
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* [PATCH v12 06/10] x86: change default load address from 1 MiB to 2 MiB
2017-01-20 1:34 [PATCH v12 00/10] x86: multiboot2 protocol support Daniel Kiper
` (4 preceding siblings ...)
2017-01-20 1:34 ` [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
@ 2017-01-20 1:34 ` Daniel Kiper
2017-01-20 4:06 ` Doug Goldstein
2017-01-20 1:34 ` [PATCH v12 07/10] x86/setup: use XEN_IMG_OFFSET instead of Daniel Kiper
` (5 subsequent siblings)
11 siblings, 1 reply; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 1:34 UTC (permalink / raw)
To: xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, jbeulich, qiaowei.ren,
gang.wei, fu.wei
Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load address from 1 MiB to 2 MiB. This way page table
code will be nice and easy. Hence, there is a chance that it will be
less error prone too... :-)))
Additionally, drop first 2 MiB mapping from Xen image mapping.
It is no longer needed.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
---
v8 - suggestions/fixes:
- drop first 2 MiB mapping from Xen image mapping
(suggested by Jan Beulich),
- improve commit message.
v7 - suggestions/fixes:
- minor cleanups
(suggested by Jan Beulich).
---
xen/arch/x86/Makefile | 2 +-
xen/arch/x86/Rules.mk | 3 +++
xen/arch/x86/boot/head.S | 8 --------
xen/arch/x86/boot/x86_64.S | 5 +++--
xen/arch/x86/setup.c | 3 ++-
xen/arch/x86/xen.lds.S | 2 +-
6 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 08e9f7b..e5b840e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -90,7 +90,7 @@ all_symbols =
endif
$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
- ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 0x100000 \
+ ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) $(XEN_IMG_OFFSET) \
`$(NM) $(TARGET)-syms | sed -ne 's/^\([^ ]*\) . __2M_rwdata_end$$/0x\1/p'`
ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o $(BASEDIR)/arch/x86/efi/built_in.o $(ALL_OBJS)
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 42be4bc..36e6386 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,9 +1,12 @@
########################################
# x86-specific definitions
+XEN_IMG_OFFSET := 0x200000
+
CFLAGS += -I$(BASEDIR)/include
CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
+CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst $(BASEDIR)/,,$(CURDIR))/$@))'
# Prevent floating-point variables from creeping into Xen.
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index b8f727a..22bd68d 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -482,14 +482,6 @@ trampoline_setup:
mov %eax,sym_phys(boot_tsc_stamp)
mov %edx,sym_phys(boot_tsc_stamp+4)
- /*
- * During boot, hook 4kB mappings of first 2MB of memory into L2.
- * This avoids mixing cachability for the legacy VGA region, and is
- * corrected when Xen relocates itself.
- */
- mov $sym_phys(l1_identmap)+__PAGE_HYPERVISOR,%edi
- mov %edi,sym_phys(l2_xenmap)
-
/* Apply relocations to bootstrap trampoline. */
mov sym_phys(trampoline_phys),%edx
mov $sym_phys(__trampoline_rel_start),%edi
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 139b2ca..7890374 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -121,8 +121,9 @@ GLOBAL(l2_identmap)
* page.
*/
GLOBAL(l2_xenmap)
- idx = 0
- .rept 8
+ .quad 0
+ idx = 1
+ .rept 7
.quad sym_phys(__image_base__) + (idx << L2_PAGETABLE_SHIFT) + (PAGE_HYPERVISOR | _PAGE_PSE)
idx = idx + 1
.endr
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index d4b7d25..e6f6ef1 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -999,7 +999,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
* Undo the temporary-hooking of the l1_identmap. __2M_text_start
* is contained in this PTE.
*/
- BUG_ON(l2_table_offset((unsigned long)_erodata) ==
+ BUG_ON(using_2M_mapping() &&
+ l2_table_offset((unsigned long)_erodata) ==
l2_table_offset((unsigned long)_stext));
*pl2e++ = l2e_from_pfn(xen_phys_start >> PAGE_SHIFT,
PAGE_HYPERVISOR_RX | _PAGE_PSE);
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 3a02b2b..f9cdfc1 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -55,7 +55,7 @@ SECTIONS
__2M_text_start = .; /* Start of 2M superpages, mapped RX. */
#endif
- . = __XEN_VIRT_START + MB(1);
+ . = __XEN_VIRT_START + XEN_IMG_OFFSET;
_start = .;
.text : {
_stext = .; /* Text and read-only data */
--
1.7.10.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 51+ messages in thread* Re: [PATCH v12 06/10] x86: change default load address from 1 MiB to 2 MiB
2017-01-20 1:34 ` [PATCH v12 06/10] x86: change default load address from 1 MiB to 2 MiB Daniel Kiper
@ 2017-01-20 4:06 ` Doug Goldstein
2017-01-20 8:49 ` Jan Beulich
0 siblings, 1 reply; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 4:06 UTC (permalink / raw)
To: Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 909 bytes --]
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> Subsequent patches introducing relocatable early boot code play with
> page tables using 2 MiB huge pages. If load address is not aligned at
> 2 MiB then code touching such page tables must have special cases for
> start and end of Xen image memory region. So, let's make life easier
> and move default load address from 1 MiB to 2 MiB. This way page table
> code will be nice and easy. Hence, there is a chance that it will be
> less error prone too... :-)))
>
> Additionally, drop first 2 MiB mapping from Xen image mapping.
> It is no longer needed.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
FWIW, I can't find where I offered my R-b for this patch. Its part of
the series I've said fails on my hardware.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 06/10] x86: change default load address from 1 MiB to 2 MiB
2017-01-20 4:06 ` Doug Goldstein
@ 2017-01-20 8:49 ` Jan Beulich
2017-01-20 10:29 ` Daniel Kiper
0 siblings, 1 reply; 51+ messages in thread
From: Jan Beulich @ 2017-01-20 8:49 UTC (permalink / raw)
To: Doug Goldstein
Cc: Juergen Gross, sstabellini, konrad.wilk, andrew.cooper3,
Daniel Kiper, pgnet.dev, ning.sun, julien.grall, xen-devel,
qiaowei.ren, gang.wei, fu.wei
>>> On 20.01.17 at 05:06, <cardoe@cardoe.com> wrote:
> On 1/19/17 8:34 PM, Daniel Kiper wrote:
>> Subsequent patches introducing relocatable early boot code play with
>> page tables using 2 MiB huge pages. If load address is not aligned at
>> 2 MiB then code touching such page tables must have special cases for
>> start and end of Xen image memory region. So, let's make life easier
>> and move default load address from 1 MiB to 2 MiB. This way page table
>> code will be nice and easy. Hence, there is a chance that it will be
>> less error prone too... :-)))
>>
>> Additionally, drop first 2 MiB mapping from Xen image mapping.
>> It is no longer needed.
>>
>> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
>
> FWIW, I can't find where I offered my R-b for this patch. Its part of
> the series I've said fails on my hardware.
Looks like you had responded to v11 00/13 without naming specific
patches the tag would apply to, so I think Daniel legitimately applied
it to the entire series. Whether he should have dropped it again
after your report of things not working is kind of fuzzy, unless at
some point you've explicitly withdrawn them (which I don't recall
you having done).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 06/10] x86: change default load address from 1 MiB to 2 MiB
2017-01-20 8:49 ` Jan Beulich
@ 2017-01-20 10:29 ` Daniel Kiper
0 siblings, 0 replies; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 10:29 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, sstabellini, konrad.wilk, andrew.cooper3,
Doug Goldstein, pgnet.dev, ning.sun, julien.grall, xen-devel,
qiaowei.ren, gang.wei, fu.wei
On Fri, Jan 20, 2017 at 01:49:46AM -0700, Jan Beulich wrote:
> >>> On 20.01.17 at 05:06, <cardoe@cardoe.com> wrote:
> > On 1/19/17 8:34 PM, Daniel Kiper wrote:
> >> Subsequent patches introducing relocatable early boot code play with
> >> page tables using 2 MiB huge pages. If load address is not aligned at
> >> 2 MiB then code touching such page tables must have special cases for
> >> start and end of Xen image memory region. So, let's make life easier
> >> and move default load address from 1 MiB to 2 MiB. This way page table
> >> code will be nice and easy. Hence, there is a chance that it will be
> >> less error prone too... :-)))
> >>
> >> Additionally, drop first 2 MiB mapping from Xen image mapping.
> >> It is no longer needed.
> >>
> >> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> >> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> >> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
> >
> > FWIW, I can't find where I offered my R-b for this patch. Its part of
> > the series I've said fails on my hardware.
>
> Looks like you had responded to v11 00/13 without naming specific
> patches the tag would apply to, so I think Daniel legitimately applied
> it to the entire series. Whether he should have dropped it again
> after your report of things not working is kind of fuzzy, unless at
> some point you've explicitly withdrawn them (which I don't recall
> you having done).
Thanks Jan. Here is the exact email:
https://lists.xen.org/archives/html/xen-devel/2016-12/msg02151.html
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* [PATCH v12 07/10] x86/setup: use XEN_IMG_OFFSET instead of...
2017-01-20 1:34 [PATCH v12 00/10] x86: multiboot2 protocol support Daniel Kiper
` (5 preceding siblings ...)
2017-01-20 1:34 ` [PATCH v12 06/10] x86: change default load address from 1 MiB to 2 MiB Daniel Kiper
@ 2017-01-20 1:34 ` Daniel Kiper
2017-01-20 4:07 ` Doug Goldstein
2017-01-20 1:34 ` [PATCH v12 08/10] x86: make Xen early boot code relocatable Daniel Kiper
` (4 subsequent siblings)
11 siblings, 1 reply; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 1:34 UTC (permalink / raw)
To: xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, jbeulich, qiaowei.ren,
gang.wei, fu.wei
..calculating its value during runtime.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
---
xen/arch/x86/setup.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index e6f6ef1..24b4b23 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -943,7 +943,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
l4_pgentry_t *pl4e;
l3_pgentry_t *pl3e;
l2_pgentry_t *pl2e;
- uint64_t load_start;
int i, j, k;
/* Select relocation address. */
@@ -957,9 +956,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
* with a barrier(). After this we must *not* modify static/global
* data until after we have switched to the relocated pagetables!
*/
- load_start = (unsigned long)_start - XEN_VIRT_START;
barrier();
- move_memory(e + load_start, load_start, _end - _start, 1);
+ move_memory(e + XEN_IMG_OFFSET, XEN_IMG_OFFSET, _end - _start, 1);
/* Walk initial pagetables, relocating page directory entries. */
pl4e = __va(__pa(idle_pg_table));
--
1.7.10.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 51+ messages in thread* Re: [PATCH v12 07/10] x86/setup: use XEN_IMG_OFFSET instead of...
2017-01-20 1:34 ` [PATCH v12 07/10] x86/setup: use XEN_IMG_OFFSET instead of Daniel Kiper
@ 2017-01-20 4:07 ` Doug Goldstein
0 siblings, 0 replies; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 4:07 UTC (permalink / raw)
To: Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 383 bytes --]
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> ..calculating its value during runtime.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
FWIW, I can't find where I offered my R-b for this patch. Its part of
the series I've said fails on my hardware.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* [PATCH v12 08/10] x86: make Xen early boot code relocatable
2017-01-20 1:34 [PATCH v12 00/10] x86: multiboot2 protocol support Daniel Kiper
` (6 preceding siblings ...)
2017-01-20 1:34 ` [PATCH v12 07/10] x86/setup: use XEN_IMG_OFFSET instead of Daniel Kiper
@ 2017-01-20 1:34 ` Daniel Kiper
2017-01-20 1:34 ` [PATCH v12 09/10] x86/boot: rename sym_phys() to sym_offs() Daniel Kiper
` (3 subsequent siblings)
11 siblings, 0 replies; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 1:34 UTC (permalink / raw)
To: xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, jbeulich, qiaowei.ren,
gang.wei, fu.wei
Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 2 MiB and ends at ~5 MiB) where image should be loaded initially is a RAM
and it is free (legacy BIOS platforms are merciful for Xen but I found at
least one EFI platform on which Xen load address conflicts with EFI boot
services; it is Dell PowerEdge R820 with latest firmware). To cope with that
problem we must make Xen early boot code relocatable and help boot loader to
relocate image in proper way by suggesting, not requesting specific load
addresses as it is right now, allowed address ranges. This patch does former.
It does not add multiboot2 protocol interface which is done in "x86: add
multiboot2 protocol support for relocatable images" patch.
This patch changes following things:
- %esi register is used as a storage for Xen image load base address;
it is mostly unused in early boot code and preserved during C functions
calls in 32-bit mode,
- %fs is used as base for Xen data relative addressing in 32-bit code
if it is possible; %esi is used for that thing during error printing
because it is not always possible to properly and efficiently
initialize %fs.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
v12 - suggestions/fixes:
- store Xen image load base address directly into %esi,
- store Xen image load base address after x86_32_switch
(suggested by Doug Goldstein),
- improve commit message.
v8 - suggestions/fixes:
- use shld instead of mov and shr in BOOT_FS segment
descriptor base address initialization
(suggested by Jan Beulich),
- simplify code updating frame addresses in page tables
(suggested by Jan Beulich),
- print Xen image base addresses using "%#lx" format
(suggested by Jan Beulich),
- improve comments
(suggested by Jan Beulich).
v6 - suggestions/fixes:
- leave static mapping of first
16 MiB in l2_identmap as is
(suggested by Jan Beulich),
- use xen_phys_start instead of xen_img_load_base_addr
(suggested by Daniel Kiper and Jan Beulich),
- simplify BOOT_FS segment descriptor
base address initialization
(suggested by Jan Beulich),
- fix BOOT_FS segment limit
(suggested by Jan Beulich),
- do not rename sym_phys in this patch
(suggested by Jan Beulich),
- rename esi_offset/fs_offset to
sym_esi/sym_fs respectively
(suggested by Jan Beulich),
- use add instead of lea in assembly
error printing code
(suggested by Jan Beulich),
- improve comments
(suggested by Jan Beulich),
- improve commit message
(suggested by Jan Beulich),
- various minor cleanups and fixes
(suggested by Jan Beulich).
v4 - suggestions/fixes:
- do not relocate Xen image if boot loader did work for us
(suggested by Andrew Cooper and Jan Beulich),
- initialize xen_img_load_base_addr in EFI boot code too,
- properly initialize trampoline_xen_phys_start,
- calculate Xen image load base address in
x86_64 code ourselves,
(suggested by Jan Beulich),
- change how and when Xen image base address is printed,
- use %fs instead of %esi for relative addressing
(suggested by Andrew Cooper and Jan Beulich),
- create esi_offset and fs_offset() macros in assembly,
- calculate <final-exec-addr> mkelf32 argument automatically,
- optimize and cleanup code,
- improve comments,
- improve commit message.
v3 - suggestions/fixes:
- improve segment registers initialization
(suggested by Jan Beulich),
- simplify Xen image load base address calculation
(suggested by Jan Beulich),
- use %esi and %r15d instead of %ebp to store
Xen image load base address,
- use %esi instead of %fs for relative addressing;
this way we get shorter and simpler code,
- rename some variables and constants
(suggested by Jan Beulich),
- improve comments
(suggested by Konrad Rzeszutek Wilk),
- improve commit message
(suggested by Jan Beulich).
---
xen/arch/x86/boot/head.S | 157 +++++++++++++++++++++++++++++--------
xen/arch/x86/boot/trampoline.S | 5 ++
xen/arch/x86/boot/x86_64.S | 21 +++--
xen/arch/x86/setup.c | 14 ++--
xen/arch/x86/x86_64/asm-offsets.c | 3 +
xen/include/asm-x86/page.h | 2 +-
6 files changed, 152 insertions(+), 50 deletions(-)
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 22bd68d..f94a4ac 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -13,12 +13,15 @@
.code32
#define sym_phys(sym) ((sym) - __XEN_VIRT_START)
+#define sym_esi(sym) sym_phys(sym)(%esi)
+#define sym_fs(sym) %fs:sym_phys(sym)
#define BOOT_CS32 0x0008
#define BOOT_CS64 0x0010
#define BOOT_DS 0x0018
#define BOOT_PSEUDORM_CS 0x0020
#define BOOT_PSEUDORM_DS 0x0028
+#define BOOT_FS 0x0030
#define MB2_HT(name) (MULTIBOOT2_HEADER_TAG_##name)
#define MB2_TT(name) (MULTIBOOT2_TAG_TYPE_##name)
@@ -105,7 +108,8 @@ multiboot2_header_start:
.word 0
gdt_boot_descr:
- .word 6*8-1
+ .word 7*8-1
+gdt_boot_base:
.long sym_phys(trampoline_gdt)
.long 0 /* Needed for 64-bit lgdt */
@@ -126,27 +130,27 @@ efi_platform:
.section .init.text, "ax", @progbits
bad_cpu:
- mov $(sym_phys(.Lbad_cpu_msg)),%esi # Error message
+ add $sym_phys(.Lbad_cpu_msg),%esi # Error message
jmp .Lget_vtb
not_multiboot:
- mov $(sym_phys(.Lbad_ldr_msg)),%esi # Error message
+ add $sym_phys(.Lbad_ldr_msg),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_st:
- mov $(sym_phys(.Lbad_ldr_nst)),%esi # Error message
+ add $sym_phys(.Lbad_ldr_nst),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_ih:
- mov $(sym_phys(.Lbad_ldr_nih)),%esi # Error message
+ add $sym_phys(.Lbad_ldr_nih),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_bs:
- mov $(sym_phys(.Lbad_ldr_nbs)),%esi # Error message
+ add $sym_phys(.Lbad_ldr_nbs),%esi # Error message
xor %edi,%edi # No VGA text buffer
jmp .Lsend_chr
.Lmb2_efi_ia_32:
- mov $(sym_phys(.Lbad_efi_msg)),%esi # Error message
+ add $sym_phys(.Lbad_efi_msg),%esi # Error message
xor %edi,%edi # No VGA text buffer
jmp .Lsend_chr
.Lget_vtb:
- mov sym_phys(vga_text_buffer),%edi
+ mov sym_esi(vga_text_buffer),%edi
.Lsend_chr:
mov (%esi),%bl
test %bl,%bl # Terminate on '\0' sentinel
@@ -304,9 +308,13 @@ run_bs:
lea trampoline_setup(%rip),%edi
x86_32_switch:
+ /* Store Xen image load base address in place accessible for 32-bit code. */
+ lea __image_base__(%rip),%esi
+
cli
/* Initialize GDTR. */
+ add %esi,gdt_boot_base(%rip)
lgdt gdt_boot_descr(%rip)
/* Reload code selector. */
@@ -342,12 +350,8 @@ __start:
cld
cli
- /* Initialise GDT and basic data segments. */
- lgdt %cs:sym_phys(gdt_boot_descr)
- mov $BOOT_DS,%ecx
- mov %ecx,%ds
- mov %ecx,%es
- mov %ecx,%ss
+ /* Load default Xen image load base address. */
+ mov $sym_phys(__image_base__),%esi
/* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
xor %edx,%edx
@@ -404,6 +408,25 @@ __start:
jmp .Lmb2_tsize
trampoline_bios_setup:
+ /*
+ * Called on legacy BIOS platforms only.
+ *
+ * Initialize GDTR and basic data segments.
+ */
+ add %esi,sym_esi(gdt_boot_base)
+ lgdt sym_esi(gdt_boot_descr)
+
+ mov $BOOT_DS,%ecx
+ mov %ecx,%ds
+ mov %ecx,%es
+ mov %ecx,%ss
+ /* %esp is initialized later. */
+
+ /* Load null descriptor to unused segment registers. */
+ xor %ecx,%ecx
+ mov %ecx,%fs
+ mov %ecx,%gs
+
/* Set up trampoline segment 64k below EBDA */
movzwl 0x40e,%ecx /* EBDA segment */
cmp $0xa000,%ecx /* sanity check (high) */
@@ -431,32 +454,64 @@ trampoline_bios_setup:
xor %cl, %cl
trampoline_setup:
+ /*
+ * Called on legacy BIOS and EFI platforms.
+ *
+ * Initialize 0-15 bits of BOOT_FS segment descriptor base address.
+ */
+ mov %si,BOOT_FS+2+sym_esi(trampoline_gdt)
+
+ /* Initialize 16-23 bits of BOOT_FS segment descriptor base address. */
+ shld $16,%esi,%edx
+ mov %dl,BOOT_FS+4+sym_esi(trampoline_gdt)
+
+ /* Initialize 24-31 bits of BOOT_FS segment descriptor base address. */
+ mov %dh,BOOT_FS+7+sym_esi(trampoline_gdt)
+
+ /*
+ * Initialize %fs and later use it to access Xen data if possible.
+ * According to Intel 64 and IA-32 Architectures Software Developer's
+ * Manual it is safe to do that without reloading GDTR before.
+ */
+ mov $BOOT_FS,%edx
+ mov %edx,%fs
+
/* Save trampoline address for later use. */
shl $4, %ecx
- mov %ecx,sym_phys(trampoline_phys)
+ mov %ecx,sym_fs(trampoline_phys)
+
+ /* Save Xen image load base address for later use. */
+ mov %esi,sym_fs(xen_phys_start)
+ mov %esi,sym_fs(trampoline_xen_phys_start)
+
+ /* Setup stack. %ss was initialized earlier. */
+ lea 1024+sym_esi(cpu0_stack),%esp
/* Save the Multiboot info struct (after relocation) for later use. */
- mov $sym_phys(cpu0_stack)+1024,%esp
push %ecx /* Boot trampoline address. */
push %ebx /* Multiboot information address. */
push %eax /* Multiboot magic. */
call reloc
- mov %eax,sym_phys(multiboot_ptr)
+ mov %eax,sym_fs(multiboot_ptr)
/*
* Do not zero BSS on EFI platform here.
* It was initialized earlier.
*/
- cmpb $0,sym_phys(efi_platform)
+ cmpb $0,sym_fs(efi_platform)
jnz 1f
/* Initialize BSS (no nasty surprises!). */
mov $sym_phys(__bss_start),%edi
mov $sym_phys(__bss_end),%ecx
+ push %fs
+ pop %es
sub %edi,%ecx
xor %eax,%eax
shr $2,%ecx
rep stosl
+ push %ds
+ pop %es
1:
/* Interrogate CPU extended features via CPUID. */
@@ -470,8 +525,8 @@ trampoline_setup:
jbe 1f
mov $0x80000001,%eax
cpuid
-1: mov %edx,sym_phys(cpuid_ext_features)
- mov %edx,sym_phys(boot_cpu_data)+CPUINFO_FEATURE_OFFSET(X86_FEATURE_LM)
+1: mov %edx,sym_fs(cpuid_ext_features)
+ mov %edx,sym_fs(boot_cpu_data)+CPUINFO_FEATURE_OFFSET(X86_FEATURE_LM)
/* Check for availability of long mode. */
bt $cpufeat_bit(X86_FEATURE_LM),%edx
@@ -479,15 +534,52 @@ trampoline_setup:
/* Stash TSC to calculate a good approximation of time-since-boot */
rdtsc
- mov %eax,sym_phys(boot_tsc_stamp)
- mov %edx,sym_phys(boot_tsc_stamp+4)
+ mov %eax,sym_fs(boot_tsc_stamp)
+ mov %edx,sym_fs(boot_tsc_stamp)+4
+
+ /*
+ * Update frame addresses in page tables excluding l2_identmap
+ * without its first entry which points to l1_identmap.
+ */
+ mov $((__page_tables_end-__page_tables_start)/8),%ecx
+ mov $(((l2_identmap-__page_tables_start)/8)+1),%edx
+1: cmp $((l2_identmap+l2_identmap_sizeof-__page_tables_start)/8),%ecx
+ cmove %edx,%ecx
+ testl $_PAGE_PRESENT,sym_fs(__page_tables_start)-8(,%ecx,8)
+ jz 2f
+ add %esi,sym_fs(__page_tables_start)-8(,%ecx,8)
+2: loop 1b
+
+ /* Initialize L2 boot-map/direct map page table entries (16MB). */
+ lea sym_esi(start),%ebx
+ lea (1<<L2_PAGETABLE_SHIFT)*7+(PAGE_HYPERVISOR|_PAGE_PSE)(%ebx),%eax
+ shr $(L2_PAGETABLE_SHIFT-3),%ebx
+ mov $8,%ecx
+1: mov %eax,sym_fs(l2_bootmap)-8(%ebx,%ecx,8)
+ mov %eax,sym_fs(l2_identmap)-8(%ebx,%ecx,8)
+ sub $(1<<L2_PAGETABLE_SHIFT),%eax
+ loop 1b
+
+ /* Initialize L3 boot-map page directory entry. */
+ lea __PAGE_HYPERVISOR+(L2_PAGETABLE_ENTRIES*8)*3+sym_esi(l2_bootmap),%eax
+ mov $4,%ecx
+1: mov %eax,sym_fs(l3_bootmap)-8(,%ecx,8)
+ sub $(L2_PAGETABLE_ENTRIES*8),%eax
+ loop 1b
+
+ /*
+ * During boot, hook 4kB mappings of first 2MB of memory into L2.
+ * This avoids mixing cachability for the legacy VGA region.
+ */
+ lea __PAGE_HYPERVISOR+sym_esi(l1_identmap),%edi
+ mov %edi,sym_fs(l2_bootmap)
/* Apply relocations to bootstrap trampoline. */
- mov sym_phys(trampoline_phys),%edx
+ mov sym_fs(trampoline_phys),%edx
mov $sym_phys(__trampoline_rel_start),%edi
1:
- mov (%edi),%eax
- add %edx,(%edi,%eax)
+ mov %fs:(%edi),%eax
+ add %edx,%fs:(%edi,%eax)
add $4,%edi
cmp $sym_phys(__trampoline_rel_stop),%edi
jb 1b
@@ -496,28 +588,29 @@ trampoline_setup:
shr $4,%edx
mov $sym_phys(__trampoline_seg_start),%edi
1:
- mov (%edi),%eax
- mov %dx,(%edi,%eax)
+ mov %fs:(%edi),%eax
+ mov %dx,%fs:(%edi,%eax)
add $4,%edi
cmp $sym_phys(__trampoline_seg_stop),%edi
jb 1b
/* Do not parse command line on EFI platform here. */
- cmpb $0,sym_phys(efi_platform)
+ cmpb $0,sym_fs(efi_platform)
jnz 1f
/* Bail if there is no command line to parse. */
- mov sym_phys(multiboot_ptr),%ebx
+ mov sym_fs(multiboot_ptr),%ebx
testl $MBI_CMDLINE,MB_flags(%ebx)
jz 1f
- pushl $sym_phys(early_boot_opts)
+ lea sym_esi(early_boot_opts),%eax
+ push %eax
pushl MB_cmdline(%ebx)
call cmdline_parse_early
1:
/* Switch to low-memory stack which lives at the end of trampoline region. */
- mov sym_phys(trampoline_phys),%edi
+ mov sym_fs(trampoline_phys),%edi
lea MB_TRAMPOLINE_SIZE+MB_TRAMPOLINE_STACK_SIZE(%edi),%esp
lea trampoline_boot_cpu_entry-trampoline_start(%edi),%eax
pushl $BOOT_CS32
@@ -526,7 +619,7 @@ trampoline_setup:
/* Copy bootstrap trampoline to low memory, below 1MB. */
mov $sym_phys(trampoline_start),%esi
mov $((trampoline_end - trampoline_start) / 4),%ecx
- rep movsl
+ rep movsl %fs:(%esi),%es:(%edi)
/* Jump into the relocated trampoline. */
lret
diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index 2715d17..64f8efd 100644
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -54,6 +54,11 @@ trampoline_gdt:
/* 0x0028: real-mode data @ BOOT_TRAMPOLINE */
.long 0x0000ffff
.long 0x00009200
+ /*
+ * 0x0030: ring 0 Xen data, 16 MiB size, base
+ * address is computed during runtime.
+ */
+ .quad 0x00c0920000000fff
.pushsection .trampoline_rel, "a"
.long trampoline_gdt + BOOT_PSEUDORM_CS + 2 - .
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 7890374..7392004 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -81,7 +81,6 @@ GLOBAL(boot_cpu_compat_gdt_table)
.quad 0x0000910000000000 /* per-CPU entry (limit == cpu) */
.align PAGE_SIZE, 0
-GLOBAL(__page_tables_start)
/*
* Mapping of first 2 megabytes of memory. This is mapped with 4kB mappings
* to avoid type conflicts with fixed-range MTRRs covering the lowest megabyte
@@ -102,6 +101,13 @@ l1_identmap:
.size l1_identmap, . - l1_identmap
/*
+ * __page_tables_start does not cover l1_identmap because it (l1_identmap)
+ * contains 1-1 mappings. This means that frame addresses of these mappings
+ * are static and should not be updated during runtime.
+ */
+GLOBAL(__page_tables_start)
+
+/*
* Space for mapping the first 4GB of memory, with the first 16 megabytes
* actualy mapped (mostly using superpages). Uses 4x 4k pages.
*/
@@ -186,21 +192,14 @@ GLOBAL(idle_pg_table)
GLOBAL(__page_tables_end)
-/* Init pagetables. Enough page directories to map into the bottom 1GB. */
+/* Init pagetables. Enough page directories to map into 4GB. */
.section .init.data, "a", @progbits
.align PAGE_SIZE, 0
GLOBAL(l2_bootmap)
- .quad sym_phys(l1_identmap) + __PAGE_HYPERVISOR
- idx = 1
- .rept 7
- .quad (idx << L2_PAGETABLE_SHIFT) | __PAGE_HYPERVISOR | _PAGE_PSE
- idx = idx + 1
- .endr
- .fill L2_PAGETABLE_ENTRIES - 8, 8, 0
+ .fill 4 * L2_PAGETABLE_ENTRIES, 8, 0
.size l2_bootmap, . - l2_bootmap
GLOBAL(l3_bootmap)
- .quad sym_phys(l2_bootmap) + __PAGE_HYPERVISOR
- .fill L3_PAGETABLE_ENTRIES - 1, 8, 0
+ .fill L3_PAGETABLE_ENTRIES, 8, 0
.size l3_bootmap, . - l3_bootmap
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 24b4b23..b75129a 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -330,9 +330,6 @@ static void *__init bootstrap_map(const module_t *mod)
if ( start >= end )
return NULL;
- if ( end <= BOOTSTRAP_MAP_BASE )
- return (void *)(unsigned long)start;
-
ret = (void *)(map_cur + (unsigned long)(start & mask));
start &= ~mask;
end = (end + mask) & ~mask;
@@ -716,6 +713,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
printk("Command line: %s\n", cmdline);
+ printk("Xen image load base address: %#lx\n", xen_phys_start);
+
printk("Video information:\n");
/* Print VGA display mode information. */
@@ -973,7 +972,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
/* Not present, 1GB mapping, or already relocated? */
if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) ||
(l3e_get_flags(*pl3e) & _PAGE_PSE) ||
- (l3e_get_pfn(*pl3e) > 0x1000) )
+ (l3e_get_pfn(*pl3e) > PFN_DOWN(xen_phys_start)) )
continue;
*pl3e = l3e_from_intpte(l3e_get_intpte(*pl3e) +
xen_phys_start);
@@ -983,7 +982,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
/* Not present, PSE, or already relocated? */
if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) ||
(l2e_get_flags(*pl2e) & _PAGE_PSE) ||
- (l2e_get_pfn(*pl2e) > 0x1000) )
+ (l2e_get_pfn(*pl2e) > PFN_DOWN(xen_phys_start)) )
continue;
*pl2e = l2e_from_intpte(l2e_get_intpte(*pl2e) +
xen_phys_start);
@@ -1006,7 +1005,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
{
unsigned int flags;
- if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
+ if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) ||
+ (l2e_get_pfn(*pl2e) > PFN_DOWN(xen_phys_start)) )
continue;
if ( !using_2M_mapping() )
@@ -1060,6 +1060,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
: "memory" );
bootstrap_map(NULL);
+
+ printk("New Xen image base address: %#lx\n", xen_phys_start);
}
/* Is the region suitable for relocating the multiboot modules? */
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index f135654..87e573a 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -179,5 +179,8 @@ void __dummy__(void)
OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
BLANK();
+ DEFINE(l2_identmap_sizeof, sizeof(l2_identmap));
+ BLANK();
+
OFFSET(DOMAIN_vm_assist, struct domain, vm_assist);
}
diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
index af7d3e8..a54fdd1 100644
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -288,7 +288,7 @@ extern root_pgentry_t idle_pg_table[ROOT_PAGETABLE_ENTRIES];
extern l2_pgentry_t *compat_idle_pg_table_l2;
extern unsigned int m2p_compat_vstart;
extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES],
- l2_bootmap[L2_PAGETABLE_ENTRIES];
+ l2_bootmap[4*L2_PAGETABLE_ENTRIES];
extern l3_pgentry_t l3_bootmap[L3_PAGETABLE_ENTRIES];
extern l2_pgentry_t l2_identmap[4*L2_PAGETABLE_ENTRIES];
extern l1_pgentry_t l1_fixmap[L1_PAGETABLE_ENTRIES];
--
1.7.10.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 51+ messages in thread* [PATCH v12 09/10] x86/boot: rename sym_phys() to sym_offs()
2017-01-20 1:34 [PATCH v12 00/10] x86: multiboot2 protocol support Daniel Kiper
` (7 preceding siblings ...)
2017-01-20 1:34 ` [PATCH v12 08/10] x86: make Xen early boot code relocatable Daniel Kiper
@ 2017-01-20 1:34 ` Daniel Kiper
2017-01-20 4:08 ` Doug Goldstein
2017-01-20 1:34 ` [PATCH v12 10/10] x86: add multiboot2 protocol support for relocatable images Daniel Kiper
` (2 subsequent siblings)
11 siblings, 1 reply; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 1:34 UTC (permalink / raw)
To: xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, jbeulich, qiaowei.ren,
gang.wei, fu.wei
This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.
There is no functional change.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
---
v8 - suggestions/fixes:
- improve commit message
(suggested by Jan Beulich).
---
xen/arch/x86/boot/head.S | 38 +++++++++++++++++++-------------------
xen/arch/x86/boot/trampoline.S | 2 +-
xen/arch/x86/boot/wakeup.S | 4 ++--
xen/arch/x86/boot/x86_64.S | 18 +++++++++---------
4 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index f94a4ac..bbc7cdd 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -12,9 +12,9 @@
.text
.code32
-#define sym_phys(sym) ((sym) - __XEN_VIRT_START)
-#define sym_esi(sym) sym_phys(sym)(%esi)
-#define sym_fs(sym) %fs:sym_phys(sym)
+#define sym_offs(sym) ((sym) - __XEN_VIRT_START)
+#define sym_esi(sym) sym_offs(sym)(%esi)
+#define sym_fs(sym) %fs:sym_offs(sym)
#define BOOT_CS32 0x0008
#define BOOT_CS64 0x0010
@@ -97,7 +97,7 @@ multiboot2_header_start:
/* EFI64 Multiboot2 entry point. */
mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
- sym_phys(__efi64_mb2_start)
+ sym_offs(__efi64_mb2_start)
/* Multiboot2 header end tag. */
mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
@@ -110,7 +110,7 @@ multiboot2_header_start:
gdt_boot_descr:
.word 7*8-1
gdt_boot_base:
- .long sym_phys(trampoline_gdt)
+ .long sym_offs(trampoline_gdt)
.long 0 /* Needed for 64-bit lgdt */
.align 4
@@ -130,23 +130,23 @@ efi_platform:
.section .init.text, "ax", @progbits
bad_cpu:
- add $sym_phys(.Lbad_cpu_msg),%esi # Error message
+ add $sym_offs(.Lbad_cpu_msg),%esi # Error message
jmp .Lget_vtb
not_multiboot:
- add $sym_phys(.Lbad_ldr_msg),%esi # Error message
+ add $sym_offs(.Lbad_ldr_msg),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_st:
- add $sym_phys(.Lbad_ldr_nst),%esi # Error message
+ add $sym_offs(.Lbad_ldr_nst),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_ih:
- add $sym_phys(.Lbad_ldr_nih),%esi # Error message
+ add $sym_offs(.Lbad_ldr_nih),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_bs:
- add $sym_phys(.Lbad_ldr_nbs),%esi # Error message
+ add $sym_offs(.Lbad_ldr_nbs),%esi # Error message
xor %edi,%edi # No VGA text buffer
jmp .Lsend_chr
.Lmb2_efi_ia_32:
- add $sym_phys(.Lbad_efi_msg),%esi # Error message
+ add $sym_offs(.Lbad_efi_msg),%esi # Error message
xor %edi,%edi # No VGA text buffer
jmp .Lsend_chr
.Lget_vtb:
@@ -351,7 +351,7 @@ __start:
cli
/* Load default Xen image load base address. */
- mov $sym_phys(__image_base__),%esi
+ mov $sym_offs(__image_base__),%esi
/* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
xor %edx,%edx
@@ -502,8 +502,8 @@ trampoline_setup:
jnz 1f
/* Initialize BSS (no nasty surprises!). */
- mov $sym_phys(__bss_start),%edi
- mov $sym_phys(__bss_end),%ecx
+ mov $sym_offs(__bss_start),%edi
+ mov $sym_offs(__bss_end),%ecx
push %fs
pop %es
sub %edi,%ecx
@@ -576,22 +576,22 @@ trampoline_setup:
/* Apply relocations to bootstrap trampoline. */
mov sym_fs(trampoline_phys),%edx
- mov $sym_phys(__trampoline_rel_start),%edi
+ mov $sym_offs(__trampoline_rel_start),%edi
1:
mov %fs:(%edi),%eax
add %edx,%fs:(%edi,%eax)
add $4,%edi
- cmp $sym_phys(__trampoline_rel_stop),%edi
+ cmp $sym_offs(__trampoline_rel_stop),%edi
jb 1b
/* Patch in the trampoline segment. */
shr $4,%edx
- mov $sym_phys(__trampoline_seg_start),%edi
+ mov $sym_offs(__trampoline_seg_start),%edi
1:
mov %fs:(%edi),%eax
mov %dx,%fs:(%edi,%eax)
add $4,%edi
- cmp $sym_phys(__trampoline_seg_stop),%edi
+ cmp $sym_offs(__trampoline_seg_stop),%edi
jb 1b
/* Do not parse command line on EFI platform here. */
@@ -617,7 +617,7 @@ trampoline_setup:
push %eax
/* Copy bootstrap trampoline to low memory, below 1MB. */
- mov $sym_phys(trampoline_start),%esi
+ mov $sym_offs(trampoline_start),%esi
mov $((trampoline_end - trampoline_start) / 4),%ecx
rep movsl %fs:(%esi),%es:(%edi)
diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index 64f8efd..b96607a 100644
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -92,7 +92,7 @@ trampoline_protmode_entry:
mov %ecx,%cr4
/* Load pagetable base register. */
- mov $sym_phys(idle_pg_table),%eax
+ mov $sym_offs(idle_pg_table),%eax
add bootsym_rel(trampoline_xen_phys_start,4,%eax)
mov %eax,%cr3
diff --git a/xen/arch/x86/boot/wakeup.S b/xen/arch/x86/boot/wakeup.S
index 08ea9b2..42d57ab 100644
--- a/xen/arch/x86/boot/wakeup.S
+++ b/xen/arch/x86/boot/wakeup.S
@@ -120,7 +120,7 @@ wakeup_32:
mov $bootsym_rel(wakeup_stack, 4, %esp)
# check saved magic again
- mov $sym_phys(saved_magic), %eax
+ mov $sym_offs(saved_magic),%eax
add bootsym_rel(trampoline_xen_phys_start, 4, %eax)
mov (%eax), %eax
cmp $0x9abcdef0, %eax
@@ -133,7 +133,7 @@ wakeup_32:
mov %ecx, %cr4
/* Load pagetable base register */
- mov $sym_phys(idle_pg_table),%eax
+ mov $sym_offs(idle_pg_table),%eax
add bootsym_rel(trampoline_xen_phys_start,4,%eax)
mov %eax,%cr3
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 7392004..86d3775 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -112,7 +112,7 @@ GLOBAL(__page_tables_start)
* actualy mapped (mostly using superpages). Uses 4x 4k pages.
*/
GLOBAL(l2_identmap)
- .quad sym_phys(l1_identmap) + __PAGE_HYPERVISOR
+ .quad sym_offs(l1_identmap) + __PAGE_HYPERVISOR
idx = 1
.rept 7
.quad (idx << L2_PAGETABLE_SHIFT) | PAGE_HYPERVISOR | _PAGE_PSE
@@ -130,7 +130,7 @@ GLOBAL(l2_xenmap)
.quad 0
idx = 1
.rept 7
- .quad sym_phys(__image_base__) + (idx << L2_PAGETABLE_SHIFT) + (PAGE_HYPERVISOR | _PAGE_PSE)
+ .quad sym_offs(__image_base__) + (idx << L2_PAGETABLE_SHIFT) + (PAGE_HYPERVISOR | _PAGE_PSE)
idx = idx + 1
.endr
.fill L2_PAGETABLE_ENTRIES - 8, 8, 0
@@ -141,7 +141,7 @@ l2_fixmap:
idx = 0
.rept L2_PAGETABLE_ENTRIES
.if idx == l2_table_offset(FIXADDR_TOP - 1)
- .quad sym_phys(l1_fixmap) + __PAGE_HYPERVISOR
+ .quad sym_offs(l1_fixmap) + __PAGE_HYPERVISOR
.else
.quad 0
.endif
@@ -153,7 +153,7 @@ l2_fixmap:
l3_identmap:
idx = 0
.rept 4
- .quad sym_phys(l2_identmap) + (idx << PAGE_SHIFT) + __PAGE_HYPERVISOR
+ .quad sym_offs(l2_identmap) + (idx << PAGE_SHIFT) + __PAGE_HYPERVISOR
idx = idx + 1
.endr
.fill L3_PAGETABLE_ENTRIES - 4, 8, 0
@@ -164,9 +164,9 @@ l3_xenmap:
idx = 0
.rept L3_PAGETABLE_ENTRIES
.if idx == l3_table_offset(XEN_VIRT_START)
- .quad sym_phys(l2_xenmap) + __PAGE_HYPERVISOR
+ .quad sym_offs(l2_xenmap) + __PAGE_HYPERVISOR
.elseif idx == l3_table_offset(FIXADDR_TOP - 1)
- .quad sym_phys(l2_fixmap) + __PAGE_HYPERVISOR
+ .quad sym_offs(l2_fixmap) + __PAGE_HYPERVISOR
.else
.quad 0
.endif
@@ -176,13 +176,13 @@ l3_xenmap:
/* Top-level master (and idle-domain) page directory. */
GLOBAL(idle_pg_table)
- .quad sym_phys(l3_bootmap) + __PAGE_HYPERVISOR
+ .quad sym_offs(l3_bootmap) + __PAGE_HYPERVISOR
idx = 1
.rept L4_PAGETABLE_ENTRIES - 1
.if idx == l4_table_offset(DIRECTMAP_VIRT_START)
- .quad sym_phys(l3_identmap) + __PAGE_HYPERVISOR
+ .quad sym_offs(l3_identmap) + __PAGE_HYPERVISOR
.elseif idx == l4_table_offset(XEN_VIRT_START)
- .quad sym_phys(l3_xenmap) + __PAGE_HYPERVISOR
+ .quad sym_offs(l3_xenmap) + __PAGE_HYPERVISOR
.else
.quad 0
.endif
--
1.7.10.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 51+ messages in thread* Re: [PATCH v12 09/10] x86/boot: rename sym_phys() to sym_offs()
2017-01-20 1:34 ` [PATCH v12 09/10] x86/boot: rename sym_phys() to sym_offs() Daniel Kiper
@ 2017-01-20 4:08 ` Doug Goldstein
0 siblings, 0 replies; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 4:08 UTC (permalink / raw)
To: Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 691 bytes --]
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> This way macro name better describes its function.
> Currently it is used to calculate symbol offset in
> relation to the beginning of Xen image mapping.
> However, value returned by sym_offs() for a given
> symbol is not always equal its physical address.
>
> There is no functional change.
>
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
FWIW, I can't find where I offered my R-b for this patch. Its part of
the series I've said fails on my hardware.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* [PATCH v12 10/10] x86: add multiboot2 protocol support for relocatable images
2017-01-20 1:34 [PATCH v12 00/10] x86: multiboot2 protocol support Daniel Kiper
` (8 preceding siblings ...)
2017-01-20 1:34 ` [PATCH v12 09/10] x86/boot: rename sym_phys() to sym_offs() Daniel Kiper
@ 2017-01-20 1:34 ` Daniel Kiper
2017-01-20 4:08 ` Doug Goldstein
2017-01-20 16:22 ` [PATCH v12 00/10] x86: multiboot2 protocol support Doug Goldstein
2017-01-20 19:42 ` Doug Goldstein
11 siblings, 1 reply; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 1:34 UTC (permalink / raw)
To: xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, cardoe,
pgnet.dev, ning.sun, julien.grall, jbeulich, qiaowei.ren,
gang.wei, fu.wei
Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
---
v12 - suggestions/fixes:
- replace TABs with spaces in xen/include/xen/multiboot2.h
(suggested by Doug Goldstein).
v9 - suggestions/fixes:
- use .L labels instead of numeric ones in multiboot2 data scanning loop
(suggested by Jan Beulich).
v4 - suggestions/fixes:
- do not get Xen image load base address from
multiboot2 information in x86_64 code
(suggested by Jan Beulich),
- improve label names
(suggested by Jan Beulich),
- improve comments,
(suggested by Jan Beulich).
v3 - suggestions/fixes:
- use %esi and %r15d instead of %ebp to store
Xen image load base address,
- rename some types and constants,
- reformat xen/include/xen/multiboot2.h
(suggested by Konrad Rzeszutek Wilk),
- improve comments,
- improve commit message
(suggested by Konrad Rzeszutek Wilk).
---
xen/arch/x86/boot/head.S | 16 ++++++++++++++++
xen/arch/x86/x86_64/asm-offsets.c | 1 +
xen/include/xen/multiboot2.h | 13 +++++++++++++
3 files changed, 30 insertions(+)
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index bbc7cdd..fd0238b 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -82,6 +82,13 @@ multiboot2_header_start:
/* Align modules at page boundry. */
mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
+ /* Load address preference. */
+ mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \
+ sym_offs(start), /* Min load address. */ \
+ 0xffffffff, /* The end of image max load address (4 GiB - 1). */ \
+ 0x200000, /* Load address alignment (2 MiB). */ \
+ MULTIBOOT2_LOAD_PREFERENCE_HIGH
+
/* Console flags tag. */
mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
@@ -383,6 +390,15 @@ __start:
cmp %edi,MB2_fixed_total_size(%ebx)
jbe trampoline_bios_setup
+ /* Get Xen image load base address from Multiboot2 information. */
+ cmpl $MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%ecx)
+ jne .Lmb2_mem_lower
+
+ mov MB2_load_base_addr(%ecx),%esi
+ sub $XEN_IMG_OFFSET,%esi
+ jmp .Lmb2_next_tag
+
+.Lmb2_mem_lower:
/* Get mem_lower from Multiboot2 information. */
cmpl $MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
cmove MB2_mem_lower(%ecx),%edx
diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c
index 87e573a..85639e4 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -174,6 +174,7 @@ void __dummy__(void)
OFFSET(MB2_fixed_total_size, multiboot2_fixed_t, total_size);
OFFSET(MB2_tag_type, multiboot2_tag_t, type);
OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+ OFFSET(MB2_load_base_addr, multiboot2_tag_load_base_addr_t, load_base_addr);
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/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
index a3e3119..5acd225 100644
--- a/xen/include/xen/multiboot2.h
+++ b/xen/include/xen/multiboot2.h
@@ -59,11 +59,17 @@
#define MULTIBOOT2_HEADER_TAG_EFI_BS 7
#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32 8
#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64 9
+#define MULTIBOOT2_HEADER_TAG_RELOCATABLE 10
/* Header tag flags. */
#define MULTIBOOT2_HEADER_TAG_REQUIRED 0
#define MULTIBOOT2_HEADER_TAG_OPTIONAL 1
+/* Where image should be loaded (suggestion not requirement). */
+#define MULTIBOOT2_LOAD_PREFERENCE_NONE 0
+#define MULTIBOOT2_LOAD_PREFERENCE_LOW 1
+#define MULTIBOOT2_LOAD_PREFERENCE_HIGH 2
+
/* Header console tag console_flags. */
#define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED 1
#define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED 2
@@ -90,6 +96,7 @@
#define MULTIBOOT2_TAG_TYPE_EFI_BS 18
#define MULTIBOOT2_TAG_TYPE_EFI32_IH 19
#define MULTIBOOT2_TAG_TYPE_EFI64_IH 20
+#define MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR 21
/* Multiboot 2 tag alignment. */
#define MULTIBOOT2_TAG_ALIGN 8
@@ -120,6 +127,12 @@ typedef struct {
typedef struct {
u32 type;
u32 size;
+ u32 load_base_addr;
+} multiboot2_tag_load_base_addr_t;
+
+typedef struct {
+ u32 type;
+ u32 size;
char string[];
} multiboot2_tag_string_t;
--
1.7.10.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 51+ messages in thread* Re: [PATCH v12 10/10] x86: add multiboot2 protocol support for relocatable images
2017-01-20 1:34 ` [PATCH v12 10/10] x86: add multiboot2 protocol support for relocatable images Daniel Kiper
@ 2017-01-20 4:08 ` Doug Goldstein
0 siblings, 0 replies; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 4:08 UTC (permalink / raw)
To: Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 614 bytes --]
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> Add multiboot2 protocol support for relocatable images. Only GRUB2 with
> "multiboot2: Add support for relocatable images" patch understands
> that feature. Older multiboot protocol (regardless of version)
> compatible loaders ignore it and everything works as usual.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
FWIW, I can't find where I offered my R-b for this patch. Its part of
the series I've said fails on my hardware.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-20 1:34 [PATCH v12 00/10] x86: multiboot2 protocol support Daniel Kiper
` (9 preceding siblings ...)
2017-01-20 1:34 ` [PATCH v12 10/10] x86: add multiboot2 protocol support for relocatable images Daniel Kiper
@ 2017-01-20 16:22 ` Doug Goldstein
2017-01-20 17:21 ` Daniel Kiper
2017-01-20 19:42 ` Doug Goldstein
11 siblings, 1 reply; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 16:22 UTC (permalink / raw)
To: Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 446 bytes --]
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> Hi,
>
> I am sending twelfth version of multiboot2 protocol support for
> legacy BIOS and EFI platforms. This patch series release contains
> fixes for all known/confirmed issues.
What machines did you test this series on? It fails to boot with iPXE
and grub on an Intel NUC and another board I've got. I've also just
tried to apply 1-5 and it fails to boot as well.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-20 16:22 ` [PATCH v12 00/10] x86: multiboot2 protocol support Doug Goldstein
@ 2017-01-20 17:21 ` Daniel Kiper
2017-01-20 18:53 ` Doug Goldstein
2017-01-20 19:28 ` Doug Goldstein
0 siblings, 2 replies; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 17:21 UTC (permalink / raw)
To: Doug Goldstein
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, xen-devel, qiaowei.ren,
gang.wei, fu.wei
On Fri, Jan 20, 2017 at 11:22:21AM -0500, Doug Goldstein wrote:
> On 1/19/17 8:34 PM, Daniel Kiper wrote:
> > Hi,
> >
> > I am sending twelfth version of multiboot2 protocol support for
> > legacy BIOS and EFI platforms. This patch series release contains
> > fixes for all known/confirmed issues.
>
> What machines did you test this series on? It fails to boot with iPXE
I have done tests on OVMF and IBM System x3550 M2. It works on both machines.
I have tested multiboot/multiboot2 on legacy BIOS, multiboot2 on EFI and
xen.efi on EFI. If it works on both OVMF and IBM System x3550 M2 I do not
have any problems anywhere else. Or it happens very rarely.
> and grub on an Intel NUC and another board I've got. I've also just
Let's focus on GRUB2. It is well tested setup. If it works then we can
move to iPXE. By the way, could you try xen.efi from current upstream
and with my patches. It should work without any issue.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-20 17:21 ` Daniel Kiper
@ 2017-01-20 18:53 ` Doug Goldstein
2017-01-20 19:28 ` Doug Goldstein
1 sibling, 0 replies; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 18:53 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, xen-devel, qiaowei.ren,
gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 1163 bytes --]
On 1/20/17 12:21 PM, Daniel Kiper wrote:
> On Fri, Jan 20, 2017 at 11:22:21AM -0500, Doug Goldstein wrote:
>> On 1/19/17 8:34 PM, Daniel Kiper wrote:
>>> Hi,
>>>
>>> I am sending twelfth version of multiboot2 protocol support for
>>> legacy BIOS and EFI platforms. This patch series release contains
>>> fixes for all known/confirmed issues.
>>
>> What machines did you test this series on? It fails to boot with iPXE
>
> I have done tests on OVMF and IBM System x3550 M2. It works on both machines.
> I have tested multiboot/multiboot2 on legacy BIOS, multiboot2 on EFI and
> xen.efi on EFI. If it works on both OVMF and IBM System x3550 M2 I do not
> have any problems anywhere else. Or it happens very rarely.
"it happens very rarely" is a bit concerning to me here.
>
>> and grub on an Intel NUC and another board I've got. I've also just
>
> Let's focus on GRUB2. It is well tested setup. If it works then we can
> move to iPXE. By the way, could you try xen.efi from current upstream
> and with my patches. It should work without any issue.
I'm using grub at the revision you mentioned a while back.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-20 17:21 ` Daniel Kiper
2017-01-20 18:53 ` Doug Goldstein
@ 2017-01-20 19:28 ` Doug Goldstein
1 sibling, 0 replies; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 19:28 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, xen-devel, qiaowei.ren,
gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 1014 bytes --]
On 1/20/17 12:21 PM, Daniel Kiper wrote:
> On Fri, Jan 20, 2017 at 11:22:21AM -0500, Doug Goldstein wrote:
>> On 1/19/17 8:34 PM, Daniel Kiper wrote:
>>> Hi,
>>>
>>> I am sending twelfth version of multiboot2 protocol support for
>>> legacy BIOS and EFI platforms. This patch series release contains
>>> fixes for all known/confirmed issues.
>>
>> What machines did you test this series on? It fails to boot with iPXE
>
> I have done tests on OVMF and IBM System x3550 M2. It works on both machines.
> I have tested multiboot/multiboot2 on legacy BIOS, multiboot2 on EFI and
> xen.efi on EFI. If it works on both OVMF and IBM System x3550 M2 I do not
> have any problems anywhere else. Or it happens very rarely.
What version of OVMF? I've tried the version that ships with Ubuntu
16.10 and a build of master from last week. I've also tried with QEMU
from Ubuntu 16.10 and master from earlier this week. I've also tried
with and without KVM. None have worked for me.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-20 1:34 [PATCH v12 00/10] x86: multiboot2 protocol support Daniel Kiper
` (10 preceding siblings ...)
2017-01-20 16:22 ` [PATCH v12 00/10] x86: multiboot2 protocol support Doug Goldstein
@ 2017-01-20 19:42 ` Doug Goldstein
2017-01-20 19:52 ` Doug Goldstein
` (2 more replies)
11 siblings, 3 replies; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 19:42 UTC (permalink / raw)
To: Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 1377 bytes --]
On 1/19/17 8:34 PM, Daniel Kiper wrote:
> Hi,
>
> I am sending twelfth version of multiboot2 protocol support for
> legacy BIOS and EFI platforms. This patch series release contains
> fixes for all known/confirmed issues.
With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
get the following on some of the systems I have access to:
(XEN) [ 2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) [ 7.012109] Stuck ??
(XEN) [ 7.012129] Failed to bring up CPU 1 (error -5)
(XEN) [ 12.023606] Stuck ??
(XEN) [ 12.023622] Failed to bring up CPU 2 (error -5)
(XEN) [ 17.035099] Stuck ??
(XEN) [ 17.035115] Failed to bring up CPU 3 (error -5)
(XEN) [ 17.035116] Brought up 1 CPUs
On other machines they reset when setting PAGING into cr0 (actually the
jmp following it) on line 124 of trampoline.S
If I drop the series to just 2-5 against staging (since patch 1 has
already gone in) and apply the fix to efi_multiboot2() then all the
machines I presently have access to boot.
Effectively the fix to efi_multiboot2() gets us back to the same level
of hardware support that v11 + my v5 was at for 1-5. So I will extend my:
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Tested-by: Doug Goldstein <cardoe@cardoe.com>
on the condition that the fix is applied to 5/10 prior to commit.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-20 19:42 ` Doug Goldstein
@ 2017-01-20 19:52 ` Doug Goldstein
2017-01-20 20:01 ` Konrad Rzeszutek Wilk
2017-01-20 21:54 ` Daniel Kiper
2 siblings, 0 replies; 51+ messages in thread
From: Doug Goldstein @ 2017-01-20 19:52 UTC (permalink / raw)
To: Daniel Kiper, xen-devel
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 564 bytes --]
On 1/20/17 2:42 PM, Doug Goldstein wrote:
> Effectively the fix to efi_multiboot2() gets us back to the same level
> of hardware support that v11 + my v5 was at for 1-5. So I will extend my:
>
> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
> Tested-by: Doug Goldstein <cardoe@cardoe.com>
>
> on the condition that the fix is applied to 5/10 prior to commit.
>
I forgot to note that I had to implement most of Jan's fixes to 5/10 as
well. I didn't do the register change in .Lrun_bs and some of the
stylistic changes.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-20 19:42 ` Doug Goldstein
2017-01-20 19:52 ` Doug Goldstein
@ 2017-01-20 20:01 ` Konrad Rzeszutek Wilk
2017-01-20 21:54 ` Daniel Kiper
2 siblings, 0 replies; 51+ messages in thread
From: Konrad Rzeszutek Wilk @ 2017-01-20 20:01 UTC (permalink / raw)
To: Doug Goldstein
Cc: jgross, sstabellini, andrew.cooper3, Daniel Kiper, pgnet.dev,
ning.sun, julien.grall, jbeulich, xen-devel, qiaowei.ren,
gang.wei, fu.wei
On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> On 1/19/17 8:34 PM, Daniel Kiper wrote:
> > Hi,
> >
> > I am sending twelfth version of multiboot2 protocol support for
> > legacy BIOS and EFI platforms. This patch series release contains
> > fixes for all known/confirmed issues.
>
> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
> get the following on some of the systems I have access to:
>
> (XEN) [ 2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB
> (XEN) [ 7.012109] Stuck ??
> (XEN) [ 7.012129] Failed to bring up CPU 1 (error -5)
> (XEN) [ 12.023606] Stuck ??
> (XEN) [ 12.023622] Failed to bring up CPU 2 (error -5)
> (XEN) [ 17.035099] Stuck ??
> (XEN) [ 17.035115] Failed to bring up CPU 3 (error -5)
> (XEN) [ 17.035116] Brought up 1 CPUs
>
> On other machines they reset when setting PAGING into cr0 (actually the
> jmp following it) on line 124 of trampoline.S
>
> If I drop the series to just 2-5 against staging (since patch 1 has
> already gone in) and apply the fix to efi_multiboot2() then all the
> machines I presently have access to boot.
>
> Effectively the fix to efi_multiboot2() gets us back to the same level
> of hardware support that v11 + my v5 was at for 1-5. So I will extend my:
>
> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
> Tested-by: Doug Goldstein <cardoe@cardoe.com>
>
> on the condition that the fix is applied to 5/10 prior to commit.
I am assuming you had applied this fix on top of this version? If
so any chance you could reply here with it - just to make sure
that nothing is lost?
Thanks!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-20 19:42 ` Doug Goldstein
2017-01-20 19:52 ` Doug Goldstein
2017-01-20 20:01 ` Konrad Rzeszutek Wilk
@ 2017-01-20 21:54 ` Daniel Kiper
2017-01-23 13:08 ` Daniel Kiper
2 siblings, 1 reply; 51+ messages in thread
From: Daniel Kiper @ 2017-01-20 21:54 UTC (permalink / raw)
To: Doug Goldstein
Cc: jgross, sstabellini, konrad.wilk, andrew.cooper3, pgnet.dev,
ning.sun, julien.grall, jbeulich, xen-devel, qiaowei.ren,
gang.wei, fu.wei
On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> On 1/19/17 8:34 PM, Daniel Kiper wrote:
> > Hi,
> >
> > I am sending twelfth version of multiboot2 protocol support for
> > legacy BIOS and EFI platforms. This patch series release contains
> > fixes for all known/confirmed issues.
>
> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
> get the following on some of the systems I have access to:
>
> (XEN) [ 2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB
> (XEN) [ 7.012109] Stuck ??
> (XEN) [ 7.012129] Failed to bring up CPU 1 (error -5)
> (XEN) [ 12.023606] Stuck ??
> (XEN) [ 12.023622] Failed to bring up CPU 2 (error -5)
> (XEN) [ 17.035099] Stuck ??
> (XEN) [ 17.035115] Failed to bring up CPU 3 (error -5)
> (XEN) [ 17.035116] Brought up 1 CPUs
>
> On other machines they reset when setting PAGING into cr0 (actually the
> jmp following it) on line 124 of trampoline.S
Thanks! I will take a look.
> If I drop the series to just 2-5 against staging (since patch 1 has
> already gone in) and apply the fix to efi_multiboot2() then all the
> machines I presently have access to boot.
Great!
> Effectively the fix to efi_multiboot2() gets us back to the same level
> of hardware support that v11 + my v5 was at for 1-5. So I will extend my:
>
> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
> Tested-by: Doug Goldstein <cardoe@cardoe.com>
Thanks!
> on the condition that the fix is applied to 5/10 prior to commit.
Will do.
By the way, I have asked my team colleagues to do more tests of this series.
I will come back to you if I have something in hand.
Thank you for your help.
Have a nice weekend,
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-20 21:54 ` Daniel Kiper
@ 2017-01-23 13:08 ` Daniel Kiper
2017-01-23 14:28 ` Konrad Rzeszutek Wilk
2017-01-23 15:35 ` Doug Goldstein
0 siblings, 2 replies; 51+ messages in thread
From: Daniel Kiper @ 2017-01-23 13:08 UTC (permalink / raw)
To: Doug Goldstein
Cc: jgross, sstabellini, andrew.cooper3, pgnet.dev, ning.sun,
julien.grall, jbeulich, xen-devel, qiaowei.ren, gang.wei, fu.wei
On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> > On 1/19/17 8:34 PM, Daniel Kiper wrote:
> > > Hi,
> > >
> > > I am sending twelfth version of multiboot2 protocol support for
> > > legacy BIOS and EFI platforms. This patch series release contains
> > > fixes for all known/confirmed issues.
> >
> > With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
> > get the following on some of the systems I have access to:
> >
> > (XEN) [ 2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB
> > (XEN) [ 7.012109] Stuck ??
> > (XEN) [ 7.012129] Failed to bring up CPU 1 (error -5)
> > (XEN) [ 12.023606] Stuck ??
> > (XEN) [ 12.023622] Failed to bring up CPU 2 (error -5)
> > (XEN) [ 17.035099] Stuck ??
> > (XEN) [ 17.035115] Failed to bring up CPU 3 (error -5)
> > (XEN) [ 17.035116] Brought up 1 CPUs
> >
> > On other machines they reset when setting PAGING into cr0 (actually the
> > jmp following it) on line 124 of trampoline.S
>
> Thanks! I will take a look.
>
> > If I drop the series to just 2-5 against staging (since patch 1 has
> > already gone in) and apply the fix to efi_multiboot2() then all the
> > machines I presently have access to boot.
>
> Great!
>
> > Effectively the fix to efi_multiboot2() gets us back to the same level
> > of hardware support that v11 + my v5 was at for 1-5. So I will extend my:
> >
> > Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
> > Tested-by: Doug Goldstein <cardoe@cardoe.com>
>
> Thanks!
>
> > on the condition that the fix is applied to 5/10 prior to commit.
>
> Will do.
>
> By the way, I have asked my team colleagues to do more tests of this series.
> I will come back to you if I have something in hand.
Once you told me that you applied some patches on top of my patch series to get
it working. Is it still true? If you still use some extra patches could you send
me them? What about ExitBootServices() call? Did you disabled it? If yes on which
machines it have to be disabled?
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-23 13:08 ` Daniel Kiper
@ 2017-01-23 14:28 ` Konrad Rzeszutek Wilk
2017-01-23 16:03 ` Doug Goldstein
2017-01-23 15:35 ` Doug Goldstein
1 sibling, 1 reply; 51+ messages in thread
From: Konrad Rzeszutek Wilk @ 2017-01-23 14:28 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, sstabellini, andrew.cooper3, Doug Goldstein, pgnet.dev,
ning.sun, julien.grall, jbeulich, xen-devel, qiaowei.ren,
gang.wei, fu.wei
On Mon, Jan 23, 2017 at 02:08:58PM +0100, Daniel Kiper wrote:
> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
> > On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> > > On 1/19/17 8:34 PM, Daniel Kiper wrote:
> > > > Hi,
> > > >
> > > > I am sending twelfth version of multiboot2 protocol support for
> > > > legacy BIOS and EFI platforms. This patch series release contains
> > > > fixes for all known/confirmed issues.
> > >
> > > With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
> > > get the following on some of the systems I have access to:
Both me and Daniel seem to have test machines with EFI that are not soo .. defective.
Could you mention which boxes have these kinds of trouble so we can
get to the bottom of this?
[Is it by any chance a T420 or x230 laptop - I am using legacy BIOS on them
as I couldn't even get them to suspend properly]
And would it be possible to get serial/power access to this box (Intel NUC?)
to figure out what is going on?
Thanks!
.. snip..
> Once you told me that you applied some patches on top of my patch series to get
> it working. Is it still true? If you still use some extra patches could you send
> me them? What about ExitBootServices() call? Did you disabled it? If yes on which
> machines it have to be disabled?
>
> Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-23 14:28 ` Konrad Rzeszutek Wilk
@ 2017-01-23 16:03 ` Doug Goldstein
2017-01-23 18:12 ` Daniel Kiper
0 siblings, 1 reply; 51+ messages in thread
From: Doug Goldstein @ 2017-01-23 16:03 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Daniel Kiper
Cc: jgross, sstabellini, andrew.cooper3, pgnet.dev, ning.sun,
julien.grall, jbeulich, xen-devel, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 2312 bytes --]
On 1/23/17 8:28 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 23, 2017 at 02:08:58PM +0100, Daniel Kiper wrote:
>> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
>>> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
>>>> On 1/19/17 8:34 PM, Daniel Kiper wrote:
>>>>> Hi,
>>>>>
>>>>> I am sending twelfth version of multiboot2 protocol support for
>>>>> legacy BIOS and EFI platforms. This patch series release contains
>>>>> fixes for all known/confirmed issues.
>>>>
>>>> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
>>>> get the following on some of the systems I have access to:
>
>
> Both me and Daniel seem to have test machines with EFI that are not soo .. defective.
What machines? Model numbers? Manufacture?
I'd also argue that this series continues to write into reserved memory
regions (as confirmed by the fix to 5/10 that I sent in) and you're able
to still boot so I wouldn't put much value into the hardware you've been
using.
>
> Could you mention which boxes have these kinds of trouble so we can
> get to the bottom of this?
HP ML10v2
Lenovo T430
Intel NUC NUC5i5MYHE
Intel NUC NUC5i3MYHE (oddly has a pretty different firmware than above)
Mercury LDS3506
Dell Precision 3420 (co-worker says this is setup to boot BIOS)
ASUS M3A78-CM motherboard
ASUS AMD motherboard (I don't have it near me and its not powered on
right now)
SuperMicro ???? (I don't have it near me and its not powered on right
now so I can't figure it out)
QEMU + OVMF from Ubuntu 16.10
QEMU (master from last week) + OVMF (master from last week)
The two unknowns are machines I've got at home and I had unplugged
everything while I was on vacation to hopefully avoid lightning strike
damage.
>
> [Is it by any chance a T420 or x230 laptop - I am using legacy BIOS on them
> as I couldn't even get them to suspend properly]
I'm using EFI on my T430.
>
> And would it be possible to get serial/power access to this box (Intel NUC?)
> to figure out what is going on?
Likely not. Both those operations are only available over AMT which is
connected on our internal corporate network. I can see if I can bring it
home for a period of time and give you access from my home.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-23 16:03 ` Doug Goldstein
@ 2017-01-23 18:12 ` Daniel Kiper
0 siblings, 0 replies; 51+ messages in thread
From: Daniel Kiper @ 2017-01-23 18:12 UTC (permalink / raw)
To: Doug Goldstein
Cc: jgross, sstabellini, andrew.cooper3, pgnet.dev, ning.sun,
julien.grall, jbeulich, xen-devel, qiaowei.ren, gang.wei, fu.wei
On Mon, Jan 23, 2017 at 10:03:52AM -0600, Doug Goldstein wrote:
> On 1/23/17 8:28 AM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 23, 2017 at 02:08:58PM +0100, Daniel Kiper wrote:
> >> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
> >>> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> >>>> On 1/19/17 8:34 PM, Daniel Kiper wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I am sending twelfth version of multiboot2 protocol support for
> >>>>> legacy BIOS and EFI platforms. This patch series release contains
> >>>>> fixes for all known/confirmed issues.
> >>>>
> >>>> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
> >>>> get the following on some of the systems I have access to:
> >
> > Both me and Daniel seem to have test machines with EFI that are not soo .. defective.
>
> What machines? Model numbers? Manufacture?
We are doing the tests. Until now everything works. I will compile full
list for you when we are finished.
> I'd also argue that this series continues to write into reserved memory
> regions (as confirmed by the fix to 5/10 that I sent in) and you're able
We do tests with your fix for #05 and full v12 patch series.
> to still boot so I wouldn't put much value into the hardware you've been
> using.
I would not comment on that until I know why it does not work on your boxes.
> > Could you mention which boxes have these kinds of trouble so we can
> > get to the bottom of this?
>
> HP ML10v2
> Lenovo T430
> Intel NUC NUC5i5MYHE
> Intel NUC NUC5i3MYHE (oddly has a pretty different firmware than above)
> Mercury LDS3506
> Dell Precision 3420 (co-worker says this is setup to boot BIOS)
> ASUS M3A78-CM motherboard
> ASUS AMD motherboard (I don't have it near me and its not powered on
> right now)
> SuperMicro ???? (I don't have it near me and its not powered on right
> now so I can't figure it out)
> QEMU + OVMF from Ubuntu 16.10
> QEMU (master from last week) + OVMF (master from last week)
Thanks for the list. Do you use latest firmware on above mentioned machines?
I hope that yes. I am asking just in case.
I am going to release v13 by the end of Wednesday. Should I remove your
Reviewed-by from patch 6-10?
[...]
> > And would it be possible to get serial/power access to this box (Intel NUC?)
> > to figure out what is going on?
>
> Likely not. Both those operations are only available over AMT which is
> connected on our internal corporate network. I can see if I can bring it
> home for a period of time and give you access from my home.
It would be nice.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-23 13:08 ` Daniel Kiper
2017-01-23 14:28 ` Konrad Rzeszutek Wilk
@ 2017-01-23 15:35 ` Doug Goldstein
2017-01-23 15:45 ` Daniel Kiper
1 sibling, 1 reply; 51+ messages in thread
From: Doug Goldstein @ 2017-01-23 15:35 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, sstabellini, andrew.cooper3, pgnet.dev, ning.sun,
julien.grall, jbeulich, xen-devel, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 2427 bytes --]
On 1/23/17 7:08 AM, Daniel Kiper wrote:
> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
>> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
>>> On 1/19/17 8:34 PM, Daniel Kiper wrote:
>>>> Hi,
>>>>
>>>> I am sending twelfth version of multiboot2 protocol support for
>>>> legacy BIOS and EFI platforms. This patch series release contains
>>>> fixes for all known/confirmed issues.
>>>
>>> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
>>> get the following on some of the systems I have access to:
>>>
>>> (XEN) [ 2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB
>>> (XEN) [ 7.012109] Stuck ??
>>> (XEN) [ 7.012129] Failed to bring up CPU 1 (error -5)
>>> (XEN) [ 12.023606] Stuck ??
>>> (XEN) [ 12.023622] Failed to bring up CPU 2 (error -5)
>>> (XEN) [ 17.035099] Stuck ??
>>> (XEN) [ 17.035115] Failed to bring up CPU 3 (error -5)
>>> (XEN) [ 17.035116] Brought up 1 CPUs
>>>
>>> On other machines they reset when setting PAGING into cr0 (actually the
>>> jmp following it) on line 124 of trampoline.S
>>
>> Thanks! I will take a look.
>>
>>> If I drop the series to just 2-5 against staging (since patch 1 has
>>> already gone in) and apply the fix to efi_multiboot2() then all the
>>> machines I presently have access to boot.
>>
>> Great!
>>
>>> Effectively the fix to efi_multiboot2() gets us back to the same level
>>> of hardware support that v11 + my v5 was at for 1-5. So I will extend my:
>>>
>>> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
>>> Tested-by: Doug Goldstein <cardoe@cardoe.com>
>>
>> Thanks!
>>
>>> on the condition that the fix is applied to 5/10 prior to commit.
>>
>> Will do.
>>
>> By the way, I have asked my team colleagues to do more tests of this series.
>> I will come back to you if I have something in hand.
>
> Once you told me that you applied some patches on top of my patch series to get
> it working. Is it still true? If you still use some extra patches could you send
> me them? What about ExitBootServices() call? Did you disabled it? If yes on which
> machines it have to be disabled?
>
> Daniel
>
I previously used the patch that I linked to you authored by Konrad. I
have since switched to the patches that XenServer uses to no-op
efi_get_time() and to map additional ranges of reserved memory to make
EBS() work.
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-23 15:35 ` Doug Goldstein
@ 2017-01-23 15:45 ` Daniel Kiper
2017-01-23 16:07 ` Doug Goldstein
0 siblings, 1 reply; 51+ messages in thread
From: Daniel Kiper @ 2017-01-23 15:45 UTC (permalink / raw)
To: Doug Goldstein
Cc: jgross, sstabellini, andrew.cooper3, pgnet.dev, ning.sun,
julien.grall, jbeulich, xen-devel, qiaowei.ren, gang.wei, fu.wei
On Mon, Jan 23, 2017 at 09:35:55AM -0600, Doug Goldstein wrote:
> On 1/23/17 7:08 AM, Daniel Kiper wrote:
> > On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
> >> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> >>> On 1/19/17 8:34 PM, Daniel Kiper wrote:
> >>>> Hi,
> >>>>
> >>>> I am sending twelfth version of multiboot2 protocol support for
> >>>> legacy BIOS and EFI platforms. This patch series release contains
> >>>> fixes for all known/confirmed issues.
> >>>
> >>> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
> >>> get the following on some of the systems I have access to:
> >>>
> >>> (XEN) [ 2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB
> >>> (XEN) [ 7.012109] Stuck ??
> >>> (XEN) [ 7.012129] Failed to bring up CPU 1 (error -5)
> >>> (XEN) [ 12.023606] Stuck ??
> >>> (XEN) [ 12.023622] Failed to bring up CPU 2 (error -5)
> >>> (XEN) [ 17.035099] Stuck ??
> >>> (XEN) [ 17.035115] Failed to bring up CPU 3 (error -5)
> >>> (XEN) [ 17.035116] Brought up 1 CPUs
> >>>
> >>> On other machines they reset when setting PAGING into cr0 (actually the
> >>> jmp following it) on line 124 of trampoline.S
> >>
> >> Thanks! I will take a look.
> >>
> >>> If I drop the series to just 2-5 against staging (since patch 1 has
> >>> already gone in) and apply the fix to efi_multiboot2() then all the
> >>> machines I presently have access to boot.
> >>
> >> Great!
> >>
> >>> Effectively the fix to efi_multiboot2() gets us back to the same level
> >>> of hardware support that v11 + my v5 was at for 1-5. So I will extend my:
> >>>
> >>> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
> >>> Tested-by: Doug Goldstein <cardoe@cardoe.com>
> >>
> >> Thanks!
> >>
> >>> on the condition that the fix is applied to 5/10 prior to commit.
> >>
> >> Will do.
> >>
> >> By the way, I have asked my team colleagues to do more tests of this series.
> >> I will come back to you if I have something in hand.
> >
> > Once you told me that you applied some patches on top of my patch series to get
> > it working. Is it still true? If you still use some extra patches could you send
> > me them? What about ExitBootServices() call? Did you disabled it? If yes on which
> > machines it have to be disabled?
> >
> > Daniel
> >
>
> I previously used the patch that I linked to you authored by Konrad. I
> have since switched to the patches that XenServer uses to no-op
> efi_get_time() and to map additional ranges of reserved memory to make
> EBS() work.
Could you send me them?
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-23 15:45 ` Daniel Kiper
@ 2017-01-23 16:07 ` Doug Goldstein
2017-01-23 18:16 ` Daniel Kiper
0 siblings, 1 reply; 51+ messages in thread
From: Doug Goldstein @ 2017-01-23 16:07 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, sstabellini, andrew.cooper3, pgnet.dev, ning.sun,
julien.grall, jbeulich, xen-devel, qiaowei.ren, gang.wei, fu.wei
[-- Attachment #1.1.1: Type: text/plain, Size: 3029 bytes --]
On 1/23/17 9:45 AM, Daniel Kiper wrote:
> On Mon, Jan 23, 2017 at 09:35:55AM -0600, Doug Goldstein wrote:
>> On 1/23/17 7:08 AM, Daniel Kiper wrote:
>>> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
>>>> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
>>>>> On 1/19/17 8:34 PM, Daniel Kiper wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I am sending twelfth version of multiboot2 protocol support for
>>>>>> legacy BIOS and EFI platforms. This patch series release contains
>>>>>> fixes for all known/confirmed issues.
>>>>>
>>>>> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
>>>>> get the following on some of the systems I have access to:
>>>>>
>>>>> (XEN) [ 2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB
>>>>> (XEN) [ 7.012109] Stuck ??
>>>>> (XEN) [ 7.012129] Failed to bring up CPU 1 (error -5)
>>>>> (XEN) [ 12.023606] Stuck ??
>>>>> (XEN) [ 12.023622] Failed to bring up CPU 2 (error -5)
>>>>> (XEN) [ 17.035099] Stuck ??
>>>>> (XEN) [ 17.035115] Failed to bring up CPU 3 (error -5)
>>>>> (XEN) [ 17.035116] Brought up 1 CPUs
>>>>>
>>>>> On other machines they reset when setting PAGING into cr0 (actually the
>>>>> jmp following it) on line 124 of trampoline.S
>>>>
>>>> Thanks! I will take a look.
>>>>
>>>>> If I drop the series to just 2-5 against staging (since patch 1 has
>>>>> already gone in) and apply the fix to efi_multiboot2() then all the
>>>>> machines I presently have access to boot.
>>>>
>>>> Great!
>>>>
>>>>> Effectively the fix to efi_multiboot2() gets us back to the same level
>>>>> of hardware support that v11 + my v5 was at for 1-5. So I will extend my:
>>>>>
>>>>> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
>>>>> Tested-by: Doug Goldstein <cardoe@cardoe.com>
>>>>
>>>> Thanks!
>>>>
>>>>> on the condition that the fix is applied to 5/10 prior to commit.
>>>>
>>>> Will do.
>>>>
>>>> By the way, I have asked my team colleagues to do more tests of this series.
>>>> I will come back to you if I have something in hand.
>>>
>>> Once you told me that you applied some patches on top of my patch series to get
>>> it working. Is it still true? If you still use some extra patches could you send
>>> me them? What about ExitBootServices() call? Did you disabled it? If yes on which
>>> machines it have to be disabled?
>>>
>>> Daniel
>>>
>>
>> I previously used the patch that I linked to you authored by Konrad. I
>> have since switched to the patches that XenServer uses to no-op
>> efi_get_time() and to map additional ranges of reserved memory to make
>> EBS() work.
>
> Could you send me them?
>
> Daniel
>
I apply them only for 2 out of the roughly dozen machines. Its not those
changes.
https://github.com/xenserver/xen-4.7.pg/blob/master/master/0002-efi-Ensure-incorrectly-typed-runtime-services-get-ma.patch
https://github.com/xenserver/xen-4.7.pg/blob/master/master/0001-x86-time-Don-t-use-EFI-s-GetTime-call.patch
--
Doug Goldstein
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH v12 00/10] x86: multiboot2 protocol support
2017-01-23 16:07 ` Doug Goldstein
@ 2017-01-23 18:16 ` Daniel Kiper
0 siblings, 0 replies; 51+ messages in thread
From: Daniel Kiper @ 2017-01-23 18:16 UTC (permalink / raw)
To: Doug Goldstein
Cc: jgross, sstabellini, andrew.cooper3, pgnet.dev, ning.sun,
julien.grall, jbeulich, xen-devel, qiaowei.ren, gang.wei, fu.wei
On Mon, Jan 23, 2017 at 10:07:36AM -0600, Doug Goldstein wrote:
> On 1/23/17 9:45 AM, Daniel Kiper wrote:
> > On Mon, Jan 23, 2017 at 09:35:55AM -0600, Doug Goldstein wrote:
> >> On 1/23/17 7:08 AM, Daniel Kiper wrote:
> >>> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
> >>>> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> >>>>> On 1/19/17 8:34 PM, Daniel Kiper wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I am sending twelfth version of multiboot2 protocol support for
> >>>>>> legacy BIOS and EFI platforms. This patch series release contains
> >>>>>> fixes for all known/confirmed issues.
> >>>>>
> >>>>> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
> >>>>> get the following on some of the systems I have access to:
> >>>>>
> >>>>> (XEN) [ 2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB
> >>>>> (XEN) [ 7.012109] Stuck ??
> >>>>> (XEN) [ 7.012129] Failed to bring up CPU 1 (error -5)
> >>>>> (XEN) [ 12.023606] Stuck ??
> >>>>> (XEN) [ 12.023622] Failed to bring up CPU 2 (error -5)
> >>>>> (XEN) [ 17.035099] Stuck ??
> >>>>> (XEN) [ 17.035115] Failed to bring up CPU 3 (error -5)
> >>>>> (XEN) [ 17.035116] Brought up 1 CPUs
> >>>>>
> >>>>> On other machines they reset when setting PAGING into cr0 (actually the
> >>>>> jmp following it) on line 124 of trampoline.S
> >>>>
> >>>> Thanks! I will take a look.
> >>>>
> >>>>> If I drop the series to just 2-5 against staging (since patch 1 has
> >>>>> already gone in) and apply the fix to efi_multiboot2() then all the
> >>>>> machines I presently have access to boot.
> >>>>
> >>>> Great!
> >>>>
> >>>>> Effectively the fix to efi_multiboot2() gets us back to the same level
> >>>>> of hardware support that v11 + my v5 was at for 1-5. So I will extend my:
> >>>>>
> >>>>> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
> >>>>> Tested-by: Doug Goldstein <cardoe@cardoe.com>
> >>>>
> >>>> Thanks!
> >>>>
> >>>>> on the condition that the fix is applied to 5/10 prior to commit.
> >>>>
> >>>> Will do.
> >>>>
> >>>> By the way, I have asked my team colleagues to do more tests of this series.
> >>>> I will come back to you if I have something in hand.
> >>>
> >>> Once you told me that you applied some patches on top of my patch series to get
> >>> it working. Is it still true? If you still use some extra patches could you send
> >>> me them? What about ExitBootServices() call? Did you disabled it? If yes on which
> >>> machines it have to be disabled?
> >>>
> >>> Daniel
> >>
> >> I previously used the patch that I linked to you authored by Konrad. I
> >> have since switched to the patches that XenServer uses to no-op
> >> efi_get_time() and to map additional ranges of reserved memory to make
> >> EBS() work.
> >
> > Could you send me them?
> >
> > Daniel
>
> I apply them only for 2 out of the roughly dozen machines. Its not those
> changes.
>
> https://github.com/xenserver/xen-4.7.pg/blob/master/master/0002-efi-Ensure-incorrectly-typed-runtime-services-get-ma.patch
>
> https://github.com/xenserver/xen-4.7.pg/blob/master/master/0001-x86-time-Don-t-use-EFI-s-GetTime-call.patch
Thanks! I will take a look.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 51+ messages in thread