bzImage 2.12

bzImage 2.12

[H. Peter Anvin]

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

Hi guys,

This is what I would like to do for bzImage 2.12.  This is *different* 
than either one of you have, but it should be a unification of both... 
please let me know if you have any objections as soon as possible.

This is intentionally a protocol only patch, which may be possible to 
push into 3.8 as an urgent patch.  David, if I understand our 
discussions right it might be better to not export XLF_EFI_HANDOFF_32 at 
this time?

Please comment as soon as possible.

Thanks,

	-hpa

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


[-- Attachment #2: 0001-x86-boot-Define-the-2.12-bzImage-boot-protocol.patch --]
[-- Type: text/x-patch, Size: 9070 bytes --]

>From 05e7535e2c26b97380319c37c1290883b553e35d Mon Sep 17 00:00:00 2001
From: "H. Peter Anvin" <hpa@linux.intel.com>
Date: Sun, 27 Jan 2013 10:43:28 -0800
Subject: [PATCH] x86, boot: Define the 2.12 bzImage boot protocol

Define the 2.12 bzImage boot protocol: add xloadflags and additional
fields to allow the command line, initramfs and struct boot_params to
live above the 4 GiB mark.

The xloadflags now communicates if this is a 64-bit kernel with the
legacy 64-bit entry point and which of the EFI handover entry points
are supported.

Avoid adding new read flags to loadflags because of claimed
bootloaders testing the whole byte for == 1 to determine bzImageness
at least until the issue can be researched further.

This is based on patches by Yinghai Lu and David Woodhouse.

Originally-by: Yinghai Lu <yinghai@kernel.org>
Originally-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/1359058816-7615-26-git-send-email-yinghai@kernel.org
Cc: Rob Landley <rob@landley.net>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Gokul Caushik <caushik1@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Joe Millenbach <jmillenbach@gmail.com>
---
 Documentation/x86/boot.txt            | 27 ++++++++++++++++++++++++++-
 Documentation/x86/zero-page.txt       |  4 ++++
 arch/x86/boot/header.S                | 27 ++++++++++++++++++++++++---
 arch/x86/boot/setup.ld                |  2 +-
 arch/x86/include/uapi/asm/bootparam.h | 27 ++++++++++++++++++++++++---
 5 files changed, 79 insertions(+), 8 deletions(-)

diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index 406d82d..e28f2f7 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -57,6 +57,10 @@ 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 the xloadflags field and extension fields
+	 	to struct boot_params for for loading bzImage and ramdisk
+		above 4G in 64bit.
+
 **** MEMORY LAYOUT
 
 The traditional memory map for the kernel loader, used for Image or
@@ -182,7 +186,7 @@ Offset	Proto	Name		Meaning
 0230/4	2.05+	kernel_alignment Physical addr alignment required for kernel
 0234/1	2.05+	relocatable_kernel Whether kernel is relocatable or not
 0235/1	2.10+	min_alignment	Minimum alignment, as a power of two
-0236/2	N/A	pad3		Unused
+0236/2	2.12+	xloadflags	Boot protocol option flags
 0238/4	2.06+	cmdline_size	Maximum size of the kernel command line
 023C/4	2.07+	hardware_subarch Hardware subarchitecture
 0240/8	2.07+	hardware_subarch_data Subarchitecture-specific data
@@ -582,6 +586,27 @@ Protocol:	2.10+
   misaligned kernel.  Therefore, a loader should typically try each
   power-of-two alignment from kernel_alignment down to this alignment.
 
+Field name:     xloadflags
+Type:           read
+Offset/size:    0x236/2
+Protocol:       2.12+
+
+  This field is a bitmask.
+
+  Bit 0 (read):	XLF_KERNEL_64
+	- If 1, this kernel has the legacy 64-bit entry point at 0x200.
+
+  Bit 1 (read): XLF_CAN_BE_LOADED_ABOVE_4G
+        - If 1, kernel/boot_params/cmdline/ramdisk can be above 4G.
+
+  Bit 2 (read):	XLF_EFI_HANDOFF_32
+	- If 1, the kernel supports the 32-bit EFI handoff entry point
+          given at handover_offset.
+
+  Bit 3 (read): XLF_EFI_HANDOFF_64
+	- If 1, the kernel supports the 32-bit EFI handoff entry point
+          given at handover_offset + 0x200.
+
 Field name:	cmdline_size
 Type:		read
 Offset/size:	0x238/4
diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
index cf5437d..199f453 100644
--- a/Documentation/x86/zero-page.txt
+++ b/Documentation/x86/zero-page.txt
@@ -19,6 +19,9 @@ Offset	Proto	Name		Meaning
 090/010	ALL	hd1_info	hd1 disk parameter, OBSOLETE!!
 0A0/010	ALL	sys_desc_table	System description table (struct sys_desc_table)
 0B0/010	ALL	olpc_ofw_header	OLPC's OpenFirmware CIF and friends
+0C0/004	ALL	ext_ramdisk_image ramdisk_image high 32bits
+0C4/004	ALL	ext_ramdisk_size  ramdisk_size high 32bits
+0C8/004	ALL	ext_cmd_line_ptr  cmd_line_ptr high 32bits
 140/080	ALL	edid_info	Video mode setup (struct edid_info)
 1C0/020	ALL	efi_info	EFI 32 information (struct efi_info)
 1E0/004	ALL	alk_mem_k	Alternative mem check, in KB
@@ -27,6 +30,7 @@ Offset	Proto	Name		Meaning
 1E9/001	ALL	eddbuf_entries	Number of entries in eddbuf (below)
 1EA/001	ALL	edd_mbr_sig_buf_entries	Number of entries in edd_mbr_sig_buffer
 				(below)
+1EF/001	ALL	sentinel	Used to detect broken bootloaders
 290/040	ALL	edd_mbr_sig_buffer EDD MBR signatures
 2D0/A00	ALL	e820_map	E820 memory map table
 				(array of struct e820entry)
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 8c132a6..40cef3d 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -255,6 +255,9 @@ section_table:
 	# header, from the old boot sector.
 
 	.section ".header", "a"
+	.globl	sentinel
+sentinel:	.byte 0xff, 0xff        /* Used to detect broken loaders */
+
 	.globl	hdr
 hdr:
 setup_sects:	.byte 0			/* Filled in by build.c */
@@ -279,7 +282,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
@@ -369,7 +372,20 @@ relocatable_kernel:    .byte 1
 relocatable_kernel:    .byte 0
 #endif
 min_alignment:		.byte MIN_KERNEL_ALIGN_LG2	# minimum alignment
-pad3:			.word 0
+
+xloadflags:
+xloadflags_val = 0
+#ifdef CONFIG_X86_64
+xloadflags_val = xloadflags_val | XLF_KERNEL_64
+#endif
+#ifdef CONFIG_EFI_STUB
+# ifdef CONFIG_X86_64
+xloadflags_val = xloadflags_val | XLF_EFI_HANDOFF_64
+# else
+xloadflags_val = xloadflags_val | XLF_EFI_HANDOFF_32
+# endif
+#endif
+			.word xloadflags_val
 
 cmdline_size:   .long   COMMAND_LINE_SIZE-1     #length of the command line,
                                                 #added with boot protocol
@@ -397,8 +413,13 @@ pref_address:		.quad LOAD_PHYSICAL_ADDR	# preferred load addr
 #define INIT_SIZE VO_INIT_SIZE
 #endif
 init_size:		.long INIT_SIZE		# kernel initialization size
-handover_offset:	.long 0x30		# offset to the handover
+handover_offset:
+#ifdef CONFIG_EFI_STUB
+  			.long 0x30		# offset to the handover
 						# protocol entry point
+#else
+			.long 0
+#endif
 
 # End of setup header #####################################################
 
diff --git a/arch/x86/boot/setup.ld b/arch/x86/boot/setup.ld
index 03c0683..96a6c75 100644
--- a/arch/x86/boot/setup.ld
+++ b/arch/x86/boot/setup.ld
@@ -13,7 +13,7 @@ SECTIONS
 	.bstext		: { *(.bstext) }
 	.bsdata		: { *(.bsdata) }
 
-	. = 497;
+	. = 495;
 	.header		: { *(.header) }
 	.entrytext	: { *(.entrytext) }
 	.inittext	: { *(.inittext) }
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 92862cd..00d282e 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -58,7 +58,12 @@ struct setup_header {
 	__u32	initrd_addr_max;
 	__u32	kernel_alignment;
 	__u8	relocatable_kernel;
-	__u8	_pad2[3];
+	__u8	min_alignment;
+	__u16	xloadflags;
+#define XLF_KERNEL_64			(1<<0)
+#define XLF_CAN_BE_LOADED_ABOVE_4G	(1<<1)
+#define XLF_EFI_HANDOFF_32		(1<<2)
+#define XLF_EFI_HANDOFF_64		(1<<3)
 	__u32	cmdline_size;
 	__u32	hardware_subarch;
 	__u64	hardware_subarch_data;
@@ -106,7 +111,10 @@ struct boot_params {
 	__u8  hd1_info[16];	/* obsolete! */		/* 0x090 */
 	struct sys_desc_table sys_desc_table;		/* 0x0a0 */
 	struct olpc_ofw_header olpc_ofw_header;		/* 0x0b0 */
-	__u8  _pad4[128];				/* 0x0c0 */
+	__u32 ext_ramdisk_image;			/* 0x0c0 */
+	__u32 ext_ramdisk_size;				/* 0x0c4 */
+	__u32 ext_cmd_line_ptr;				/* 0x0c8 */
+	__u8  _pad4[116];				/* 0x0cc */
 	struct edid_info edid_info;			/* 0x140 */
 	struct efi_info efi_info;			/* 0x1c0 */
 	__u32 alt_mem_k;				/* 0x1e0 */
@@ -115,7 +123,20 @@ struct boot_params {
 	__u8  eddbuf_entries;				/* 0x1e9 */
 	__u8  edd_mbr_sig_buf_entries;			/* 0x1ea */
 	__u8  kbd_status;				/* 0x1eb */
-	__u8  _pad6[5];					/* 0x1ec */
+	__u8  _pad5[3];					/* 0x1ec */
+	/*
+	 * The sentinel is set to a nonzero value (0xff) in header.S.
+	 *
+	 * A bootloader is supposed to only take setup_header and put
+	 * it into a clean boot_params buffer. If it turns out that
+	 * it is clumsy or too generous with the buffer, it most
+	 * probably will pick up the sentinel variable too. The fact
+	 * that this variable then is still 0xff will let kernel
+	 * know that some variables in boot_params are invalid and
+	 * kernel should zero out certain portions of boot_params.
+	 */
+	__u8  sentinel;					/* 0x1ef */
+	__u8  _pad6[1];					/* 0x1f0 */
 	struct setup_header hdr;    /* setup header */	/* 0x1f1 */
 	__u8  _pad7[0x290-0x1f1-sizeof(struct setup_header)];
 	__u32 edd_mbr_sig_buffer[EDD_MBR_SIG_MAX];	/* 0x290 */
-- 
1.7.11.7

Re: bzImage 2.12

[David Woodhouse]

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

On Sun, 2013-01-27 at 11:02 -0800, H. Peter Anvin wrote:
> This is intentionally a protocol only patch, which may be possible to 
> push into 3.8 as an urgent patch.  David, if I understand our 
> discussions right it might be better to not export XLF_EFI_HANDOFF_32
> at this time?

That won't stop broken bootloaders from jumping to $handover_offset
anyway. Anyone who was daft enough to implement EFI boot stub in their
bootloader *despite* its obvious brokenness, rather than insisting on
fixing it before it could be considered usable, will still be jumping
into hyperspace. I have little sympathy for them, but I'm told we need
to care.

It'd probably be better to just mark CONFIG_EFI_STUB as 'depends on
BROKEN' for 32-bit.

Or, and perhaps this is heresy, merge the patches which bloody fix it?

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

Re: bzImage 2.12

[H. Peter Anvin]

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

On 01/27/2013 11:10 AM, David Woodhouse wrote:
> On Sun, 2013-01-27 at 11:02 -0800, H. Peter Anvin wrote:
>> This is intentionally a protocol only patch, which may be possible to
>> push into 3.8 as an urgent patch.  David, if I understand our
>> discussions right it might be better to not export XLF_EFI_HANDOFF_32
>> at this time?
>
> That won't stop broken bootloaders from jumping to $handover_offset
> anyway. Anyone who was daft enough to implement EFI boot stub in their
> bootloader *despite* its obvious brokenness, rather than insisting on
> fixing it before it could be considered usable, will still be jumping
> into hyperspace. I have little sympathy for them, but I'm told we need
> to care.

At the moment I'm concerned with a new updated bootloader, which knows 
the 2.12 protocol, encountering an old kernel.

> It'd probably be better to just mark CONFIG_EFI_STUB as 'depends on
> BROKEN' for 32-bit.
>
> Or, and perhaps this is heresy, merge the patches which bloody fix it?

I think we can probably do that, since it doesn't affect anything 
non-broken at this point.  I'm sorting out what can be done for 3.8 vs 
3.9 at this point.

Anyway, as you can tell I'm spending this weekend working for a reason.

It turns out the patch I sent out doesn't actually build.  Here is an 
updated patch.  Can I get your ack for this so I can do the appropriate 
hacks to your and Yinghai's patchsets?

	-hpa

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


[-- Attachment #2: 0001-x86-boot-Define-the-2.12-bzImage-boot-protocol.patch --]
[-- Type: text/x-patch, Size: 9132 bytes --]

>From fb28b02a097389b937c5ed5c74a7b811a10a6615 Mon Sep 17 00:00:00 2001
From: "H. Peter Anvin" <hpa@linux.intel.com>
Date: Sun, 27 Jan 2013 10:43:28 -0800
Subject: [PATCH] x86, boot: Define the 2.12 bzImage boot protocol

Define the 2.12 bzImage boot protocol: add xloadflags and additional
fields to allow the command line, initramfs and struct boot_params to
live above the 4 GiB mark.

The xloadflags now communicates if this is a 64-bit kernel with the
legacy 64-bit entry point and which of the EFI handover entry points
are supported.

Avoid adding new read flags to loadflags because of claimed
bootloaders testing the whole byte for == 1 to determine bzImageness
at least until the issue can be researched further.

This is based on patches by Yinghai Lu and David Woodhouse.

Originally-by: Yinghai Lu <yinghai@kernel.org>
Originally-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/1359058816-7615-26-git-send-email-yinghai@kernel.org
Cc: Rob Landley <rob@landley.net>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Gokul Caushik <caushik1@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Joe Millenbach <jmillenbach@gmail.com>
---
 Documentation/x86/boot.txt            | 27 ++++++++++++++++++++++++++-
 Documentation/x86/zero-page.txt       |  4 ++++
 arch/x86/boot/header.S                | 30 +++++++++++++++++++++++++++---
 arch/x86/boot/setup.ld                |  2 +-
 arch/x86/include/uapi/asm/bootparam.h | 27 ++++++++++++++++++++++++---
 5 files changed, 82 insertions(+), 8 deletions(-)

diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index 406d82d..86bd3e9 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -57,6 +57,10 @@ 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 the xloadflags field and extension fields
+	 	to struct boot_params for for loading bzImage and ramdisk
+		above 4G in 64bit.
+
 **** MEMORY LAYOUT
 
 The traditional memory map for the kernel loader, used for Image or
@@ -182,7 +186,7 @@ Offset	Proto	Name		Meaning
 0230/4	2.05+	kernel_alignment Physical addr alignment required for kernel
 0234/1	2.05+	relocatable_kernel Whether kernel is relocatable or not
 0235/1	2.10+	min_alignment	Minimum alignment, as a power of two
-0236/2	N/A	pad3		Unused
+0236/2	2.12+	xloadflags	Boot protocol option flags
 0238/4	2.06+	cmdline_size	Maximum size of the kernel command line
 023C/4	2.07+	hardware_subarch Hardware subarchitecture
 0240/8	2.07+	hardware_subarch_data Subarchitecture-specific data
@@ -582,6 +586,27 @@ Protocol:	2.10+
   misaligned kernel.  Therefore, a loader should typically try each
   power-of-two alignment from kernel_alignment down to this alignment.
 
+Field name:     xloadflags
+Type:           read
+Offset/size:    0x236/2
+Protocol:       2.12+
+
+  This field is a bitmask.
+
+  Bit 0 (read):	XLF_KERNEL_64
+	- If 1, this kernel has the legacy 64-bit entry point at 0x200.
+
+  Bit 1 (read): XLF_CAN_BE_LOADED_ABOVE_4G
+        - If 1, kernel/boot_params/cmdline/ramdisk can be above 4G.
+
+  Bit 2 (read):	XLF_EFI_HANDOVER_32
+	- If 1, the kernel supports the 32-bit EFI handoff entry point
+          given at handover_offset.
+
+  Bit 3 (read): XLF_EFI_HANDOVER_64
+	- If 1, the kernel supports the 32-bit EFI handoff entry point
+          given at handover_offset + 0x200.
+
 Field name:	cmdline_size
 Type:		read
 Offset/size:	0x238/4
diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
index cf5437d..199f453 100644
--- a/Documentation/x86/zero-page.txt
+++ b/Documentation/x86/zero-page.txt
@@ -19,6 +19,9 @@ Offset	Proto	Name		Meaning
 090/010	ALL	hd1_info	hd1 disk parameter, OBSOLETE!!
 0A0/010	ALL	sys_desc_table	System description table (struct sys_desc_table)
 0B0/010	ALL	olpc_ofw_header	OLPC's OpenFirmware CIF and friends
+0C0/004	ALL	ext_ramdisk_image ramdisk_image high 32bits
+0C4/004	ALL	ext_ramdisk_size  ramdisk_size high 32bits
+0C8/004	ALL	ext_cmd_line_ptr  cmd_line_ptr high 32bits
 140/080	ALL	edid_info	Video mode setup (struct edid_info)
 1C0/020	ALL	efi_info	EFI 32 information (struct efi_info)
 1E0/004	ALL	alk_mem_k	Alternative mem check, in KB
@@ -27,6 +30,7 @@ Offset	Proto	Name		Meaning
 1E9/001	ALL	eddbuf_entries	Number of entries in eddbuf (below)
 1EA/001	ALL	edd_mbr_sig_buf_entries	Number of entries in edd_mbr_sig_buffer
 				(below)
+1EF/001	ALL	sentinel	Used to detect broken bootloaders
 290/040	ALL	edd_mbr_sig_buffer EDD MBR signatures
 2D0/A00	ALL	e820_map	E820 memory map table
 				(array of struct e820entry)
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 8c132a6..65a8778 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -255,6 +255,9 @@ section_table:
 	# header, from the old boot sector.
 
 	.section ".header", "a"
+	.globl	sentinel
+sentinel:	.byte 0xff, 0xff        /* Used to detect broken loaders */
+
 	.globl	hdr
 hdr:
 setup_sects:	.byte 0			/* Filled in by build.c */
@@ -279,7 +282,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
@@ -369,7 +372,23 @@ relocatable_kernel:    .byte 1
 relocatable_kernel:    .byte 0
 #endif
 min_alignment:		.byte MIN_KERNEL_ALIGN_LG2	# minimum alignment
-pad3:			.word 0
+
+xloadflags:
+#ifdef CONFIG_X86_64
+# define XLF0 XLF_KERNEL_64			/* 64-bit kernel */
+#else
+# define XLF0 0
+#endif
+#ifdef CONFIG_EFI_STUB
+# ifdef CONFIG_X86_64
+#  define XLF23 XLF_EFI_HANDOVER_64		/* 64-bit EFI handover ok */
+# else
+#  define XLF23 XLF_EFI_HANDOVER_32		/* 32-bit EFI handover ok */
+# endif
+#else
+# define XLF23 0
+#endif
+			.word XLF0 | XLF23
 
 cmdline_size:   .long   COMMAND_LINE_SIZE-1     #length of the command line,
                                                 #added with boot protocol
@@ -397,8 +416,13 @@ pref_address:		.quad LOAD_PHYSICAL_ADDR	# preferred load addr
 #define INIT_SIZE VO_INIT_SIZE
 #endif
 init_size:		.long INIT_SIZE		# kernel initialization size
-handover_offset:	.long 0x30		# offset to the handover
+handover_offset:
+#ifdef CONFIG_EFI_STUB
+  			.long 0x30		# offset to the handover
 						# protocol entry point
+#else
+			.long 0
+#endif
 
 # End of setup header #####################################################
 
diff --git a/arch/x86/boot/setup.ld b/arch/x86/boot/setup.ld
index 03c0683..96a6c75 100644
--- a/arch/x86/boot/setup.ld
+++ b/arch/x86/boot/setup.ld
@@ -13,7 +13,7 @@ SECTIONS
 	.bstext		: { *(.bstext) }
 	.bsdata		: { *(.bsdata) }
 
-	. = 497;
+	. = 495;
 	.header		: { *(.header) }
 	.entrytext	: { *(.entrytext) }
 	.inittext	: { *(.inittext) }
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 92862cd..1934b05 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -58,7 +58,12 @@ struct setup_header {
 	__u32	initrd_addr_max;
 	__u32	kernel_alignment;
 	__u8	relocatable_kernel;
-	__u8	_pad2[3];
+	__u8	min_alignment;
+	__u16	xloadflags;
+#define XLF_KERNEL_64			(1<<0)
+#define XLF_CAN_BE_LOADED_ABOVE_4G	(1<<1)
+#define XLF_EFI_HANDOVER_32		(1<<2)
+#define XLF_EFI_HANDOVER_64		(1<<3)
 	__u32	cmdline_size;
 	__u32	hardware_subarch;
 	__u64	hardware_subarch_data;
@@ -106,7 +111,10 @@ struct boot_params {
 	__u8  hd1_info[16];	/* obsolete! */		/* 0x090 */
 	struct sys_desc_table sys_desc_table;		/* 0x0a0 */
 	struct olpc_ofw_header olpc_ofw_header;		/* 0x0b0 */
-	__u8  _pad4[128];				/* 0x0c0 */
+	__u32 ext_ramdisk_image;			/* 0x0c0 */
+	__u32 ext_ramdisk_size;				/* 0x0c4 */
+	__u32 ext_cmd_line_ptr;				/* 0x0c8 */
+	__u8  _pad4[116];				/* 0x0cc */
 	struct edid_info edid_info;			/* 0x140 */
 	struct efi_info efi_info;			/* 0x1c0 */
 	__u32 alt_mem_k;				/* 0x1e0 */
@@ -115,7 +123,20 @@ struct boot_params {
 	__u8  eddbuf_entries;				/* 0x1e9 */
 	__u8  edd_mbr_sig_buf_entries;			/* 0x1ea */
 	__u8  kbd_status;				/* 0x1eb */
-	__u8  _pad6[5];					/* 0x1ec */
+	__u8  _pad5[3];					/* 0x1ec */
+	/*
+	 * The sentinel is set to a nonzero value (0xff) in header.S.
+	 *
+	 * A bootloader is supposed to only take setup_header and put
+	 * it into a clean boot_params buffer. If it turns out that
+	 * it is clumsy or too generous with the buffer, it most
+	 * probably will pick up the sentinel variable too. The fact
+	 * that this variable then is still 0xff will let kernel
+	 * know that some variables in boot_params are invalid and
+	 * kernel should zero out certain portions of boot_params.
+	 */
+	__u8  sentinel;					/* 0x1ef */
+	__u8  _pad6[1];					/* 0x1f0 */
 	struct setup_header hdr;    /* setup header */	/* 0x1f1 */
 	__u8  _pad7[0x290-0x1f1-sizeof(struct setup_header)];
 	__u32 edd_mbr_sig_buffer[EDD_MBR_SIG_MAX];	/* 0x290 */
-- 
1.7.11.7

Re: bzImage 2.12

[Matt Fleming]

On Sun, 2013-01-27 at 11:19 -0800, H. Peter Anvin wrote:
> It turns out the patch I sent out doesn't actually build.  Here is an 
> updated patch.  Can I get your ack for this so I can do the appropriate 
> hacks to your and Yinghai's patchsets?
> 
> 	-hpa
> 

Acked-by: Matt Fleming <matt.fleming@intel.com>

Re: bzImage 2.12

[Yinghai Lu]

On Sun, Jan 27, 2013 at 11:19 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> I think we can probably do that, since it doesn't affect anything non-broken
> at this point.  I'm sorting out what can be done for 3.8 vs 3.9 at this
> point.
>
> Anyway, as you can tell I'm spending this weekend working for a reason.
>
> It turns out the patch I sent out doesn't actually build.  Here is an
> updated patch.  Can I get your ack for this so I can do the appropriate
> hacks to your and Yinghai's patchsets?

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

Do you want to me to update my patchset on top it and resend?

or you are going to sort it out by you self?

Thanks

Yinghai

Re: bzImage 2.12

[H. Peter Anvin]

I'm planning to sort it out... I'll let you know if I run out of bandwidth.

Yinghai Lu <yinghai@kernel.org> wrote:

>On Sun, Jan 27, 2013 at 11:19 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> I think we can probably do that, since it doesn't affect anything
>non-broken
>> at this point.  I'm sorting out what can be done for 3.8 vs 3.9 at
>this
>> point.
>>
>> Anyway, as you can tell I'm spending this weekend working for a
>reason.
>>
>> It turns out the patch I sent out doesn't actually build.  Here is an
>> updated patch.  Can I get your ack for this so I can do the
>appropriate
>> hacks to your and Yinghai's patchsets?
>
>Acked-by: Yinghai Lu <yinghai@kernel.org>
>
>Do you want to me to update my patchset on top it and resend?
>
>or you are going to sort it out by you self?
>
>Thanks
>
>Yinghai

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

Re: bzImage 2.12

[Yinghai Lu]

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

On Sun, Jan 27, 2013 at 11:39 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> I'm planning to sort it out... I'll let you know if I run out of bandwidth.
>
> Yinghai Lu <yinghai@kernel.org> wrote:
>
>>On Sun, Jan 27, 2013 at 11:19 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>>
>>> I think we can probably do that, since it doesn't affect anything
>>non-broken
>>> at this point.  I'm sorting out what can be done for 3.8 vs 3.9 at
>>this
>>> point.
>>>
>>> Anyway, as you can tell I'm spending this weekend working for a
>>reason.
>>>
>>> It turns out the patch I sent out doesn't actually build.  Here is an
>>> updated patch.  Can I get your ack for this so I can do the
>>appropriate
>>> hacks to your and Yinghai's patchsets?
>>
>>Acked-by: Yinghai Lu <yinghai@kernel.org>
>>
>>Do you want to me to update my patchset on top it and resend?
>>
>>or you are going to sort it out by you self?
>>

To save your some time, please check attached patch.

It would take position of

https://patchwork.kernel.org/patch/2035731/

[25/35] x86, boot: Add fields to support load bzImage and ramdisk above 4G

Thanks

Yinghai

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

Subject: [PATCH v5 10/11] x86, boot: enable support load bzImage and ramdisk above 4G

xloadflags bit1 is set if kernel is relocatable and 64bit.

bootloader will check if xloadflags bit1 is set to decicde if
it could load ramdisk and kernel high above 4G.

bootloader will fill value to ext_ramdisk_image/size for high 32bits
when it load ramdisk above 4G.
kernel use get_ramdisk_image/size to use ext_ramdisk_image/size to get
right positon for ramdisk.

sentinel is used so kernel could find out if ext_* and other fields have
valid values set in boot_params from bootloader.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Rob Landley <rob@landley.net>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Gokul Caushik <caushik1@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Joe Millenbach <jmillenbach@gmail.com>

---
 arch/x86/boot/compressed/cmdline.c |    2 ++
 arch/x86/boot/compressed/misc.c    |   19 +++++++++++++++++++
 arch/x86/boot/header.S             |   10 +++++++++-
 arch/x86/kernel/head64.c           |    2 ++
 arch/x86/kernel/setup.c            |    4 ++++
 5 files changed, 36 insertions(+), 1 deletion(-)

Index: linux-2.6/arch/x86/boot/header.S
===================================================================
--- linux-2.6.orig/arch/x86/boot/header.S
+++ linux-2.6/arch/x86/boot/header.S
@@ -374,6 +374,14 @@ xloadflags:
 #else
 # define XLF0 0
 #endif
+
+#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_X86_64)
+   /* kernel/boot_param/ramdisk could be loaded above 4g */
+# define XLF1 XLF_CAN_BE_LOADED_ABOVE_4G
+#else
+# define XLF1 0
+#endif
+
 #ifdef CONFIG_EFI_STUB
 # ifdef CONFIG_X86_64
 #  define XLF23 XLF_EFI_HANDOVER_64		/* 64-bit EFI handover ok */
@@ -383,7 +391,7 @@ xloadflags:
 #else
 # define XLF23 0
 #endif
-			.word XLF0 | XLF23
+			.word XLF0 | XLF1 | XLF23
 
 cmdline_size:   .long   COMMAND_LINE_SIZE-1     #length of the command line,
                                                 #added with boot protocol
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -298,12 +298,16 @@ static u64 __init get_ramdisk_image(void
 {
 	u64 ramdisk_image = boot_params.hdr.ramdisk_image;
 
+	ramdisk_image |= (u64)boot_params.ext_ramdisk_image << 32;
+
 	return ramdisk_image;
 }
 static u64 __init get_ramdisk_size(void)
 {
 	u64 ramdisk_size = boot_params.hdr.ramdisk_size;
 
+	ramdisk_size |= (u64)boot_params.ext_ramdisk_size << 32;
+
 	return ramdisk_size;
 }
 
Index: linux-2.6/arch/x86/boot/compressed/cmdline.c
===================================================================
--- linux-2.6.orig/arch/x86/boot/compressed/cmdline.c
+++ linux-2.6/arch/x86/boot/compressed/cmdline.c
@@ -17,6 +17,8 @@ static unsigned long get_cmd_line_ptr(vo
 {
 	unsigned long cmd_line_ptr = real_mode->hdr.cmd_line_ptr;
 
+	cmd_line_ptr |= (u64)real_mode->ext_cmd_line_ptr << 32;
+
 	return cmd_line_ptr;
 }
 int cmdline_find_option(const char *option, char *buffer, int bufsize)
Index: linux-2.6/arch/x86/kernel/head64.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/head64.c
+++ linux-2.6/arch/x86/kernel/head64.c
@@ -115,6 +115,8 @@ static unsigned long get_cmd_line_ptr(vo
 {
 	unsigned long cmd_line_ptr = boot_params.hdr.cmd_line_ptr;
 
+	cmd_line_ptr |= (u64)boot_params.ext_cmd_line_ptr << 32;
+
 	return cmd_line_ptr;
 }
 
Index: linux-2.6/arch/x86/boot/compressed/misc.c
===================================================================
--- linux-2.6.orig/arch/x86/boot/compressed/misc.c
+++ linux-2.6/arch/x86/boot/compressed/misc.c
@@ -318,6 +318,23 @@ static void parse_elf(void *output)
 	free(phdrs);
 }
 
+static void sanitize_real_mode(struct boot_params *real_mode)
+{
+	if (real_mode->sentinel) {
+		/*fields in boot_params are not valid, clear them */
+		memset(&real_mode->olpc_ofw_header, 0,
+		       (char *)&real_mode->alt_mem_k -
+			(char *)&real_mode->olpc_ofw_header);
+		memset(&real_mode->_pad7[0], 0,
+		       (char *)&real_mode->edd_mbr_sig_buffer[0] -
+			(char *)&real_mode->_pad7[0]);
+		memset(&real_mode->_pad8[0], 0,
+		       (char *)&real_mode->eddbuf[0] -
+			(char *)&real_mode->_pad8[0]);
+		memset(&real_mode->_pad9[0], 0, sizeof(real_mode->_pad9));
+	}
+}
+
 asmlinkage void decompress_kernel(void *rmode, memptr heap,
 				  unsigned char *input_data,
 				  unsigned long input_len,
@@ -325,6 +342,8 @@ asmlinkage void decompress_kernel(void *
 {
 	real_mode = rmode;
 
+	sanitize_real_mode(real_mode);
+
 	if (real_mode->screen_info.orig_video_mode == 7) {
 		vidmem = (char *) 0xb0000;
 		vidport = 0x3b4;

Re: bzImage 2.12

[H. Peter Anvin]

Thanks.

Yinghai Lu <yinghai@kernel.org> wrote:

>On Sun, Jan 27, 2013 at 11:39 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>> I'm planning to sort it out... I'll let you know if I run out of
>bandwidth.
>>
>> Yinghai Lu <yinghai@kernel.org> wrote:
>>
>>>On Sun, Jan 27, 2013 at 11:19 AM, H. Peter Anvin <hpa@zytor.com>
>wrote:
>>>>
>>>> I think we can probably do that, since it doesn't affect anything
>>>non-broken
>>>> at this point.  I'm sorting out what can be done for 3.8 vs 3.9 at
>>>this
>>>> point.
>>>>
>>>> Anyway, as you can tell I'm spending this weekend working for a
>>>reason.
>>>>
>>>> It turns out the patch I sent out doesn't actually build.  Here is
>an
>>>> updated patch.  Can I get your ack for this so I can do the
>>>appropriate
>>>> hacks to your and Yinghai's patchsets?
>>>
>>>Acked-by: Yinghai Lu <yinghai@kernel.org>
>>>
>>>Do you want to me to update my patchset on top it and resend?
>>>
>>>or you are going to sort it out by you self?
>>>
>
>To save your some time, please check attached patch.
>
>It would take position of
>
>https://patchwork.kernel.org/patch/2035731/
>
>[25/35] x86, boot: Add fields to support load bzImage and ramdisk above
>4G
>
>Thanks
>
>Yinghai

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

Re: bzImage 2.12

[Yinghai Lu]

On Sun, Jan 27, 2013 at 7:36 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Thanks.
>
> Yinghai Lu <yinghai@kernel.org> wrote:
>
>>On Sun, Jan 27, 2013 at 11:39 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> I'm planning to sort it out... I'll let you know if I run out of
>>bandwidth.
>>>
>>> Yinghai Lu <yinghai@kernel.org> wrote:
>>>
>>>>On Sun, Jan 27, 2013 at 11:19 AM, H. Peter Anvin <hpa@zytor.com>
>>wrote:
>>>>>
>>>>> I think we can probably do that, since it doesn't affect anything
>>>>non-broken
>>>>> at this point.  I'm sorting out what can be done for 3.8 vs 3.9 at
>>>>this
>>>>> point.
>>>>>
>>>>> Anyway, as you can tell I'm spending this weekend working for a
>>>>reason.
>>>>>
>>>>> It turns out the patch I sent out doesn't actually build.  Here is
>>an
>>>>> updated patch.  Can I get your ack for this so I can do the
>>>>appropriate
>>>>> hacks to your and Yinghai's patchsets?
>>>>
>>>>Acked-by: Yinghai Lu <yinghai@kernel.org>
>>>>
>>>>Do you want to me to update my patchset on top it and resend?
>>>>
>>>>or you are going to sort it out by you self?
>>>>
>>
>>To save your some time, please check attached patch.
>>
>>It would take position of
>>
>>https://patchwork.kernel.org/patch/2035731/
>>
>>[25/35] x86, boot: Add fields to support load bzImage and ramdisk above
>>4G
>>

Did you get chance to put them into for-x86-boot?

You need to skip the first two about memmap= exactmap and reserveram ...

Thanks

Yinghai

Re: bzImage 2.12

[Yinghai Lu]

On Mon, Jan 28, 2013 at 7:50 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Sun, Jan 27, 2013 at 7:36 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Did you get chance to put them into for-x86-boot?
>
> You need to skip the first two about memmap= exactmap and reserveram ...
>

put updated version in
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
for-x86-boot for-x86-boot-v7u4

and it is based on Linus tree +  tip:x86/mm, tip:x86/mm2,
tip:x86/urgent, tip:x86/boot

Yinghai

Re: bzImage 2.12

[Yinghai Lu]

On Mon, Jan 28, 2013 at 8:22 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Mon, Jan 28, 2013 at 7:50 PM, Yinghai Lu <yinghai@kernel.org> wrote:
>> On Sun, Jan 27, 2013 at 7:36 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> Did you get chance to put them into for-x86-boot?
>>
>> You need to skip the first two about memmap= exactmap and reserveram ...
>>
>

please check
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
for-x86-boot for-x86-boot-v7u5

and it is based on Linus tree +  tip:x86/mm2 + tip:x86/boot

Also put Konrad Ack into last swiotlb patch.

Thanks

Yinghai

Re: bzImage 2.12

[David Woodhouse]

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

On Sun, 2013-01-27 at 11:19 -0800, H. Peter Anvin wrote:
> It turns out the patch I sent out doesn't actually build.  Here is an 
> updated patch.  Can I get your ack for this so I can do the
> appropriate hacks to your and Yinghai's patchsets?

The new flags are supposed to indicate that the EFI stub is present and
usable. So please do NOT add it for 32-bit unless you've also merged the
outstanding patches which actually fix it. Or at least marked EFI_STUB
as 'depends on BROKEN'.

Other than that,

Acked-by: David Woodhouse <David.Woodhouse@intel.com>

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]