x86_64 boot: Add linked listof struct setup_data to boot protocol
cover x86_64 boot: Add linked listof struct setup_data to boot protocol
This patchset adds the linked list of struct setup_data to boot protocol. This is needed by EDD information and some SGI machine with E820 entry number > 128.
Now, only the x86_64 is supported. The i386 can be supported after early reservation mechanism for x86 is available.
This patchset is based on 2.6.25-rc5-mm1 and has been tested on Intel x86_64 machine.
Best Regards,
Huang Ying
Quoted 3 lines · Huang, Ying
This patchset adds the linked list of struct
setup_datato boot protocol. This is needed by EDD information and some SGI machine with E820 entry number > 128.
what happens with the SGI machine - does it crash (because we overflow the e820 array) - or does it boot up with less memory available and we get this bootup warning:
Ooops! Too many entries in the memory map!
?
I guess we should we raise E820MAX from 128 to 256 (patch below), but if we do something worse (crash), we should fix that side-effect as well.
Quoted 2 lines
Now, only the
x86_64is supported. The i386 can be supported after early reservation mechanism for x86 is available.
could you try to do that nevertheless? We generally prefer feature patches after sensible unification has been done.
Ingo
-------------->
Subject: x86: more e820
From: Ingo Molnar <[email protected]>
Date: Thu Mar 27 09:18:44 CET 2008
--- include/asm-x86/e820.h | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
include/asm-x86/e820.h +4 -3
@@ -1,8 +1,9 @@#ifndef __ASM_E820_H#define __ASM_E820_H -#define E820MAP 0x2d0/* our map */ -#define E820MAX 128/* number of entries in E820MAP */ -#define E820NR 0x1e8/* # entries in E820MAP */ + +#define E820MAP 0x2d0/* our map */ +#define E820MAX 256/* number of entries in E820MAP */ +#define E820NR 0x1e8/* # entries in E820MAP */ #define E820_RAM 1#define E820_RESERVED 2
Ingo asked:
Quoted 1 line
what happens with the SGI machine
Unless I misunderstand your post, Ingo, you don't need an SGI machine for this one, ... just a compiler ;).
In the file arch/x86/boot/main.c, see the line:
BUILD_BUG_ON(sizeof boot_params != 4096);
This BUILD_BUG is serving as a reminder that the PC's "zero page", such as is encoded in the struct boot_params (include/asm-x86/bootparam.h) has to be exactly 4096 bytes by traditional PC architecture. One of the entries in that struct is:
struct e820entry e820_map[E820MAX]; /* 0x2d0 */
H. Peter Anvin, Andi Kleen and Huang had further discussion in an earlier email thread as to how to best extend this limit. I trust that Huang's patch represents their concensus of that discussion.
By the way, Peter, do you have any idea what that E820NR define is doing in include/asm-x86/e820.h ... it looks like useless redundancy to me?
Signature · 3 lines
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.940.382.4214Quoted 3 lines · Paul Jackson
In the file
arch/x86/boot/main.c, see the line:BUILD_BUG_ON(sizeof boot_params != 4096);
oh well, indeed. I was hoping for some simple short-term solution as well that could go into 2.6.25.
( in case anyone knows about any other stupidly shortsighted limit we
have in arch/x86 that is not being worked on yet, please tell us _before_ we hit it with real hardware ... )
Ingo
Quoted 1 line · Ingo
stupidly shortsighted limit ...
Eh ... I don't think all that shortsighted ... that 4096 limit has probably been around longer than Linux. Linus or hpa or others would know the history better than I do.
Quoted 1 line
in case anyone knows about any other ... please tell us
We're pushing into and finding those limits as best we can, here at SGI ;). You've heard of the canary in the mine shaft, and the elephant in the room. Well, we're the elephant in the canary cage.
Signature · 3 lines
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.940.382.4214Quoted 6 lines · Paul Jackson
Quoted 1 line · Ingo
stupidly shortsighted limit ...
Eh ... I don't think all that shortsighted ... that 4096 limit has probably been around longer than Linux. Linus or hpa or others would know the history better than I do.
the limit for boot parameters is 2048 bytes - the BUILD_WARN_ON() checks for the sum of the two boot parameter areas. We used empty_zero_page for boot parameter passing for a near eternity - 2K for the command line (which used to be clipped - recently upped to true 2048), and 2K for the boot parameters.
As a historic/nostalgic sidenote: the 2048 limit is not as old as Linux, version 0.11 of Linux had 512 bytes of special area for boot parameters, at 0x90000-0x901FF.
having fixed-length 2K buffering ABI between two historically rather inflexible pieces of software (the bootloader and the kernel), at a very fragile and under-capable junction of our bootstrap (very early during bootup) _is_ shortsighted. Granted, it's a difficult area to change but still it's a nasty limit - as you have found it out first-hand ;-)
Ingo
Quoted 11 lines · Ingo Molnar
Quoted 3 lines · Huang, Ying
This patchset adds the linked list of struct
setup_datato boot protocol. This is needed by EDD information and some SGI machine with E820 entry number > 128.what happens with the SGI machine - does it crash (because we overflow the e820 array) - or does it boot up with less memory available and we get this bootup warning:
Ooops! Too many entries in the memory map!
SGI guys want to build machine with NUMA node number > 128, so they need e820 entry number > 128. In current boot protocol, this can not be passed by boot loader to kernel. So the boot protocol need to be extended.
Quoted 4 lines
?
I guess we should we raise E820MAX from 128 to 256 (patch below), but if we do something worse (crash), we should fix that side-effect as well.
Because the size of "zero page" is limited to 4k, the entry number of E820 table in "zero page" is limited too. We can not raise it to 256, because 20 * 256 = 5120 > 4096.
Quoted 5 lines
Quoted 2 lines
Now, only the
x86_64is supported. The i386 can be supported after early reservation mechanism for x86 is available.could you try to do that nevertheless? We generally prefer feature patches after sensible unification has been done.
I try to port reserve_early() to i386 before. But it is said that the reserve_early() should be replaced by e820 based early reservation/allocation mechanism on i386 and x86_64. So I think I should wait for it.
Best Regards,
Huang Ying
Quoted 7 lines · Huang, Ying
Quoted 2 lines
could you try to do that nevertheless? We generally prefer feature patches after sensible unification has been done.
I try to port
reserve_early()to i386 before. But it is said that thereserve_early()should be replaced by e820 based early reservation/allocation mechanism on i386 andx86_64. So I think I should wait for it.
correct, e820 space manipulations is how it should be done. Peter, any progress on that project?
Ingo
Quoted 7 lines · Ingo Molnar
Quoted 2 lines · Huang, Ying
Quoted 1 line
could you try to do that nevertheless? We generally prefer feature patches after sensible unification has been done.
I try to port
reserve_early()to i386 before. But it is said that thereserve_early()should be replaced by e820 based early reservation/allocation mechanism on i386 andx86_64. So I think I should wait for it.correct, e820 space manipulations is how it should be done. Peter, any progress on that project?
It's not all that complex of a piece of code, but the testing is painful (fortunately, I have some code which has been at least partially validated already.)
I have been working on a nonkernel project this week (http://syslinux.zytor.com/archives/2008-March/009723.html), but I'm hoping to look at it next week.
-hpa