[PATCH v2 00/13] x86, boot, 64bit: Add support for loading ramdisk and bzImage high

[PATCH v2 00/13] x86, boot, 64bit: Add support for loading ramdisk and bzImage high

[Yinghai Lu]

Now we have limit kdump reseved under 896M, because kexec has the limitation.
and also bzImage need to stay under 4g.

To make kexec/kdump could use range above 4g, we need to make bzImage and
ramdisk could be loaded above 4g.
During booting bzImage will be unpacked on same postion and stay high.

The patches add field in boot header to
1. get info about ramdisk position info above 4g from bootloader/kexec
2. set code64_start_offset in header for bzImage and bootloader/kexec load
   could check that to decide if need to put bzImage high.

This patches is tested with kexec tools with local changes and they are sent
to kexec list.

could be found at:
        git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-boot

and it is on top of for-x86-mm

-v2: add ext_cmd_line_ptr support, and handle boot_param/cmd_line is above
     4G case.

Thanks

Yinghai

Yinghai Lu (13):
  x86, boot: move verify_cpu.S after 0x200
  x86, boot: Move lldt/ltr out of 64bit code section
  x86: Add macro for 64bit entry startup_64
  x86, 64bit: set extra ident page table for whole kernel range
  x86, 64bit: add support for loading kernel above 512G
  x86: Merge early_reserve_initrd for 32bit and 64bit
  x86: add get_ramdisk_image/size
  x86, boot: add get_cmd_line_ptr()
  x86, boot: Don't check if cmd_line_ptr is accessible in misc/decompressor()
  x86, boot: update cmd_line_ptr to unsigned long
  x86: use io_remap to access real_mode_data
  x86, boot: add fields to support load bzImage and ramdisk high
  x86: remove 1024g limitation for kexec buffer on 64bit

 Documentation/x86/boot.txt         |   39 +++++++++++++++++++++++++
 arch/x86/boot/boot.h               |   18 +++++++++--
 arch/x86/boot/cmdline.c            |   12 ++++----
 arch/x86/boot/compressed/cmdline.c |   13 +++++++-
 arch/x86/boot/compressed/head_64.S |   16 ++++++----
 arch/x86/boot/header.S             |    8 ++++-
 arch/x86/include/asm/boot.h        |    2 +
 arch/x86/include/asm/bootparam.h   |    4 ++
 arch/x86/include/asm/kexec.h       |    6 ++--
 arch/x86/kernel/head32.c           |   11 -------
 arch/x86/kernel/head64.c           |   42 +++++++++++++++++----------
 arch/x86/kernel/head_64.S          |   49 +++++++++++++++++++++++++------
 arch/x86/kernel/setup.c            |   55 +++++++++++++++++++++++++++++------
 13 files changed, 207 insertions(+), 68 deletions(-)

-- 
1.7.7

[PATCH v2 01/13] x86, boot: move verify_cpu.S after 0x200

[Yinghai Lu]

We are short of space before 0x200 that is entry for startup_64.

And we can not change startup_64 to other value --- ABI ?

We could move function verify_cpu down, and that could avoid extra
code of jmp back and forth.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Matt Fleming <matt.fleming@intel.com>
---
 arch/x86/boot/compressed/head_64.S |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
index 2c4b171..2c3cee4 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -182,8 +182,6 @@ no_longmode:
 	hlt
 	jmp     1b
 
-#include "../../kernel/verify_cpu.S"
-
 	/*
 	 * Be careful here startup_64 needs to be at a predictable
 	 * address so I can export it in an ELF header.  Bootloaders
@@ -349,6 +347,9 @@ relocated:
  */
 	jmp	*%rbp
 
+	.code32
+#include "../../kernel/verify_cpu.S"
+
 	.data
 gdt:
 	.word	gdt_end - gdt
-- 
1.7.7

[PATCH v2 02/13] x86, boot: Move lldt/ltr out of 64bit code section

[Yinghai Lu]

commit 08da5a2ca

    x86_64: Early segment setup for VT

add lldt/ltr to clean more segments.

Those code are put in code64, and it is using gdt that is only
loaded from code32 path.

That breaks booting with 64bit bootloader that does not go through
code32 path, and get at startup_64 directly, so they have different
gdt.

Move those lines into code32 after their gdt is loaded.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Zachary Amsden <zamsden@gmail.com>
Cc: Matt Fleming <matt.fleming@intel.com>
---
 arch/x86/boot/compressed/head_64.S |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
index 2c3cee4..375af23 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -154,6 +154,12 @@ ENTRY(startup_32)
 	btsl	$_EFER_LME, %eax
 	wrmsr
 
+	/* After gdt is loaded */
+	xorl	%eax, %eax
+	lldt	%ax
+	movl    $0x20, %eax
+	ltr	%ax
+
 	/*
 	 * Setup for the jump to 64bit mode
 	 *
@@ -245,9 +251,6 @@ preferred_addr:
 	movl	%eax, %ss
 	movl	%eax, %fs
 	movl	%eax, %gs
-	lldt	%ax
-	movl    $0x20, %eax
-	ltr	%ax
 
 	/*
 	 * Compute the decompressed kernel start address.  It is where
-- 
1.7.7

[PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[Yinghai Lu]

We will add one 64bit entry for bzImage in boot header struct.

the contents in that field will be offset of startup_64.

Add macro for offset of startup_64 to keep two places consistent.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Matt Fleming <matt.fleming@intel.com>
---
 arch/x86/boot/compressed/head_64.S |    2 +-
 arch/x86/include/asm/boot.h        |    2 ++
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
index 375af23..e4964dd 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -195,7 +195,7 @@ no_longmode:
 	 * it may change in the future.
 	 */
 	.code64
-	.org 0x200
+	.org BOOT_CODE64_START_OFFSET
 ENTRY(startup_64)
 	/*
 	 * We come here either from startup_32 or directly from a
diff --git a/arch/x86/include/asm/boot.h b/arch/x86/include/asm/boot.h
index b13fe63..ef36497 100644
--- a/arch/x86/include/asm/boot.h
+++ b/arch/x86/include/asm/boot.h
@@ -38,8 +38,10 @@
 
 #ifdef CONFIG_X86_64
 #define BOOT_STACK_SIZE	0x4000
+#define BOOT_CODE64_START_OFFSET 0x200
 #else
 #define BOOT_STACK_SIZE	0x1000
+#define BOOT_CODE64_START_OFFSET 0
 #endif
 
 #endif /* __KERNEL__ */
-- 
1.7.7

[PATCH v2 04/13] x86, 64bit: set extra ident page table for whole kernel range

[Yinghai Lu]

Current when kernel is loaded above 1G, only [_text, _text+2M]
is set up with extra ident page table.
That is not enough, some variables that could be used early are
out of that range. (like gdt...)

Just set map for [_text, _end] include text/data/bss/brk...

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
---
 arch/x86/kernel/head_64.S |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 94bf9cc..efc0c08 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -115,7 +115,16 @@ startup_64:
 	andq	$(PTRS_PER_PMD - 1), %rax
 	leaq	__PAGE_KERNEL_IDENT_LARGE_EXEC(%rdi), %rdx
 	leaq	level2_spare_pgt(%rip), %rbx
-	movq	%rdx, 0(%rbx, %rax, 8)
+	leaq	_end(%rip), %r8
+	decq	%r8
+	shrq	$PMD_SHIFT, %r8
+	andq	$(PTRS_PER_PMD - 1), %r8
+1:	movq	%rdx, 0(%rbx, %rax, 8)
+	addq	$PMD_SIZE, %rdx
+	incq	%rax
+	cmp	%r8, %rax
+	jle	1b
+
 ident_complete:
 
 	/*
-- 
1.7.7

[PATCH v2 05/13] x86, 64bit: add support for loading kernel above 512G

[Yinghai Lu]

Current kernel is not allowed to be loaded above 512g, it thinks
that address is too big.

We only need to add one extra spare page for needed level3 to
point another 512g range.

Need to check _text range and set level4 pg to point to that spare
level3 page, and set level3 to point to level2 page to cover
[_text, _end] with extra mapping.

We need this to put relocatable bzImage high above 512g.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
---
 arch/x86/kernel/head_64.S |   34 +++++++++++++++++++++++++++-------
 1 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index efc0c08..32fa9d0 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -78,12 +78,6 @@ startup_64:
 	testl	%eax, %eax
 	jnz	bad_address
 
-	/* Is the address too large? */
-	leaq	_text(%rip), %rdx
-	movq	$PGDIR_SIZE, %rax
-	cmpq	%rax, %rdx
-	jae	bad_address
-
 	/* Fixup the physical addresses in the page table
 	 */
 	addq	%rbp, init_level4_pgt + 0(%rip)
@@ -102,12 +96,35 @@ startup_64:
 	andq	$PMD_PAGE_MASK, %rdi
 
 	movq	%rdi, %rax
+	shrq	$PGDIR_SHIFT, %rax
+	andq	$(PTRS_PER_PGD - 1), %rax
+	jz	skip_level3_spare
+
+	/* Set level3 at first */
+	leaq	(level3_spare_pgt - __START_KERNEL_map + _KERNPG_TABLE)(%rbp), %rdx
+	leaq	init_level4_pgt(%rip), %rbx
+	movq	%rdx, 0(%rbx, %rax, 8)
+	addq	$L4_PAGE_OFFSET, %rax
+	movq	%rdx, 0(%rbx, %rax, 8)
+
+	/* always need to set level2 */
+	movq	%rdi, %rax
+	shrq	$PUD_SHIFT, %rax
+	andq	$(PTRS_PER_PUD - 1), %rax
+	leaq	level3_spare_pgt(%rip), %rbx
+	jmp	set_level2_spare
+
+skip_level3_spare:
+	movq	%rdi, %rax
 	shrq	$PUD_SHIFT, %rax
 	andq	$(PTRS_PER_PUD - 1), %rax
 	jz	ident_complete
 
-	leaq	(level2_spare_pgt - __START_KERNEL_map + _KERNPG_TABLE)(%rbp), %rdx
+	/* only set level2 with out level3 spare */
 	leaq	level3_ident_pgt(%rip), %rbx
+
+set_level2_spare:
+	leaq	(level2_spare_pgt - __START_KERNEL_map + _KERNPG_TABLE)(%rbp), %rdx
 	movq	%rdx, 0(%rbx, %rax, 8)
 
 	movq	%rdi, %rax
@@ -435,6 +452,9 @@ NEXT_PAGE(level2_kernel_pgt)
 	PMDS(0, __PAGE_KERNEL_LARGE_EXEC,
 		KERNEL_IMAGE_SIZE/PMD_SIZE)
 
+NEXT_PAGE(level3_spare_pgt)
+	.fill   512, 8, 0
+
 NEXT_PAGE(level2_spare_pgt)
 	.fill   512, 8, 0
 
-- 
1.7.7

[PATCH v2 06/13] x86: Merge early_reserve_initrd for 32bit and 64bit

[Yinghai Lu]

They are the same, could move them out from head32/64.c to setup.c.

We are using memblock, and it could handle overlapping properly, so
we don't need to reserve some at first to hold the location, and just
need to make sure we reserve them before we are using memblock to find
free mem to use.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
 arch/x86/kernel/head32.c |   11 -----------
 arch/x86/kernel/head64.c |   11 -----------
 arch/x86/kernel/setup.c  |   22 ++++++++++++++++++----
 3 files changed, 18 insertions(+), 26 deletions(-)

diff --git a/arch/x86/kernel/head32.c b/arch/x86/kernel/head32.c
index c18f59d..4c52efc 100644
--- a/arch/x86/kernel/head32.c
+++ b/arch/x86/kernel/head32.c
@@ -33,17 +33,6 @@ void __init i386_start_kernel(void)
 	memblock_reserve(__pa_symbol(&_text),
 			 __pa_symbol(&__bss_stop) - __pa_symbol(&_text));
 
-#ifdef CONFIG_BLK_DEV_INITRD
-	/* Reserve INITRD */
-	if (boot_params.hdr.type_of_loader && boot_params.hdr.ramdisk_image) {
-		/* Assume only end is not page aligned */
-		u64 ramdisk_image = boot_params.hdr.ramdisk_image;
-		u64 ramdisk_size  = boot_params.hdr.ramdisk_size;
-		u64 ramdisk_end   = PAGE_ALIGN(ramdisk_image + ramdisk_size);
-		memblock_reserve(ramdisk_image, ramdisk_end - ramdisk_image);
-	}
-#endif
-
 	/* Call the subarch specific early setup function */
 	switch (boot_params.hdr.hardware_subarch) {
 	case X86_SUBARCH_MRST:
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 037df57..00e612a 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -100,17 +100,6 @@ void __init x86_64_start_reservations(char *real_mode_data)
 	memblock_reserve(__pa_symbol(&_text),
 			 __pa_symbol(&__bss_stop) - __pa_symbol(&_text));
 
-#ifdef CONFIG_BLK_DEV_INITRD
-	/* Reserve INITRD */
-	if (boot_params.hdr.type_of_loader && boot_params.hdr.ramdisk_image) {
-		/* Assume only end is not page aligned */
-		unsigned long ramdisk_image = boot_params.hdr.ramdisk_image;
-		unsigned long ramdisk_size  = boot_params.hdr.ramdisk_size;
-		unsigned long ramdisk_end   = PAGE_ALIGN(ramdisk_image + ramdisk_size);
-		memblock_reserve(ramdisk_image, ramdisk_end - ramdisk_image);
-	}
-#endif
-
 	reserve_ebda_region();
 
 	/*
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 6d29d1f..ee6d267 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -364,6 +364,19 @@ static u64 __init get_mem_size(unsigned long limit_pfn)
 
 	return mapped_pages << PAGE_SHIFT;
 }
+static void __init early_reserve_initrd(void)
+{
+	/* Assume only end is not page aligned */
+	u64 ramdisk_image = boot_params.hdr.ramdisk_image;
+	u64 ramdisk_size  = boot_params.hdr.ramdisk_size;
+	u64 ramdisk_end   = PAGE_ALIGN(ramdisk_image + ramdisk_size);
+
+	if (!boot_params.hdr.type_of_loader ||
+	    !ramdisk_image || !ramdisk_size)
+		return;		/* No initrd provided by bootloader */
+
+	memblock_reserve(ramdisk_image, ramdisk_end - ramdisk_image);
+}
 static void __init reserve_initrd(void)
 {
 	/* Assume only end is not page aligned */
@@ -390,10 +403,6 @@ static void __init reserve_initrd(void)
 	if (pfn_range_is_mapped(PFN_DOWN(ramdisk_image),
 				PFN_DOWN(ramdisk_end))) {
 		/* All are mapped, easy case */
-		/*
-		 * don't need to reserve again, already reserved early
-		 * in i386_start_kernel
-		 */
 		initrd_start = ramdisk_image + PAGE_OFFSET;
 		initrd_end = initrd_start + ramdisk_size;
 		return;
@@ -404,6 +413,9 @@ static void __init reserve_initrd(void)
 	memblock_free(ramdisk_image, ramdisk_end - ramdisk_image);
 }
 #else
+static void __init early_reserve_initrd(void)
+{
+}
 static void __init reserve_initrd(void)
 {
 }
@@ -665,6 +677,8 @@ early_param("reservelow", parse_reservelow);
 
 void __init setup_arch(char **cmdline_p)
 {
+	early_reserve_initrd();
+
 #ifdef CONFIG_X86_32
 	memcpy(&boot_cpu_data, &new_cpu_data, sizeof(new_cpu_data));
 	visws_early_detect();
-- 
1.7.7

[PATCH v2 07/13] x86: add get_ramdisk_image/size

[Yinghai Lu]

There several places to find ramdisk information early for reserving
and relocating.

Use functions to make code more readable and consistent.

Later will add ext_ramdisk_image/size in those functions to support
loading ramdisk above 4g.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
 arch/x86/kernel/setup.c |   29 +++++++++++++++++++++--------
 1 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index ee6d267..194e151 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -298,12 +298,25 @@ static void __init reserve_brk(void)
 
 #ifdef CONFIG_BLK_DEV_INITRD
 
+static u64 __init get_ramdisk_image(void)
+{
+	u64 ramdisk_image = boot_params.hdr.ramdisk_image;
+
+	return ramdisk_image;
+}
+static u64 __init get_ramdisk_size(void)
+{
+	u64 ramdisk_size = boot_params.hdr.ramdisk_size;
+
+	return ramdisk_size;
+}
+
 #define MAX_MAP_CHUNK	(NR_FIX_BTMAPS << PAGE_SHIFT)
 static void __init relocate_initrd(void)
 {
 	/* Assume only end is not page aligned */
-	u64 ramdisk_image = boot_params.hdr.ramdisk_image;
-	u64 ramdisk_size  = boot_params.hdr.ramdisk_size;
+	u64 ramdisk_image = get_ramdisk_image();
+	u64 ramdisk_size  = get_ramdisk_size();
 	u64 area_size     = PAGE_ALIGN(ramdisk_size);
 	u64 ramdisk_here;
 	unsigned long slop, clen, mapaddr;
@@ -342,8 +355,8 @@ static void __init relocate_initrd(void)
 		ramdisk_size  -= clen;
 	}
 
-	ramdisk_image = boot_params.hdr.ramdisk_image;
-	ramdisk_size  = boot_params.hdr.ramdisk_size;
+	ramdisk_image = get_ramdisk_image();
+	ramdisk_size  = get_ramdisk_size();
 	printk(KERN_INFO "Move RAMDISK from [mem %#010llx-%#010llx] to"
 		" [mem %#010llx-%#010llx]\n",
 		ramdisk_image, ramdisk_image + ramdisk_size - 1,
@@ -367,8 +380,8 @@ static u64 __init get_mem_size(unsigned long limit_pfn)
 static void __init early_reserve_initrd(void)
 {
 	/* Assume only end is not page aligned */
-	u64 ramdisk_image = boot_params.hdr.ramdisk_image;
-	u64 ramdisk_size  = boot_params.hdr.ramdisk_size;
+	u64 ramdisk_image = get_ramdisk_image();
+	u64 ramdisk_size  = get_ramdisk_size();
 	u64 ramdisk_end   = PAGE_ALIGN(ramdisk_image + ramdisk_size);
 
 	if (!boot_params.hdr.type_of_loader ||
@@ -380,8 +393,8 @@ static void __init early_reserve_initrd(void)
 static void __init reserve_initrd(void)
 {
 	/* Assume only end is not page aligned */
-	u64 ramdisk_image = boot_params.hdr.ramdisk_image;
-	u64 ramdisk_size  = boot_params.hdr.ramdisk_size;
+	u64 ramdisk_image = get_ramdisk_image();
+	u64 ramdisk_size  = get_ramdisk_size();
 	u64 ramdisk_end   = PAGE_ALIGN(ramdisk_image + ramdisk_size);
 	u64 mapped_size;
 
-- 
1.7.7

[PATCH v2 08/13] x86, boot: add get_cmd_line_ptr()

[Yinghai Lu]

later will check ext_cmd_line_ptr at the same time.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
 arch/x86/boot/compressed/cmdline.c |   10 ++++++++--
 arch/x86/kernel/head64.c           |   13 +++++++++++--
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/arch/x86/boot/compressed/cmdline.c b/arch/x86/boot/compressed/cmdline.c
index 10f6b11..b4c913c 100644
--- a/arch/x86/boot/compressed/cmdline.c
+++ b/arch/x86/boot/compressed/cmdline.c
@@ -13,13 +13,19 @@ static inline char rdfs8(addr_t addr)
 	return *((char *)(fs + addr));
 }
 #include "../cmdline.c"
+static unsigned long get_cmd_line_ptr(void)
+{
+	unsigned long cmd_line_ptr = real_mode->hdr.cmd_line_ptr;
+
+	return cmd_line_ptr;
+}
 int cmdline_find_option(const char *option, char *buffer, int bufsize)
 {
-	return __cmdline_find_option(real_mode->hdr.cmd_line_ptr, option, buffer, bufsize);
+	return __cmdline_find_option(get_cmd_line_ptr(), option, buffer, bufsize);
 }
 int cmdline_find_option_bool(const char *option)
 {
-	return __cmdline_find_option_bool(real_mode->hdr.cmd_line_ptr, option);
+	return __cmdline_find_option_bool(get_cmd_line_ptr(), option);
 }
 
 #endif
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 00e612a..3ac6cad 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -41,13 +41,22 @@ static void __init clear_bss(void)
 	       (unsigned long) __bss_stop - (unsigned long) __bss_start);
 }
 
+static unsigned long get_cmd_line_ptr(void)
+{
+	unsigned long cmd_line_ptr = boot_params.hdr.cmd_line_ptr;
+
+	return cmd_line_ptr;
+}
+
 static void __init copy_bootdata(char *real_mode_data)
 {
 	char * command_line;
+	unsigned long cmd_line_ptr;
 
 	memcpy(&boot_params, real_mode_data, sizeof boot_params);
-	if (boot_params.hdr.cmd_line_ptr) {
-		command_line = __va(boot_params.hdr.cmd_line_ptr);
+	cmd_line_ptr = get_cmd_line_ptr();
+	if (cmd_line_ptr) {
+		command_line = __va(cmd_line_ptr);
 		memcpy(boot_command_line, command_line, COMMAND_LINE_SIZE);
 	}
 }
-- 
1.7.7

[PATCH v2 09/13] x86, boot: Don't check if cmd_line_ptr is accessible in misc/decompressor()

[Yinghai Lu]

At that stage, it is already in 32bit protected mode or 64bit mode.
so we do not need to check if ptr less 1M.

When go from other boot loader (kexec) instead of boot/ code path.

Move out accessible checking out __cmdline_find_option....

So misc.c will parse cmdline and have debug print out.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
 arch/x86/boot/boot.h    |   14 ++++++++++++--
 arch/x86/boot/cmdline.c |    8 ++++----
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h
index 18997e5..7fadf80 100644
--- a/arch/x86/boot/boot.h
+++ b/arch/x86/boot/boot.h
@@ -289,12 +289,22 @@ int __cmdline_find_option(u32 cmdline_ptr, const char *option, char *buffer, int
 int __cmdline_find_option_bool(u32 cmdline_ptr, const char *option);
 static inline int cmdline_find_option(const char *option, char *buffer, int bufsize)
 {
-	return __cmdline_find_option(boot_params.hdr.cmd_line_ptr, option, buffer, bufsize);
+	u32 cmd_line_ptr = boot_params.hdr.cmd_line_ptr;
+
+	if (cmd_line_ptr >= 0x100000)
+		return -1;      /* inaccessible */
+
+	return __cmdline_find_option(cmd_line_ptr, option, buffer, bufsize);
 }
 
 static inline int cmdline_find_option_bool(const char *option)
 {
-	return __cmdline_find_option_bool(boot_params.hdr.cmd_line_ptr, option);
+	u32 cmd_line_ptr = boot_params.hdr.cmd_line_ptr;
+
+	if (cmd_line_ptr >= 0x100000)
+		return -1;      /* inaccessible */
+
+	return __cmdline_find_option_bool(cmd_line_ptr, option);
 }
 
 
diff --git a/arch/x86/boot/cmdline.c b/arch/x86/boot/cmdline.c
index 6b3b6f7..768f00f 100644
--- a/arch/x86/boot/cmdline.c
+++ b/arch/x86/boot/cmdline.c
@@ -41,8 +41,8 @@ int __cmdline_find_option(u32 cmdline_ptr, const char *option, char *buffer, int
 		st_bufcpy	/* Copying this to buffer */
 	} state = st_wordstart;
 
-	if (!cmdline_ptr || cmdline_ptr >= 0x100000)
-		return -1;	/* No command line, or inaccessible */
+	if (!cmdline_ptr)
+		return -1;      /* No command line */
 
 	cptr = cmdline_ptr & 0xf;
 	set_fs(cmdline_ptr >> 4);
@@ -111,8 +111,8 @@ int __cmdline_find_option_bool(u32 cmdline_ptr, const char *option)
 		st_wordskip,	/* Miscompare, skip */
 	} state = st_wordstart;
 
-	if (!cmdline_ptr || cmdline_ptr >= 0x100000)
-		return -1;	/* No command line, or inaccessible */
+	if (!cmdline_ptr)
+		return -1;      /* No command line */
 
 	cptr = cmdline_ptr & 0xf;
 	set_fs(cmdline_ptr >> 4);
-- 
1.7.7

[PATCH v2 10/13] x86, boot: update cmd_line_ptr to unsigned long

[Yinghai Lu]

boot/compressed/misc.c could be with 64 bit, and cmd_line_ptr could
above 4g.

So change to unsigned long instead. that will be 64bit in 64bit,
and 32bit in 32bit.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
 arch/x86/boot/boot.h    |    8 ++++----
 arch/x86/boot/cmdline.c |    4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h
index 7fadf80..5b75319 100644
--- a/arch/x86/boot/boot.h
+++ b/arch/x86/boot/boot.h
@@ -285,11 +285,11 @@ struct biosregs {
 void intcall(u8 int_no, const struct biosregs *ireg, struct biosregs *oreg);
 
 /* cmdline.c */
-int __cmdline_find_option(u32 cmdline_ptr, const char *option, char *buffer, int bufsize);
-int __cmdline_find_option_bool(u32 cmdline_ptr, const char *option);
+int __cmdline_find_option(unsigned long cmdline_ptr, const char *option, char *buffer, int bufsize);
+int __cmdline_find_option_bool(unsigned long cmdline_ptr, const char *option);
 static inline int cmdline_find_option(const char *option, char *buffer, int bufsize)
 {
-	u32 cmd_line_ptr = boot_params.hdr.cmd_line_ptr;
+	unsigned long cmd_line_ptr = boot_params.hdr.cmd_line_ptr;
 
 	if (cmd_line_ptr >= 0x100000)
 		return -1;      /* inaccessible */
@@ -299,7 +299,7 @@ static inline int cmdline_find_option(const char *option, char *buffer, int bufs
 
 static inline int cmdline_find_option_bool(const char *option)
 {
-	u32 cmd_line_ptr = boot_params.hdr.cmd_line_ptr;
+	unsigned long cmd_line_ptr = boot_params.hdr.cmd_line_ptr;
 
 	if (cmd_line_ptr >= 0x100000)
 		return -1;      /* inaccessible */
diff --git a/arch/x86/boot/cmdline.c b/arch/x86/boot/cmdline.c
index 768f00f..625d21b 100644
--- a/arch/x86/boot/cmdline.c
+++ b/arch/x86/boot/cmdline.c
@@ -27,7 +27,7 @@ static inline int myisspace(u8 c)
  * Returns the length of the argument (regardless of if it was
  * truncated to fit in the buffer), or -1 on not found.
  */
-int __cmdline_find_option(u32 cmdline_ptr, const char *option, char *buffer, int bufsize)
+int __cmdline_find_option(unsigned long cmdline_ptr, const char *option, char *buffer, int bufsize)
 {
 	addr_t cptr;
 	char c;
@@ -99,7 +99,7 @@ int __cmdline_find_option(u32 cmdline_ptr, const char *option, char *buffer, int
  * Returns the position of that option (starts counting with 1)
  * or 0 on not found
  */
-int __cmdline_find_option_bool(u32 cmdline_ptr, const char *option)
+int __cmdline_find_option_bool(unsigned long cmdline_ptr, const char *option)
 {
 	addr_t cptr;
 	char c;
-- 
1.7.7

[PATCH v2 11/13] x86: use io_remap to access real_mode_data

[Yinghai Lu]

When 64bit bootloader put real mode data above 4g, We can not
access real mode data directly.

because in arch/x86/kernel/head_64.S, only set ident mapping
for 0-1g, and kernel code/data/bss.

So need to move early_ioremap_init() calling from setup_arch
to x86_64_start_kernel.

Also use rsi/rdi instead of esi/edi.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
 arch/x86/kernel/head64.c  |   17 ++++++++++++++---
 arch/x86/kernel/head_64.S |    4 ++--
 arch/x86/kernel/setup.c   |    2 ++
 3 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 3ac6cad..ca00d73 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -52,12 +52,21 @@ static void __init copy_bootdata(char *real_mode_data)
 {
 	char * command_line;
 	unsigned long cmd_line_ptr;
+	char *p;
 
-	memcpy(&boot_params, real_mode_data, sizeof boot_params);
+	/*
+	 * for 64bit bootload path, those data could be above 4G,
+	 * and we do set ident mapping for them in head_64.S.
+	 * So need to ioremap to access them.
+	 */
+	p = early_memremap((unsigned long)real_mode_data, sizeof boot_params);
+	memcpy(&boot_params, p, sizeof boot_params);
+	early_iounmap(p, sizeof boot_params);
 	cmd_line_ptr = get_cmd_line_ptr();
 	if (cmd_line_ptr) {
-		command_line = __va(cmd_line_ptr);
+		command_line = early_memremap(cmd_line_ptr, COMMAND_LINE_SIZE);
 		memcpy(boot_command_line, command_line, COMMAND_LINE_SIZE);
+		early_iounmap(command_line, COMMAND_LINE_SIZE);
 	}
 }
 
@@ -104,7 +113,9 @@ void __init x86_64_start_kernel(char * real_mode_data)
 
 void __init x86_64_start_reservations(char *real_mode_data)
 {
-	copy_bootdata(__va(real_mode_data));
+	early_ioremap_init();
+
+	copy_bootdata(real_mode_data);
 
 	memblock_reserve(__pa_symbol(&_text),
 			 __pa_symbol(&__bss_stop) - __pa_symbol(&_text));
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 32fa9d0..14c5de2 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -262,9 +262,9 @@ ENTRY(secondary_startup_64)
 	movl	initial_gs+4(%rip),%edx
 	wrmsr	
 
-	/* esi is pointer to real mode structure with interesting info.
+	/* rsi is pointer to real mode structure with interesting info.
 	   pass it to C */
-	movl	%esi, %edi
+	movq	%rsi, %rdi
 	
 	/* Finally jump to run C code and to be on real kernel address
 	 * Since we are running on identity-mapped space we have to jump
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 194e151..573fa7d7 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -718,7 +718,9 @@ void __init setup_arch(char **cmdline_p)
 
 	early_trap_init();
 	early_cpu_init();
+#ifdef CONFIG_X86_32
 	early_ioremap_init();
+#endif
 
 	setup_olpc_ofw_pgd();
 
-- 
1.7.7

[PATCH v2 12/13] x86, boot: add fields to support load bzImage and ramdisk high

[Yinghai Lu]

ext_ramdisk_image/size will record high 32bits for ramdisk info.

code64_start_offset will be set for bzImage that support 64bit.

Let get_ramdisk_image/size to use ext_ramdisk_image/size to get
right positon for ramdisk.

bootloader will fill value to ext_ramdisk_image/size when it load
ramdisk high.

Also bootloader will check if code64_start_offset set to decicde if
it could load ramdisk high above 4G.

Update header version to 2.12.

-v2: add ext_cmd_line_ptr for above 4G support.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Rob Landley <rob@landley.net>
Cc: Matt Fleming <matt.fleming@intel.com>
---
 Documentation/x86/boot.txt         |   39 ++++++++++++++++++++++++++++++++++++
 arch/x86/boot/compressed/cmdline.c |    3 ++
 arch/x86/boot/header.S             |    8 ++++++-
 arch/x86/include/asm/bootparam.h   |    4 +++
 arch/x86/kernel/head64.c           |    3 ++
 arch/x86/kernel/setup.c            |    6 +++++
 6 files changed, 62 insertions(+), 1 deletions(-)

diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index 9efceff..bec29e1 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -57,6 +57,9 @@ Protocol 2.10:	(Kernel 2.6.31) Added a protocol for relaxed alignment
 Protocol 2.11:	(Kernel 3.6) Added a field for offset of EFI handover
 		protocol entry point.
 
+Protocol 2.12:	(Kernel 3.9) Added three fields for loading bzImage and
+		 ramdisk above 4G with 64bit.
+
 **** MEMORY LAYOUT
 
 The traditional memory map for the kernel loader, used for Image or
@@ -193,6 +196,10 @@ Offset	Proto	Name		Meaning
 0258/8	2.10+	pref_address	Preferred loading address
 0260/4	2.10+	init_size	Linear memory required during initialization
 0264/4	2.11+	handover_offset	Offset of handover entry point
+0268/4	2.12+	ext_ramdisk_image ramdisk_image 32 bits
+026C/4	2.12+	ext_ramdisk_size ramdisk_size high 32 bits
+0270/4	2.12+   code64_start_offset 64bit start offset for bzImage
+0274/4	2.12+   ext_cmd_line_ptr cmd_line_ptr high 32 bits
 
 (1) For backwards compatibility, if the setup_sects field contains 0, the
     real value is 4.
@@ -707,6 +714,38 @@ Offset/size:	0x264/4
 
   See EFI HANDOVER PROTOCOL below for more details.
 
+Field name:	ext_ramdisk_image
+Type:		write
+Offset/size:	0x268/4
+Protocol:	2.12+
+
+  The high 32-bit linear address of the initial ramdisk or ramfs.  Leave at
+  zero if there is no initial ramdisk/ramfs, or under 4G.
+
+Field name:	ext_ramdisk_size
+Type:		write
+Offset/size:	0x26c/4
+Protocol:	2.12+
+
+  High 32-bit size of the initial ramdisk or ramfs.  Leave at zero if there
+  is no initial ramdisk/ramfs.
+
+Field name:	code64_start_offset
+Type:		modify (reloc)
+Offset/size:	0x270/4
+Protocol:	2.12+
+
+  The offset of 64bit code to start.  It is offset to the load address
+  of the kernel, and can be used by the boot loader to determine if
+  the bzImage is for 64bit. 64bit loader could jump to load address
+  plus the offset directly.
+
+Field name:	ext_cmd_line_ptr
+Type:		write
+Offset/size:	0x274/4
+Protocol:	2.12+
+
+  cmd_line_ptr high 32 bits. Leave at zero if under 4G.
 
 **** THE IMAGE CHECKSUM
 
diff --git a/arch/x86/boot/compressed/cmdline.c b/arch/x86/boot/compressed/cmdline.c
index b4c913c..00678d3 100644
--- a/arch/x86/boot/compressed/cmdline.c
+++ b/arch/x86/boot/compressed/cmdline.c
@@ -17,6 +17,9 @@ static unsigned long get_cmd_line_ptr(void)
 {
 	unsigned long cmd_line_ptr = real_mode->hdr.cmd_line_ptr;
 
+	if (real_mode->hdr.version >= 0x020c)
+		cmd_line_ptr |= (u64)real_mode->hdr.ext_cmd_line_ptr << 32;
+
 	return cmd_line_ptr;
 }
 int cmdline_find_option(const char *option, char *buffer, int bufsize)
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 2a01744..0fcff87 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -279,7 +279,7 @@ _start:
 	# Part 2 of the header, from the old setup.S
 
 		.ascii	"HdrS"		# header signature
-		.word	0x020b		# header version number (>= 0x0105)
+		.word	0x020c		# header version number (>= 0x0105)
 					# or else old loadlin-1.5 will fail)
 		.globl realmode_swtch
 realmode_swtch:	.word	0, 0		# default_switch, SETUPSEG
@@ -400,6 +400,12 @@ init_size:		.long INIT_SIZE		# kernel initialization size
 handover_offset:	.long 0x30		# offset to the handover
 						# protocol entry point
 
+ext_ramdisk_image:	.long	0	# ramdisk_image high 32 bits
+ext_ramdisk_size:	.long	0	# ramdisk_size high 32 bits
+code64_start_offset:	.long	BOOT_CODE64_START_OFFSET	# startup_64 in
+					# arch/x86/boot/compressed/head_64.S
+ext_cmd_line_ptr:	.long	0	# cmd_line_ptr high 32 bits.
+
 # End of setup header #####################################################
 
 	.section ".entrytext", "ax"
diff --git a/arch/x86/include/asm/bootparam.h b/arch/x86/include/asm/bootparam.h
index 2ad874c..8068191 100644
--- a/arch/x86/include/asm/bootparam.h
+++ b/arch/x86/include/asm/bootparam.h
@@ -67,6 +67,10 @@ struct setup_header {
 	__u64	pref_address;
 	__u32	init_size;
 	__u32	handover_offset;
+	__u32	ext_ramdisk_image;
+	__u32	ext_ramdisk_size;
+	__u32	code64_start_offset;
+	__u32	ext_cmd_line_ptr;
 } __attribute__((packed));
 
 struct sys_desc_table {
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index ca00d73..e82001e 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -45,6 +45,9 @@ static unsigned long get_cmd_line_ptr(void)
 {
 	unsigned long cmd_line_ptr = boot_params.hdr.cmd_line_ptr;
 
+	if (boot_params.hdr.version >= 0x020c)
+		cmd_line_ptr |= (u64)boot_params.hdr.ext_cmd_line_ptr << 32;
+
 	return cmd_line_ptr;
 }
 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 573fa7d7..6a0ffa3 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -302,12 +302,18 @@ static u64 __init get_ramdisk_image(void)
 {
 	u64 ramdisk_image = boot_params.hdr.ramdisk_image;
 
+	if (boot_params.hdr.version >= 0x020c)
+		ramdisk_image |= (u64)boot_params.hdr.ext_ramdisk_image << 32;
+
 	return ramdisk_image;
 }
 static u64 __init get_ramdisk_size(void)
 {
 	u64 ramdisk_size = boot_params.hdr.ramdisk_size;
 
+	if (boot_params.hdr.version >= 0x020c)
+		ramdisk_size |= (u64)boot_params.hdr.ext_ramdisk_size << 32;
+
 	return ramdisk_size;
 }
 
-- 
1.7.7

[PATCH v2 13/13] x86: remove 1024g limitation for kexec buffer on 64bit

[Yinghai Lu]

Now 64bit kernel supports more than 1T ram and kexec tools
could find buffer above 1T, remove that obsolete limitation.
and use MAXMEM instead.

Tested on system more than 1024g ram.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
---
 arch/x86/include/asm/kexec.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index 317ff17..11bfdc5 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -48,11 +48,11 @@
 # define vmcore_elf_check_arch_cross(x) ((x)->e_machine == EM_X86_64)
 #else
 /* Maximum physical address we can use pages from */
-# define KEXEC_SOURCE_MEMORY_LIMIT      (0xFFFFFFFFFFUL)
+# define KEXEC_SOURCE_MEMORY_LIMIT      (MAXMEM-1)
 /* Maximum address we can reach in physical address mode */
-# define KEXEC_DESTINATION_MEMORY_LIMIT (0xFFFFFFFFFFUL)
+# define KEXEC_DESTINATION_MEMORY_LIMIT (MAXMEM-1)
 /* Maximum address we can use for the control pages */
-# define KEXEC_CONTROL_MEMORY_LIMIT     (0xFFFFFFFFFFUL)
+# define KEXEC_CONTROL_MEMORY_LIMIT     (MAXMEM-1)
 
 /* Allocate one page for the pdp and the second for the code */
 # define KEXEC_CONTROL_PAGE_SIZE  (4096UL + 4096UL)
-- 
1.7.7

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[H. Peter Anvin]

On 11/17/2012 11:09 PM, Yinghai Lu wrote:
> We will add one 64bit entry for bzImage in boot header struct.
> 
> the contents in that field will be offset of startup_64.
> 
> Add macro for offset of startup_64 to keep two places consistent.
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> Cc: Matt Fleming <matt.fleming@intel.com>
> ---
>  arch/x86/boot/compressed/head_64.S |    2 +-
>  arch/x86/include/asm/boot.h        |    2 ++
>  2 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
> index 375af23..e4964dd 100644
> --- a/arch/x86/boot/compressed/head_64.S
> +++ b/arch/x86/boot/compressed/head_64.S
> @@ -195,7 +195,7 @@ no_longmode:
>  	 * it may change in the future.
>  	 */
>  	.code64
> -	.org 0x200
> +	.org BOOT_CODE64_START_OFFSET
>  ENTRY(startup_64)
>  	/*
>  	 * We come here either from startup_32 or directly from a
> diff --git a/arch/x86/include/asm/boot.h b/arch/x86/include/asm/boot.h
> index b13fe63..ef36497 100644
> --- a/arch/x86/include/asm/boot.h
> +++ b/arch/x86/include/asm/boot.h
> @@ -38,8 +38,10 @@
>  
>  #ifdef CONFIG_X86_64
>  #define BOOT_STACK_SIZE	0x4000
> +#define BOOT_CODE64_START_OFFSET 0x200
>  #else
>  #define BOOT_STACK_SIZE	0x1000
> +#define BOOT_CODE64_START_OFFSET 0
>  #endif
>  

We can't change the 0x200 value, ever, because there are already things
that use the 64-bit entry point.  As such, these macros and the bzImage
fields are pointless; let's not bother and instead document the 0x200 as
the permanently fixed address of the 64-bit entry point.

	-hpa

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[Yinghai Lu]

On Mon, Nov 19, 2012 at 2:42 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 11/17/2012 11:09 PM, Yinghai Lu wrote:
>> We will add one 64bit entry for bzImage in boot header struct.
>>
>> the contents in that field will be offset of startup_64.
>>
>> Add macro for offset of startup_64 to keep two places consistent.
>>
>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>> Cc: Matt Fleming <matt.fleming@intel.com>
>> ---
>>  arch/x86/boot/compressed/head_64.S |    2 +-
>>  arch/x86/include/asm/boot.h        |    2 ++
>>  2 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
>> index 375af23..e4964dd 100644
>> --- a/arch/x86/boot/compressed/head_64.S
>> +++ b/arch/x86/boot/compressed/head_64.S
>> @@ -195,7 +195,7 @@ no_longmode:
>>        * it may change in the future.
>>        */
>>       .code64
>> -     .org 0x200
>> +     .org BOOT_CODE64_START_OFFSET
>>  ENTRY(startup_64)
>>       /*
>>        * We come here either from startup_32 or directly from a
>> diff --git a/arch/x86/include/asm/boot.h b/arch/x86/include/asm/boot.h
>> index b13fe63..ef36497 100644
>> --- a/arch/x86/include/asm/boot.h
>> +++ b/arch/x86/include/asm/boot.h
>> @@ -38,8 +38,10 @@
>>
>>  #ifdef CONFIG_X86_64
>>  #define BOOT_STACK_SIZE      0x4000
>> +#define BOOT_CODE64_START_OFFSET 0x200
>>  #else
>>  #define BOOT_STACK_SIZE      0x1000
>> +#define BOOT_CODE64_START_OFFSET 0
>>  #endif
>>
>
> We can't change the 0x200 value, ever, because there are already things
> that use the 64-bit entry point.  As such, these macros and the bzImage
> fields are pointless; let's not bother and instead document the 0x200 as
> the permanently fixed address of the 64-bit entry point.

ok,

any other field, in header struct field that we can use to tell
bzImage could be used that
0x200 directly?

hardware_subarch?

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[H. Peter Anvin]

On 11/19/2012 02:53 PM, Yinghai Lu wrote:
>>
>> We can't change the 0x200 value, ever, because there are already things
>> that use the 64-bit entry point.  As such, these macros and the bzImage
>> fields are pointless; let's not bother and instead document the 0x200 as
>> the permanently fixed address of the 64-bit entry point.
> 
> ok,
> 
> any other field, in header struct field that we can use to tell
> bzImage could be used that
> 0x200 directly?
> 
> hardware_subarch?
> 

There isn't one... this dates back all the way to the original x86-64
kernels.

Are you asking if we can tell this is a 64-bit kernel (as opposed to a
32-bit kernel, which obviously doesn't have a 64-bit entry point)?
Unfortunately there isn't an intentional one that I know of.  There
might be an accidental such indicator, but we'd have to go back to look
at 8+ years of kernels.  We can't even rely on a jmp instruction at the
address...

	-hpa

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[Yinghai Lu]

On Mon, Nov 19, 2012 at 3:13 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 11/19/2012 02:53 PM, Yinghai Lu wrote:
>>
>> any other field, in header struct field that we can use to tell
>> bzImage could be used that
>> 0x200 directly?
>>
>> hardware_subarch?
>>
>
> There isn't one... this dates back all the way to the original x86-64
> kernels.
>
> Are you asking if we can tell this is a 64-bit kernel (as opposed to a
> 32-bit kernel, which obviously doesn't have a 64-bit entry point)?
> Unfortunately there isn't an intentional one that I know of.  There
> might be an accidental such indicator, but we'd have to go back to look
> at 8+ years of kernels.  We can't even rely on a jmp instruction at the
> address...

So we could add one field to tell that bzImage could be used with 64bit?

current in this patchset, I added

0268/4  2.12+   ext_ramdisk_image ramdisk_image 32 bits
026C/4  2.12+   ext_ramdisk_size ramdisk_size high 32 bits
0270/4  2.12+   code64_start_offset 64bit start offset for bzImage
0274/4  2.12+   ext_cmd_line_ptr cmd_line_ptr high 32 bits

so you don't like code64_start_offset.

how about other three?

can we use bits 31 of hardware_subarch to tell it is bzImage for x86_64?

Thanks

Yinghai

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[H. Peter Anvin]

We probably should add a flag for those, but that is more of a boot_flag...

Yinghai Lu <yinghai@kernel.org> wrote:

>On Mon, Nov 19, 2012 at 3:13 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 11/19/2012 02:53 PM, Yinghai Lu wrote:
>>>
>>> any other field, in header struct field that we can use to tell
>>> bzImage could be used that
>>> 0x200 directly?
>>>
>>> hardware_subarch?
>>>
>>
>> There isn't one... this dates back all the way to the original x86-64
>> kernels.
>>
>> Are you asking if we can tell this is a 64-bit kernel (as opposed to
>a
>> 32-bit kernel, which obviously doesn't have a 64-bit entry point)?
>> Unfortunately there isn't an intentional one that I know of.  There
>> might be an accidental such indicator, but we'd have to go back to
>look
>> at 8+ years of kernels.  We can't even rely on a jmp instruction at
>the
>> address...
>
>So we could add one field to tell that bzImage could be used with
>64bit?
>
>current in this patchset, I added
>
>0268/4  2.12+   ext_ramdisk_image ramdisk_image 32 bits
>026C/4  2.12+   ext_ramdisk_size ramdisk_size high 32 bits
>0270/4  2.12+   code64_start_offset 64bit start offset for bzImage
>0274/4  2.12+   ext_cmd_line_ptr cmd_line_ptr high 32 bits
>
>so you don't like code64_start_offset.
>
>how about other three?
>
>can we use bits 31 of hardware_subarch to tell it is bzImage for
>x86_64?
>
>Thanks
>
>Yinghai

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[Yinghai Lu]

On Mon, Nov 19, 2012 at 3:55 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> We probably should add a flag for those, but that is more of a boot_flag...

kernel_cap_bits:
RAMDISK_ABOVE_4G  = (1<<0)
KERNEL_ABOVE_4G =(1<<2)
CMD_LINE_ABOVE 4G = (1<<1)
                .long   (RAMDISK_ABOVE_4G | CMD_LINE_ABOVE_4G | KERNEL_ABOVE_4G)

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[Yinghai Lu]

On Mon, Nov 19, 2012 at 4:39 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Mon, Nov 19, 2012 at 3:55 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> We probably should add a flag for those, but that is more of a boot_flag...
>
> kernel_cap_bits:
> RAMDISK_ABOVE_4G  = (1<<0)
> KERNEL_ABOVE_4G =(1<<2)
> CMD_LINE_ABOVE 4G = (1<<1)
>                 .long   (RAMDISK_ABOVE_4G | CMD_LINE_ABOVE_4G | KERNEL_ABOVE_4G)

more complete version:

kernel_cap_bits:
RAMDISK_ABOVE_4G  = (1<<0)
KERNEL_ABOVE_4G =(1<<1)
BOOT_PARAMS_ABOVE_4G=(1<<2)
CMD_LINE_ABOVE 4G = (1<<3)
                .long   (RAMDISK_ABOVE_4G | BOOT_PARAMS_ABOVE_4G |
CMD_LINE_ABOVE_4G | KERNEL_ABOVE_4G)

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[H. Peter Anvin]

I don't see any point in three flags here.  Let's stick to one flag; then it fits in the existing boot_flags field.

Yinghai Lu <yinghai@kernel.org> wrote:

>On Mon, Nov 19, 2012 at 4:39 PM, Yinghai Lu <yinghai@kernel.org> wrote:
>> On Mon, Nov 19, 2012 at 3:55 PM, H. Peter Anvin <hpa@zytor.com>
>wrote:
>>> We probably should add a flag for those, but that is more of a
>boot_flag...
>>
>> kernel_cap_bits:
>> RAMDISK_ABOVE_4G  = (1<<0)
>> KERNEL_ABOVE_4G =(1<<2)
>> CMD_LINE_ABOVE 4G = (1<<1)
>>                 .long   (RAMDISK_ABOVE_4G | CMD_LINE_ABOVE_4G |
>KERNEL_ABOVE_4G)
>
>more complete version:
>
>kernel_cap_bits:
>RAMDISK_ABOVE_4G  = (1<<0)
>KERNEL_ABOVE_4G =(1<<1)
>BOOT_PARAMS_ABOVE_4G=(1<<2)
>CMD_LINE_ABOVE 4G = (1<<3)
>                .long   (RAMDISK_ABOVE_4G | BOOT_PARAMS_ABOVE_4G |
>CMD_LINE_ABOVE_4G | KERNEL_ABOVE_4G)

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[Yinghai Lu]

On Tue, Nov 20, 2012 at 12:44 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> I don't see any point in three flags here.  Let's stick to one flag; then it fits in the existing boot_flags field.

the magic AA55

boot/header.S:boot_flag:        .word 0xAA55

if change that to other value, would it break existing boot loader?
aka old boot loader could boot the new bzImage anymore.

Thanks

Yinghai

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[H. Peter Anvin]

On 11/20/2012 12:55 PM, Yinghai Lu wrote:
> On Tue, Nov 20, 2012 at 12:44 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> I don't see any point in three flags here.  Let's stick to one flag; then it fits in the existing boot_flags field.
>
> the magic AA55
>
> boot/header.S:boot_flag:        .word 0xAA55
>
> if change that to other value, would it break existing boot loader?
> aka old boot loader could boot the new bzImage anymore.
>

Sorry, I meant loadflags.

This is a read flag and so should be low, bit 1 presumably.

On the other hand, the read flags in loadflags has not been modified for 
a very long time, and there is a serious risk that some broken 
bootloader might be doing a full byte comparison.

relocatable_kernel really should have been a flag, but it is now defined 
as a comparison with zero.  As such, and in an effort to minimize the 
growth of struct setup_header (it is limited to little over 128 bytes 
long) I suggest we redefine the 16-byte field at offset 0x236 as a new 
flags field.  We still only need one flag, though.

Backwards compatibility is so much fun.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[Yinghai Lu]

On Tue, Nov 20, 2012 at 1:12 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 11/20/2012 12:55 PM, Yinghai Lu wrote:
>>
>> On Tue, Nov 20, 2012 at 12:44 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>>
>>> I don't see any point in three flags here.  Let's stick to one flag; then
>>> it fits in the existing boot_flags field.
>>
>>
>> the magic AA55
>>
>> boot/header.S:boot_flag:        .word 0xAA55
>>
>> if change that to other value, would it break existing boot loader?
>> aka old boot loader could boot the new bzImage anymore.
>>
>
> Sorry, I meant loadflags.
>
> This is a read flag and so should be low, bit 1 presumably.

yes.

Field name:     loadflags
Type:           modify (obligatory)
Offset/size:    0x211/1
Protocol:       2.00+

  This field is a bitmask.

  Bit 0 (read): LOADED_HIGH
        - If 0, the protected-mode code is loaded at 0x10000.
        - If 1, the protected-mode code is loaded at 0x100000.

  Bit 5 (write): QUIET_FLAG
        - If 0, print early messages.
        - If 1, suppress early messages.
                This requests to the kernel (decompressor and early
                kernel) to not write early messages that require
                accessing the display hardware directly.

  Bit 6 (write): KEEP_SEGMENTS
        Protocol: 2.07+
        - If 0, reload the segment registers in the 32bit entry point.
        - If 1, do not reload the segment registers in the 32bit entry point.
                Assume that %cs %ds %ss %es are all set to flat segments with
                a base of 0 (or the equivalent for their environment).

  Bit 7 (write): CAN_USE_HEAP
        Set this bit to 1 to indicate that the value entered in the
        heap_end_ptr is valid.  If this field is clear, some setup code
        functionality will be disabled.


So will have
  Bit 1 (read): LOADED_ABOVE_4G
  - If 1, code, boot_param, cmdline, ramdisk could be loaded above 4G,

will update the patches accordingly.

>
> On the other hand, the read flags in loadflags has not been modified for a
> very long time, and there is a serious risk that some broken bootloader
> might be doing a full byte comparison.
>
> relocatable_kernel really should have been a flag, but it is now defined as
> a comparison with zero.  As such, and in an effort to minimize the growth of
> struct setup_header (it is limited to little over 128 bytes long) I suggest
> we redefine the 16-byte field at offset 0x236 as a new flags field.  We
> still only need one flag, though.
>
> Backwards compatibility is so much fun.

yes. try to make it ready for future is fun too.

are you going to have pointer for ext_header ?

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[H. Peter Anvin]

On 11/20/2012 04:20 PM, Yinghai Lu wrote:
> 
> So will have
>   Bit 1 (read): LOADED_ABOVE_4G
>   - If 1, code, boot_param, cmdline, ramdisk could be loaded above 4G,
> 
> will update the patches accordingly.
> 

No, read the below.

>>
>> On the other hand, the read flags in loadflags has not been modified for a
>> very long time, and there is a serious risk that some broken bootloader
>> might be doing a full byte comparison.
>>
>> relocatable_kernel really should have been a flag, but it is now defined as
>> a comparison with zero.  As such, and in an effort to minimize the growth of
>> struct setup_header (it is limited to little over 128 bytes long) I suggest
>> we redefine the 16-byte field at offset 0x236 as a new flags field.  We
>> still only need one flag, though.
>>
>> Backwards compatibility is so much fun.
> 
> yes. try to make it ready for future is fun too.
> 
> are you going to have pointer for ext_header ?
> 

No, it doesn't help us much.

Overall, we need to keep growth of struct setup_header under some
control.  The highest usable offset is 0x280.

	-hpa

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[Yinghai Lu]

On Tue, Nov 20, 2012 at 4:28 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 11/20/2012 04:20 PM, Yinghai Lu wrote:
>>
>>> relocatable_kernel really should have been a flag, but it is now defined as
>>> a comparison with zero.  As such, and in an effort to minimize the growth of
>>> struct setup_header (it is limited to little over 128 bytes long) I suggest
>>> we redefine the 16-byte field at offset 0x236 as a new flags field.  We
>>> still only need one flag, though.

ok will use 0x236.

Thanks

Yinghai

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[Yinghai Lu]

On Tue, Nov 20, 2012 at 4:32 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Tue, Nov 20, 2012 at 4:28 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 11/20/2012 04:20 PM, Yinghai Lu wrote:
>>>
>>>> relocatable_kernel really should have been a flag, but it is now defined as
>>>> a comparison with zero.  As such, and in an effort to minimize the growth of
>>>> struct setup_header (it is limited to little over 128 bytes long) I suggest
>>>> we redefine the 16-byte field at offset 0x236 as a new flags field.  We
>>>> still only need one flag, though.
>
> ok will use 0x236.

how to call it?

boot_flag2 ?

Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64

[H. Peter Anvin]

On 11/20/2012 04:34 PM, Yinghai Lu wrote:
> On Tue, Nov 20, 2012 at 4:32 PM, Yinghai Lu <yinghai@kernel.org> wrote:
>> On Tue, Nov 20, 2012 at 4:28 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 11/20/2012 04:20 PM, Yinghai Lu wrote:
>>>>
>>>>> relocatable_kernel really should have been a flag, but it is now defined as
>>>>> a comparison with zero.  As such, and in an effort to minimize the growth of
>>>>> struct setup_header (it is limited to little over 128 bytes long) I suggest
>>>>> we redefine the 16-byte field at offset 0x236 as a new flags field.  We
>>>>> still only need one flag, though.
>>
>> ok will use 0x236.
> 
> how to call it?
> 
> boot_flag2 ?
> 

Lets say "xloadflags".

	-hpa