A partner of ours is reporting boot failures (Xen not even emitting a
single message) over iSCSI on new (UEFI based) systems. After
pointing at their BIOS initially I finally remembered to take a look
at the memory map a native kernel booted this way see - and voila, the
BIOS reports memory starting at 0x8d000 as reserved. Xen, however,
places about 12k of (trampoline) data at 0x8c000.
Not having got testing feedback on the below patch yet, I still wanted
to raise the question whether for 4.0 we should go with a simplistic
fix like this, or whether we shouldn''t really determine the trampoline
location dynamically (i.e. honoring the E820 data) since it obviously
cannot be excluded that other BIOSes might reserve even more of the
space below 640k.
One thing this patch enforces in any case is a single point of
definition for the hard coded location, so that at least adjusting it
won''t require more than a single line change in the future.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
--- 2010-01-27.orig/xen/arch/x86/boot/Makefile 2010-01-13 18:58:11.000000000
+0100
+++ 2010-01-27/xen/arch/x86/boot/Makefile 2010-02-05 13:56:20.000000000 +0100
@@ -2,6 +2,8 @@ obj-y += head.o
head.o: reloc.S
-# NB. BOOT_TRAMPOLINE == 0x8c000
+BOOT_TRAMPOLINE := $(shell sed -n
''s,^\#define[[:space:]]\+BOOT_TRAMPOLINE[[:space:]]\+,,p''
$(BASEDIR)/include/asm-x86/config.h)
%.S: %.c
- RELOC=0x8c000 $(MAKE) -f build32.mk $@
+ RELOC=$(BOOT_TRAMPOLINE) $(MAKE) -f build32.mk $@
+
+reloc.S: $(BASEDIR)/include/asm-x86/config.h
--- 2010-01-27.orig/xen/arch/x86/boot/build32.mk 2010-01-13 18:58:11.000000000
+0100
+++ 2010-01-27/xen/arch/x86/boot/build32.mk 2010-02-05 14:19:12.000000000 +0100
@@ -19,7 +19,9 @@ CFLAGS += -Werror -fno-builtin -msoft-fl
$(OBJCOPY) -O binary $< $@
%.lnk: %.o
- $(LD) $(LDFLAGS_DIRECT) -N -Ttext 0x8c000 -o $@ $<
+ $(LD) $(LDFLAGS_DIRECT) -N -Ttext $(RELOC) -o $@ $<
%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@
+
+reloc.o: $(BASEDIR)/include/asm-x86/config.h
--- 2010-01-27.orig/xen/include/asm-x86/config.h 2010-01-13 18:58:11.000000000
+0100
+++ 2010-01-27/xen/include/asm-x86/config.h 2010-02-05 13:46:19.000000000 +0100
@@ -94,7 +94,7 @@
/* Primary stack is restricted to 8kB by guard pages. */
#define PRIMARY_STACK_SIZE 8192
-#define BOOT_TRAMPOLINE 0x8c000
+#define BOOT_TRAMPOLINE 0x88000
#define bootsym_phys(sym) \
(((unsigned long)&(sym)-(unsigned
long)&trampoline_start)+BOOT_TRAMPOLINE)
#define bootsym(sym) \
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2010-Feb-10 09:36 UTC
Re: [Xen-devel] [PATCH, RFC] x86: move trampoline location
On 09/02/2010 13:46, "Jan Beulich" <JBeulich@novell.com> wrote:> A partner of ours is reporting boot failures (Xen not even emitting a > single message) over iSCSI on new (UEFI based) systems. After > pointing at their BIOS initially I finally remembered to take a look > at the memory map a native kernel booted this way see - and voila, the > BIOS reports memory starting at 0x8d000 as reserved. Xen, however, > places about 12k of (trampoline) data at 0x8c000. > > Not having got testing feedback on the below patch yet, I still wanted > to raise the question whether for 4.0 we should go with a simplistic > fix like this, or whether we shouldn''t really determine the trampoline > location dynamically (i.e. honoring the E820 data) since it obviously > cannot be excluded that other BIOSes might reserve even more of the > space below 640k.Looks fine to me, for 4.0.0 and 3.4.3. I''m not sure whether dynamic placement based on E820 info is worthwhile. If all systems have an available region from about address 0x0 up to some delta below EBDA etc, then why not statically place the trampoline/reloc code to account for the largest such delta ever observed? The main danger in going to lower addresses I think is some bootloaders stick multiboot structures down there, which would get obliterated by our 32-bit relocator. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel