kexec: put bzImage and ramdisk above 4G for x86 64bit

On Tue, Nov 20, 2012 at 11:31:38PM -0800, Yinghai Lu wrote:

[..]

kexec/arch/x86_64/kexec-bzImage64.c line 238

Quoted 13 lines

kexec/arch/x86_64/kexec-bzImage64.c new file +13 -0

+	/* avoid cross GB boundary */
+	align = real_mode->kernel_alignment;
+	addr = locate_hole(info, size, align, 0x100000, -1, -1);
+	if (addr == ULONG_MAX)
+		die("can not load bzImage64");
+	/* same GB ? */
+	while ((addr >> 30) != ((addr + size - 1) >> 30)) {
+		addr = locate_hole(info, size, align, 0x100000,
+				 round_down(addr + size - 1, (1UL<<30)), -1);
+		if (addr == ULONG_MAX)
+			die("can not load bzImage64");
+	}
+	dbgprintf("Found kernel buffer at %lx size %lx\n", addr, size);

Where does this limitation of not loading kernel across GB boundary come from?

On Tue, Nov 20, 2012 at 11:31:38PM -0800, Yinghai Lu wrote:

[..]

kexec/arch/x86_64/kexec-bzImage64.c line 238

Quoted 13 lines

kexec/arch/x86_64/kexec-bzImage64.c new file +13 -0

+     /* avoid cross GB boundary */
+     align = real_mode->kernel_alignment;
+     addr = locate_hole(info, size, align, 0x100000, -1, -1);
+     if (addr == ULONG_MAX)
+             die("can not load bzImage64");
+     /* same GB ? */
+     while ((addr >> 30) != ((addr + size - 1) >> 30)) {
+             addr = locate_hole(info, size, align, 0x100000,
+                              round_down(addr + size - 1, (1UL<<30)), -1);
+             if (addr == ULONG_MAX)
+                     die("can not load bzImage64");
+     }
+     dbgprintf("Found kernel buffer at %lx size %lx\n", addr, size);

Where does this limitation of not loading kernel across GB boundary come from?

Quoted 17 lines · Vivek Goyal

On Tue, Nov 20, 2012 at 11:31:38PM -0800, Yinghai Lu wrote:

[..]

kexec/arch/x86_64/kexec-bzImage64.c line 238

Quoted 13 lines

kexec/arch/x86_64/kexec-bzImage64.c new file +13 -0

+     /* avoid cross GB boundary */
+     align = real_mode->kernel_alignment;
+     addr = locate_hole(info, size, align, 0x100000, -1, -1);
+     if (addr == ULONG_MAX)
+             die("can not load bzImage64");
+     /* same GB ? */
+     while ((addr >> 30) != ((addr + size - 1) >> 30)) {
+             addr = locate_hole(info, size, align, 0x100000,
+                              round_down(addr + size - 1, (1UL<<30)), -1);
+             if (addr == ULONG_MAX)
+                     die("can not load bzImage64");
+     }
+     dbgprintf("Found kernel buffer at %lx size %lx\n", addr, size);

Quoted 2 lines

Where does this limitation of not loading kernel across GB boundary come from?

in kernel arch/x86/kernel/head_64.S

it only set first 1G ident mapping. and if it find that code is above 1G, it will set extra ident mapping
for new _text.._end.
To make checking and add extra mapping simple and also save two extra pages for mapping.
Limit that _text.._end in them same GB range.

Quoted 10 lines · Yinghai Lu

in kernel arch/x86/kernel/head_64.S

it only set first 1G ident mapping. and if it find that code is above 1G, it will set extra ident mapping
for new _text.._end.
To make checking and add extra mapping simple and also save two extra pages for mapping.
Limit that _text.._end in them same GB range.

No, this is backwards.

We should fix that limitation instead.

Quoted 12 lines · H. Peter Anvin

Quoted 10 lines · Yinghai Lu

in kernel arch/x86/kernel/head_64.S

it only set first 1G ident mapping. and if it find that code is above 1G, it will set extra ident mapping
for new _text.._end.
To make checking and add extra mapping simple and also save two extra pages for mapping.
Limit that _text.._end in them same GB range.

Quoted 1 line

No, this is backwards.

old one: it limited bzImage in [0,1G) aka the first 1G.

Now we can put it in any aligned 1G range.

So how could it be called backwards?

Quoted 2 lines

We should fix that limitation instead.

sure, but that will make arch/x86/boot/compressed/head_64.S not need complicated.

Quoted 15 lines · Yinghai Lu

Quoted 13 lines · H. Peter Anvin

Quoted 10 lines · Yinghai Lu

in kernel arch/x86/kernel/head_64.S

it only set first 1G ident mapping. and if it find that code is above 1G, it will set extra ident mapping
for new _text.._end.
To make checking and add extra mapping simple and also save two extra pages for mapping.
Limit that _text.._end in them same GB range.

No, this is backwards.

Quoted 6 lines

old one: it limited bzImage in [0,1G) aka the first 1G.

Now we can put it in any aligned 1G range.

So how could it be called backwards?

Because you're adding a more complicated hack.

Quoted 6 lines

Quoted 3 lines

We should fix that limitation instead.

sure, but that will make arch/x86/boot/compressed/head_64.S not need complicated.

But it makes the bootloaders more complicated, and the bootloaders are harder to fix.

Quoted 2 lines · H. Peter Anvin

Quoted 1 line · Yinghai Lu

On Wed, Nov 21, 2012 at 11:56 AM, H. Peter Anvin <[email protected]>

Quoted 5 lines · wrote:

Quoted 5 lines

Quoted 5 lines · Yinghai Lu

Quoted 4 lines

in kernel arch/x86/kernel/head_64.S

it only set first 1G ident mapping. and if it find that code is

above

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

1G, it will set extra ident mapping
for new _text.._end.
To make checking and add extra mapping simple and also save two

extra

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

pages for mapping.
Limit that _text.._end in them same GB range.

No, this is backwards.

Quoted 8 lines

Quoted 6 lines

old one: it limited bzImage in [0,1G) aka the first 1G.

Now we can put it in any aligned 1G range.

So how could it be called backwards?

Because you're adding a more complicated hack.

not that complicated, and it only add 7 lines

       /* same GB ? */
       while ((addr >> 30) != ((addr + size - 1) >> 30)) {
               addr = locate_hole(info, size, align, 0x100000,
                          round_down(addr + size - 1, (1UL<<30)), -1);
               if (addr == ULONG_MAX)
                       die("can not load bzImage64");
       }

Quoted 6 lines

Quoted 6 lines

Quoted 3 lines

We should fix that limitation instead.

sure, but that will make arch/x86/boot/compressed/head_64.S not need complicated.

If that add cover cross GB boundary handling in head_64.S, may need another 100 line code
for checking and etc.

Also will need another two spare pages for cross 512G boundary.

Quoted 2 lines

But it makes the bootloaders more complicated, and the bootloaders

are

Quoted 1 line

harder to fix.

current bootloader does not have this feature and will add the feature. and looks like kexec is only one at this point.

BTW, is there any 64bit boot loader?

Quoted 5 lines

Quoted 5 lines

Quoted 2 lines

We should fix that limitation instead.

sure, but that will make arch/x86/boot/compressed/head_64.S not need complicated.

If that add cover cross GB boundary handling in head_64.S, may need another 100 line code
for checking and etc.

Also will need another two spare pages for cross 512G boundary.

Quoted 2 lines

Also will need another two spare pages for cross 512G boundary.

Doesn't seem like a problem.

Let me be blunt: either we do it right or we don't do it at all.

kexec/arch/x86_64/kexec-bzImage64.c new file +34 -0

+int bzImage64_probe(const char *buf, off_t len)
+{
+	const struct x86_linux_header *header;
+	if ((uintmax_t)len < (uintmax_t)(2 * 512)) {
+		if (probe_debug) {
+			fprintf(stderr, "File is too short to be a bzImage!\n");
+		}
+		return -1;
+	}
+	header = (const struct x86_linux_header *)buf;
+	if (memcmp(header->header_magic, "HdrS", 4) != 0) {
+		if (probe_debug) {
+			fprintf(stderr, "Not a bzImage\n");
+		}
+		return -1;
+	}
+	if (header->boot_sector_magic != 0xAA55) {
+		if (probe_debug) {
+			fprintf(stderr, "No x86 boot sector present\n");
+		}
+		/* No x86 boot sector present */
+		return -1;
+	}
+	if (header->protocol_version < 0x020C) {
+		if (probe_debug) {
+			fprintf(stderr, "Must be at least protocol version 2.12\n");
+		}
+		/* Must be at least protocol version 2.12 */
+		return -1;
+	}
+	if ((header->loadflags & 1) == 0) {
+		if (probe_debug) {
+			fprintf(stderr, "zImage not a bzImage\n");
+		}

On Tue, Nov 20, 2012 at 11:31:38PM -0800, Yinghai Lu wrote:

[..]

Quoted 38 lines

kexec/arch/x86_64/kexec-bzImage64.c new file +38 -0

+int bzImage64_probe(const char *buf, off_t len)
+{
+     const struct x86_linux_header *header;
+     if ((uintmax_t)len < (uintmax_t)(2 * 512)) {
+             if (probe_debug) {
+                     fprintf(stderr, "File is too short to be a bzImage!\n");
+             }
+             return -1;
+     }
+     header = (const struct x86_linux_header *)buf;
+     if (memcmp(header->header_magic, "HdrS", 4) != 0) {
+             if (probe_debug) {
+                     fprintf(stderr, "Not a bzImage\n");
+             }
+             return -1;
+     }
+     if (header->boot_sector_magic != 0xAA55) {
+             if (probe_debug) {
+                     fprintf(stderr, "No x86 boot sector present\n");
+             }
+             /* No x86 boot sector present */
+             return -1;
+     }
+     if (header->protocol_version < 0x020C) {
+             if (probe_debug) {
+                     fprintf(stderr, "Must be at least protocol version 2.12\n");
+             }
+             /* Must be at least protocol version 2.12 */
+             return -1;
+     }
+     if ((header->loadflags & 1) == 0) {
+             if (probe_debug) {
+                     fprintf(stderr, "zImage not a bzImage\n");
+             }
+             /* Not a bzImage */
+             return -1;
+     }
+     if (!(header->xloadflags & 1)) {

kexec/arch/x86_64/kexec-bzImage64.c line 89

Quoted 6 lines

kexec/arch/x86_64/kexec-bzImage64.c new file +6 -0

+             if (probe_debug) {
+                     fprintf(stderr, "Not a bzImage64\n");
+             }
+             /* Must be LOADED_ABOVE_4G */
+             return -1;
+     }

So how do I force a 16bit or 32bit entry using a bzImage64?

Quoted 2 lines

So how do I force a 16bit or 32bit entry using a bzImage64?

kexec -t bzImage -l ....
will load low and use 32bit entry.

kexec -t bzImage64 -l ...
kexec -l ...
will try to load high and use 64bit entry.

Quoted 6 lines · Yinghai Lu

Quoted 2 lines

So how do I force a 16bit or 32bit entry using a bzImage64?

kexec -t bzImage -l ....
will load low and use 32bit entry.

Quoted 4 lines

kexec -t bzImage64 -l ...
kexec -l ...
will try to load high and use 64bit entry.

I don't see any difference...

Quoted 1 line

So how do I force a 16bit or 32bit entry using a bzImage64?

kexec -t bzImage -l ....
will load low and use 32bit entry.

kexec -t bzImage64 -l ...
kexec -l ...
will try to load high and use 64bit entry.

On Wed, Nov 21, 2012 at 11:50:56AM -0800, Yinghai Lu wrote:

[..]

Quoted 5 lines

Quoted 1 line

So how do I force a 16bit or 32bit entry using a bzImage64?

kexec -t bzImage -l ....
will load low and use 32bit entry.

Ok, so user needs to enforce image type (using -t option) to bzImage (for a bzImage which supports 64bit entry point) to be able to use 32bit entry.

I think a better option is that bzImage64 loader parses the user specified entry options and call into 32bit bzImage loader if user is asking for 32bit or 16bit entry. For 16bit, we already have option --real-mode option. May be we need to introduce another one for forcing 32bit entry, say --entry-32bit or --protected-mode (whatever makes sense).

Quoted 13 lines · Vivek Goyal

On Wed, Nov 21, 2012 at 11:50:56AM -0800, Yinghai Lu wrote:

[..]

Quoted 5 lines

Quoted 1 line

So how do I force a 16bit or 32bit entry using a bzImage64?

kexec -t bzImage -l ....
will load low and use 32bit entry.

Ok, so user needs to enforce image type (using -t option) to bzImage (for a bzImage which supports 64bit entry point) to be able to use 32bit entry.

Quoted 5 lines

I think a better option is that bzImage64 loader parses the user specified entry options and call into 32bit bzImage loader if user is asking for 32bit or 16bit entry. For 16bit, we already have option --real-mode option. May be we need to introduce another one for forcing 32bit entry, say --entry-32bit or --protected-mode (whatever makes sense).

that is doable.

add checking entry-32bit and real-mode checking in kexec-bzImage64.c and bail early to leave kexec-bzImage.c to take over.

Or actually can we do reverse. Do not introduce new image format bzImage64. In existing bzImage loader if bzImage version is greater than 0x020c (or whatever version has 64bit entry extension), just call into load_bzImage64().

Quoted 41 lines · Vivek Goyal

On Tue, Nov 20, 2012 at 11:31:38PM -0800, Yinghai Lu wrote:

[..]

Quoted 38 lines

kexec/arch/x86_64/kexec-bzImage64.c new file +38 -0

+int bzImage64_probe(const char *buf, off_t len)
+{
+     const struct x86_linux_header *header;
+     if ((uintmax_t)len < (uintmax_t)(2 * 512)) {
+             if (probe_debug) {
+                     fprintf(stderr, "File is too short to be a bzImage!\n");
+             }
+             return -1;
+     }
+     header = (const struct x86_linux_header *)buf;
+     if (memcmp(header->header_magic, "HdrS", 4) != 0) {
+             if (probe_debug) {
+                     fprintf(stderr, "Not a bzImage\n");
+             }
+             return -1;
+     }
+     if (header->boot_sector_magic != 0xAA55) {
+             if (probe_debug) {
+                     fprintf(stderr, "No x86 boot sector present\n");
+             }
+             /* No x86 boot sector present */
+             return -1;
+     }
+     if (header->protocol_version < 0x020C) {
+             if (probe_debug) {
+                     fprintf(stderr, "Must be at least protocol version 2.12\n");
+             }
+             /* Must be at least protocol version 2.12 */
+             return -1;
+     }
+     if ((header->loadflags & 1) == 0) {
+             if (probe_debug) {
+                     fprintf(stderr, "zImage not a bzImage\n");
+             }
+             /* Not a bzImage */
+             return -1;
+     }
+     if (!(header->xloadflags & 1)) {

Quoted 8 lines

kexec/arch/x86_64/kexec-bzImage64.c line 89

Quoted 6 lines

kexec/arch/x86_64/kexec-bzImage64.c new file +6 -0

+             if (probe_debug) {
+                     fprintf(stderr, "Not a bzImage64\n");
+             }
+             /* Must be LOADED_ABOVE_4G */
+             return -1;
+     }

So how do I force a 16bit or 32bit entry using a bzImage64?

kexec -t bzImage -l ....
will load low and use 32bit entry.

kexec -t bzImage64 -l ...
kexec -l ...
will try to load high and use 64bit entry.

Quoted 7 lines · Yinghai Lu

Quoted 2 lines · Vivek Goyal

So how do I force a 16bit or 32bit entry using a bzImage64?

kexec -t bzImage -l ....
will load low and use 32bit entry.

Quoted 3 lines

kexec -t bzImage64 -l ...
kexec -l ...
will try to load high and use 64bit entry.

Also bzImage64 is not really a new image format. It is just enhancement of bzImage format. We keep on doing extention of bzImage and don't call it a new image format. I am not sure how good an idea it is to export the notion of new image type bzImage64 to user.