[PATCH 0/9] x86, boot, 64bit: Add support for loading ramdisk and bzImage high

[PATCH 0/9] 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, will send kexec
tools change to kexec list later.

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

Thanks

Yinghai

Yinghai Lu (9):
  x86, boot: Move lldt/ltr out of 64bit only path
  x86: Add macro for 64bit entry for bzImage
  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 field to support load bzImage and ramdisk high
  x86: ramdisk info print with high bits.
  x86: remove 1024g limitation for kexec buffer on 64bit

 Documentation/x86/boot.txt         |    4 ++
 arch/x86/boot/compressed/head_64.S |   11 ++++--
 arch/x86/boot/header.S             |   11 ++++++-
 arch/x86/include/asm/boot.h        |    2 +
 arch/x86/include/asm/bootparam.h   |    3 ++
 arch/x86/include/asm/kexec.h       |    6 ++--
 arch/x86/kernel/head32.c           |   11 ------
 arch/x86/kernel/head64.c           |   11 ------
 arch/x86/kernel/head_64.S          |   45 ++++++++++++++++++++++-----
 arch/x86/kernel/setup.c            |   61 +++++++++++++++++++++++++++--------
 10 files changed, 113 insertions(+), 52 deletions(-)

-- 
1.7.7

[PATCH 1/9] x86, boot: Move lldt/ltr out of 64bit only path

[Yinghai Lu]

commit 08da5a2ca

    x86_64: Early segment setup for VT

add lldt/ltr to clean more segments.

but 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 that
code32 path, because they have different gdt.

Move those lines into code32 after their gdt is loaded.

Also it push down startup_64 to 0x208.

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

diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
index 2c4b171..4c8af67 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
 	 *
@@ -191,7 +197,7 @@ no_longmode:
 	 * it may change in the future.
 	 */
 	.code64
-	.org 0x200
+	.org 0x208
 ENTRY(startup_64)
 	/*
 	 * We come here either from startup_32 or directly from a
@@ -247,9 +253,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 2/9] x86: Add macro for 64bit entry for bzImage

[Yinghai Lu]

will use it with bzImage header.

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 4c8af67..0733638 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -197,7 +197,7 @@ no_longmode:
 	 * it may change in the future.
 	 */
 	.code64
-	.org 0x208
+	.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..bcae405 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 0x208
 #else
 #define BOOT_STACK_SIZE	0x1000
+#define BOOT_CODE64_START_OFFSET 0
 #endif
 
 #endif /* __KERNEL__ */
-- 
1.7.7

[PATCH 3/9] 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 with [_text, _end] for all 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 4/9] 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 one 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 5/9] 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, 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 6/9] x86: add get_ramdisk_image/size

[Yinghai Lu]

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

use functions to make code more readable and consistent.

later will add ext_ramdisk_image/size with 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 7/9] x86, boot: add field 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.

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       |    4 ++++
 arch/x86/boot/header.S           |   11 ++++++++++-
 arch/x86/include/asm/bootparam.h |    3 +++
 arch/x86/kernel/setup.c          |    6 ++++++
 4 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index 9efceff..26c7dcc 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -193,6 +193,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 initrd load address high 32 bits
+				(set by boot loader)
+026C/4	2.12+	ext_ramdisk_size initrd size high 32 bits (set by boot loader)
+0270/4	2.12+   code64_start_offset 64bit start offset for bzImage
 
 (1) For backwards compatibility, if the setup_sects field contains 0, the
     real value is 4.
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 2a01744..85ce1a4 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,15 @@ init_size:		.long INIT_SIZE		# kernel initialization size
 handover_offset:	.long 0x30		# offset to the handover
 						# protocol entry point
 
+ext_ramdisk_image:	.long	0	# address of loaded ramdisk image
+					# Here the loader puts the high 32 bits
+					# address where it loaded the image.
+					# This only will be read by the kernel.
+
+ext_ramdisk_size:	.long	0	# its size in bytes high 32 bits.
+code64_start_offset:	.long	BOOT_CODE64_START_OFFSET	# startup_64 in
+					# arch/x86/boot/compressed/head_64.S
+
 # 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..4e42fd1 100644
--- a/arch/x86/include/asm/bootparam.h
+++ b/arch/x86/include/asm/bootparam.h
@@ -67,6 +67,9 @@ struct setup_header {
 	__u64	pref_address;
 	__u32	init_size;
 	__u32	handover_offset;
+	__u32	ext_ramdisk_image;
+	__u32	ext_ramdisk_size;
+	__u32	code64_start_offset;
 } __attribute__((packed));
 
 struct sys_desc_table {
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 194e151..c2eb535 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 8/9] x86: ramdisk info print with high bits.

[Yinghai Lu]

ramdisk could be loaded high now for 64bit.

So need to print more digits for them.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Matt Fleming <matt.fleming@intel.com>
---
 arch/x86/kernel/setup.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index c2eb535..0e13c6e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -341,7 +341,7 @@ static void __init relocate_initrd(void)
 	memblock_reserve(ramdisk_here, area_size);
 	initrd_start = ramdisk_here + PAGE_OFFSET;
 	initrd_end   = initrd_start + ramdisk_size;
-	printk(KERN_INFO "Allocated new RAMDISK: [mem %#010llx-%#010llx]\n",
+	printk(KERN_INFO "Allocated new RAMDISK: [mem %#018llx-%#018llx]\n",
 			 ramdisk_here, ramdisk_here + ramdisk_size - 1);
 
 	q = (char *)initrd_start;
@@ -363,8 +363,8 @@ static void __init relocate_initrd(void)
 
 	ramdisk_image = get_ramdisk_image();
 	ramdisk_size  = get_ramdisk_size();
-	printk(KERN_INFO "Move RAMDISK from [mem %#010llx-%#010llx] to"
-		" [mem %#010llx-%#010llx]\n",
+	printk(KERN_INFO "Move RAMDISK from [mem %#018llx-%#018llx] to"
+		" [mem %#018llx-%#018llx]\n",
 		ramdisk_image, ramdisk_image + ramdisk_size - 1,
 		ramdisk_here, ramdisk_here + ramdisk_size - 1);
 }
@@ -416,7 +416,7 @@ static void __init reserve_initrd(void)
 		       "disabling initrd (%lld needed, %lld available)\n",
 		       ramdisk_size, mapped_size>>1);
 
-	printk(KERN_INFO "RAMDISK: [mem %#010llx-%#010llx]\n", ramdisk_image,
+	printk(KERN_INFO "RAMDISK: [mem %#018llx-%#018llx]\n", ramdisk_image,
 			ramdisk_end - 1);
 
 	if (pfn_range_is_mapped(PFN_DOWN(ramdisk_image),
-- 
1.7.7

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

[Yinghai Lu]

could find buffer above that, remove that obsolete limitation.
use MAXMEM instead.

Tested on sytem 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 1/9] x86, boot: Move lldt/ltr out of 64bit only path

[H. Peter Anvin]

On 11/16/2012 12:53 AM, Yinghai Lu wrote:
> 
> Also it push down startup_64 to 0x208.
> 

NAK.  0x200 is an ABI, you can't change it.

	-hpa

Re: [PATCH 2/9] x86: Add macro for 64bit entry for bzImage

[H. Peter Anvin]

On 11/16/2012 12:53 AM, Yinghai Lu wrote:
> will use it with bzImage header.

This isn't really a decent description.  The subject line should stand
alone from the patch comment.  Think of it as a newspaper headline
versus the newspaper article.

	-hpa

Re: [PATCH 8/9] x86: ramdisk info print with high bits.

[H. Peter Anvin]

On 11/16/2012 12:53 AM, Yinghai Lu wrote:
> ramdisk could be loaded high now for 64bit.
> 
> So need to print more digits for them.
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> Cc: Matt Fleming <matt.fleming@intel.com>
> ---
>  arch/x86/kernel/setup.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index c2eb535..0e13c6e 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -341,7 +341,7 @@ static void __init relocate_initrd(void)
>  	memblock_reserve(ramdisk_here, area_size);
>  	initrd_start = ramdisk_here + PAGE_OFFSET;
>  	initrd_end   = initrd_start + ramdisk_size;
> -	printk(KERN_INFO "Allocated new RAMDISK: [mem %#010llx-%#010llx]\n",
> +	printk(KERN_INFO "Allocated new RAMDISK: [mem %#018llx-%#018llx]\n",
>  			 ramdisk_here, ramdisk_here + ramdisk_size - 1);

NAK, this is expected to match the resource print format (%pR), which
prints 10 digits by default and then expands.  Furthermore, printing
*18* digits is downright silly since we still don't have 72-bit addressing.

	-hpa

Re: [PATCH 0/9] x86, boot, 64bit: Add support for loading ramdisk and bzImage high

[H. Peter Anvin]

On 11/16/2012 12:53 AM, Yinghai Lu wrote:
> 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, will send kexec
> tools change to kexec list later.
> 
> 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
> 

Mostly a good series, but the 0x208 is a showstopper.  0x200 is awkward
as an ABI (too big to just make a jump table, but potentially too small
to hold all the code needed.)  I have sent some other comments, too.

If 0x200 is too small, it isn't a huge problem; we can put a jump at
0x200 and continue the 32-bit code afterwards:


	/* 32-bit code */

	jmp	1f

	.org	0x200
	.code64
ENTRY(startup_64)
	jmp	start_64_real

	.code32
1:
	/* 32-bit code continues... */


It is annoying because it has to be placed by hand, but isn't actually a
problem.  The easy way to do this is probably to push verify_cpu.S into
the post-entry-point area.  The .code64/.code32 don't actually do
anything for a simple jmp, but are added for documentation.

How is collecting comments and ACKs for for-x86-mm coming?  I'd like to
do another review pass today and putting it in -tip if it is in better
shape.  Otherwise I suspect we'll be looking at 3.9, which is OK, of course.

	-hpa

Re: [PATCH 1/9] x86, boot: Move lldt/ltr out of 64bit only path

[Yinghai Lu]

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

On Fri, Nov 16, 2012 at 7:55 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 11/16/2012 12:53 AM, Yinghai Lu wrote:
>>
>> Also it push down startup_64 to 0x208.
>>
>
> NAK.  0x200 is an ABI, you can't change it.
>

ok, will add attached patche before this one and keep 0x200.

Thanks

Yinghai

[-- Attachment #2: move_verify_cpu.patch --]
[-- Type: application/octet-stream, Size: 913 bytes --]

Subject: [PATCH] x86, boot: move verify_cpu.S after 0x200

We are short of space before 0x200 for startup_64.

before that are 32 bit code. We could move function verify_cpu down

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/boot/compressed/head_64.S |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux-2.6/arch/x86/boot/compressed/head_64.S
===================================================================
--- linux-2.6.orig/arch/x86/boot/compressed/head_64.S
+++ linux-2.6/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

Re: [PATCH 8/9] x86: ramdisk info print with high bits.

[Yinghai Lu]

On Fri, Nov 16, 2012 at 8:05 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 11/16/2012 12:53 AM, Yinghai Lu wrote:
>> ramdisk could be loaded high now for 64bit.
>>
>> So need to print more digits for them.
>>
>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>> Cc: Matt Fleming <matt.fleming@intel.com>
>> ---
>>  arch/x86/kernel/setup.c |    8 ++++----
>>  1 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index c2eb535..0e13c6e 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -341,7 +341,7 @@ static void __init relocate_initrd(void)
>>       memblock_reserve(ramdisk_here, area_size);
>>       initrd_start = ramdisk_here + PAGE_OFFSET;
>>       initrd_end   = initrd_start + ramdisk_size;
>> -     printk(KERN_INFO "Allocated new RAMDISK: [mem %#010llx-%#010llx]\n",
>> +     printk(KERN_INFO "Allocated new RAMDISK: [mem %#018llx-%#018llx]\n",
>>                        ramdisk_here, ramdisk_here + ramdisk_size - 1);
>
> NAK, this is expected to match the resource print format (%pR), which
> prints 10 digits by default and then expands.  Furthermore, printing
> *18* digits is downright silly since we still don't have 72-bit addressing.

that is the same as in e820_print_map::

                printk(KERN_INFO "%s: [mem %#018Lx-%#018Lx] ", who,
                       (unsigned long long) e820.map[i].addr,
                       (unsigned long long)
                       (e820.map[i].addr + e820.map[i].size - 1));


that is for 64bit address.

that extra 2 is for "0x"

or you prefer to cast them to pointer and use %pR for them all?

or fix printk to add extra 2 for "0x" when # is found?

Re: [PATCH 8/9] x86: ramdisk info print with high bits.

[Yinghai Lu]

On Fri, Nov 16, 2012 at 11:21 AM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Fri, Nov 16, 2012 at 8:05 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 11/16/2012 12:53 AM, Yinghai Lu wrote:
>>> ramdisk could be loaded high now for 64bit.
>>>
>>> So need to print more digits for them.
>>>
>>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>>> Cc: Matt Fleming <matt.fleming@intel.com>
>>> ---
>>>  arch/x86/kernel/setup.c |    8 ++++----
>>>  1 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>>> index c2eb535..0e13c6e 100644
>>> --- a/arch/x86/kernel/setup.c
>>> +++ b/arch/x86/kernel/setup.c
>>> @@ -341,7 +341,7 @@ static void __init relocate_initrd(void)
>>>       memblock_reserve(ramdisk_here, area_size);
>>>       initrd_start = ramdisk_here + PAGE_OFFSET;
>>>       initrd_end   = initrd_start + ramdisk_size;
>>> -     printk(KERN_INFO "Allocated new RAMDISK: [mem %#010llx-%#010llx]\n",
>>> +     printk(KERN_INFO "Allocated new RAMDISK: [mem %#018llx-%#018llx]\n",
>>>                        ramdisk_here, ramdisk_here + ramdisk_size - 1);
>>
>> NAK, this is expected to match the resource print format (%pR), which
>> prints 10 digits by default and then expands.  Furthermore, printing
>> *18* digits is downright silly since we still don't have 72-bit addressing.
>
> that is the same as in e820_print_map::
>
>                 printk(KERN_INFO "%s: [mem %#018Lx-%#018Lx] ", who,
>                        (unsigned long long) e820.map[i].addr,
>                        (unsigned long long)
>                        (e820.map[i].addr + e820.map[i].size - 1));
>
>
> that is for 64bit address.
>
> that extra 2 is for "0x"
>
> or you prefer to cast them to pointer and use %pR for them all?
>
> or fix printk to add extra 2 for "0x" when # is found?

looks like we have lots of %#010llx or %#010Lx there in arch/x86.

We need to fix printk to make it acting like %pR ?

Re: [PATCH 8/9] x86: ramdisk info print with high bits.

[H. Peter Anvin]

On 11/16/2012 11:21 AM, Yinghai Lu wrote:
>>
>> NAK, this is expected to match the resource print format (%pR), which
>> prints 10 digits by default and then expands.  Furthermore, printing
>> *18* digits is downright silly since we still don't have 72-bit addressing.
> 
> that is the same as in e820_print_map::
> 
>                 printk(KERN_INFO "%s: [mem %#018Lx-%#018Lx] ", who,
>                        (unsigned long long) e820.map[i].addr,
>                        (unsigned long long)
>                        (e820.map[i].addr + e820.map[i].size - 1));
> 
> 
> that is for 64bit address.
> that extra 2 is for "0x"
> 

Oh, right.  It's the use of %#... I usually use 0x%... so I didn't think
of it.

> or you prefer to cast them to pointer and use %pR for them all?
> 
> or fix printk to add extra 2 for "0x" when # is found?

We should normally use %pR or the equivalent format.  The only reason we
do it different for e820_print_map is because it prints a whole bunch of
lines in which we want the columns to line up.

	-hpa

Re: [PATCH 8/9] x86: ramdisk info print with high bits.

[H. Peter Anvin]

On 11/16/2012 11:32 AM, Yinghai Lu wrote:
>>
>> or fix printk to add extra 2 for "0x" when # is found?
> 
> looks like we have lots of %#010llx or %#010Lx there in arch/x86.
> 
> We need to fix printk to make it acting like %pR ?
> 

No, it was a thinko on my part.

	-hpa

Re: [PATCH 8/9] x86: ramdisk info print with high bits.

[Yinghai Lu]

On Fri, Nov 16, 2012 at 11:39 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 11/16/2012 11:21 AM, Yinghai Lu wrote:
>>>
>>> NAK, this is expected to match the resource print format (%pR), which
>>> prints 10 digits by default and then expands.  Furthermore, printing
>>> *18* digits is downright silly since we still don't have 72-bit addressing.
>>
>> that is the same as in e820_print_map::
>>
>>                 printk(KERN_INFO "%s: [mem %#018Lx-%#018Lx] ", who,
>>                        (unsigned long long) e820.map[i].addr,
>>                        (unsigned long long)
>>                        (e820.map[i].addr + e820.map[i].size - 1));
>>
>>
>> that is for 64bit address.
>> that extra 2 is for "0x"
>>
>
> Oh, right.  It's the use of %#... I usually use 0x%... so I didn't think
> of it.
>
>> or you prefer to cast them to pointer and use %pR for them all?
>>
>> or fix printk to add extra 2 for "0x" when # is found?
>
> We should normally use %pR or the equivalent format.  The only reason we
> do it different for e820_print_map is because it prints a whole bunch of
> lines in which we want the columns to line up.

so we just use #llx or #Lx instead in this patch?

Re: [PATCH 8/9] x86: ramdisk info print with high bits.

[H. Peter Anvin]

Use %#010llx

Yinghai Lu <yinghai@kernel.org> wrote:

>On Fri, Nov 16, 2012 at 11:39 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 11/16/2012 11:21 AM, Yinghai Lu wrote:
>>>>
>>>> NAK, this is expected to match the resource print format (%pR),
>which
>>>> prints 10 digits by default and then expands.  Furthermore,
>printing
>>>> *18* digits is downright silly since we still don't have 72-bit
>addressing.
>>>
>>> that is the same as in e820_print_map::
>>>
>>>                 printk(KERN_INFO "%s: [mem %#018Lx-%#018Lx] ", who,
>>>                        (unsigned long long) e820.map[i].addr,
>>>                        (unsigned long long)
>>>                        (e820.map[i].addr + e820.map[i].size - 1));
>>>
>>>
>>> that is for 64bit address.
>>> that extra 2 is for "0x"
>>>
>>
>> Oh, right.  It's the use of %#... I usually use 0x%... so I didn't
>think
>> of it.
>>
>>> or you prefer to cast them to pointer and use %pR for them all?
>>>
>>> or fix printk to add extra 2 for "0x" when # is found?
>>
>> We should normally use %pR or the equivalent format.  The only reason
>we
>> do it different for e820_print_map is because it prints a whole bunch
>of
>> lines in which we want the columns to line up.
>
>so we just use #llx or #Lx instead in this patch?

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

Re: [PATCH 8/9] x86: ramdisk info print with high bits.

[Yinghai Lu]

On Fri, Nov 16, 2012 at 12:08 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Use %#010llx

that will only print out 0x87654321 when val is 0xa987654321

Re: [PATCH 8/9] x86: ramdisk info print with high bits.

[H. Peter Anvin]

No, it won't... try it.

Yinghai Lu <yinghai@kernel.org> wrote:

>On Fri, Nov 16, 2012 at 12:08 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> Use %#010llx
>
>that will only print out 0x87654321 when val is 0xa987654321

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

Re: [PATCH 8/9] x86: ramdisk info print with high bits.

[Yinghai Lu]

On Fri, Nov 16, 2012 at 12:25 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> No, it won't... try it.
>

yes, you are right. this patch is not needed.

Thanks

Yinghai

Re: [PATCH 0/9] x86, boot, 64bit: Add support for loading ramdisk and bzImage high

[Yinghai Lu]

On Fri, Nov 16, 2012 at 8:17 AM, H. Peter Anvin <hpa@zytor.com> wrote:

> How is collecting comments and ACKs for for-x86-mm coming?  I'd like to
> do another review pass today and putting it in -tip if it is in better
> shape.  Otherwise I suspect we'll be looking at 3.9, which is OK, of course.

get three Acks from Stefano.

Konard test -v6 and found one bug, and it is address in -v7.
--- xen domU does not have hole under 4G when 8G ram is configured.

please check updated one with acks and updated log from
    git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
for-x86-mm

Hope you can put them in tip early for more test coverage.

Thanks

Yinghai

Re: [PATCH 8/9] x86: ramdisk info print with high bits.

[Valdis.Kletnieks]

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

On Fri, 16 Nov 2012 11:32:50 -0800, Yinghai Lu said:
> On Fri, Nov 16, 2012 at 11:21 AM, Yinghai Lu <yinghai@kernel.org> wrote:

> > or you prefer to cast them to pointer and use %pR for them all?
> >
> > or fix printk to add extra 2 for "0x" when # is found?
>
> looks like we have lots of %#010llx or %#010Lx there in arch/x86.
>
> We need to fix printk to make it acting like %pR ?

I'd prefer fixing the code to use %pR - when I'm looking at the code,
that tells me more about the intended semantics than $# does.

But I'm basically just a crash test dummy here - the x86 maintainers
of course get to make the decision what they'd prefer to have.


[-- Attachment #2: Type: application/pgp-signature, Size: 865 bytes --]