* [PATCH -mm 0/4] x86_64 boot: Add linked listof struct setup_data to boot protocol
@ 2008-03-27 7:09 Huang, Ying
2008-03-27 8:32 ` Ingo Molnar
0 siblings, 1 reply; 9+ messages in thread
From: Huang, Ying @ 2008-03-27 7:09 UTC (permalink / raw)
To: H. Peter Anvin, andi, mingo, tglx, Paul Jackson; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH -mm 0/4] x86_64 boot: Add linked listof struct setup_data to boot protocol
2008-03-27 7:09 [PATCH -mm 0/4] x86_64 boot: Add linked listof struct setup_data to boot protocol Huang, Ying
@ 2008-03-27 8:32 ` Ingo Molnar
2008-03-27 9:02 ` Paul Jackson
2008-03-27 9:25 ` Huang, Ying
0 siblings, 2 replies; 9+ messages in thread
From: Ingo Molnar @ 2008-03-27 8:32 UTC (permalink / raw)
To: Huang, Ying; +Cc: H. Peter Anvin, andi, mingo, tglx, Paul Jackson, linux-kernel
* Huang, Ying <ying.huang@intel.com> wrote:
> 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.
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.
> Now, only the x86_64 is 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 <mingo@elte.hu>
Date: Thu Mar 27 09:18:44 CET 2008
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
include/asm-x86/e820.h | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: linux-x86.q/include/asm-x86/e820.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/e820.h
+++ linux-x86.q/include/asm-x86/e820.h
@@ -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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH -mm 0/4] x86_64 boot: Add linked listof struct setup_data to boot protocol
2008-03-27 8:32 ` Ingo Molnar
@ 2008-03-27 9:02 ` Paul Jackson
2008-03-27 9:09 ` Ingo Molnar
2008-03-27 9:25 ` Huang, Ying
1 sibling, 1 reply; 9+ messages in thread
From: Paul Jackson @ 2008-03-27 9:02 UTC (permalink / raw)
To: Ingo Molnar; +Cc: ying.huang, hpa, andi, mingo, tglx, linux-kernel
Ingo asked:
> 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?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH -mm 0/4] x86_64 boot: Add linked listof struct setup_data to boot protocol
2008-03-27 9:02 ` Paul Jackson
@ 2008-03-27 9:09 ` Ingo Molnar
2008-03-27 9:21 ` Paul Jackson
0 siblings, 1 reply; 9+ messages in thread
From: Ingo Molnar @ 2008-03-27 9:09 UTC (permalink / raw)
To: Paul Jackson; +Cc: ying.huang, hpa, andi, mingo, tglx, linux-kernel
* Paul Jackson <pj@sgi.com> wrote:
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH -mm 0/4] x86_64 boot: Add linked listof struct setup_data to boot protocol
2008-03-27 9:09 ` Ingo Molnar
@ 2008-03-27 9:21 ` Paul Jackson
2008-03-27 9:46 ` Ingo Molnar
0 siblings, 1 reply; 9+ messages in thread
From: Paul Jackson @ 2008-03-27 9:21 UTC (permalink / raw)
To: Ingo Molnar; +Cc: ying.huang, hpa, andi, mingo, tglx, linux-kernel
Ingo wrote:
> 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.
> 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.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH -mm 0/4] x86_64 boot: Add linked listof struct setup_data to boot protocol
2008-03-27 8:32 ` Ingo Molnar
2008-03-27 9:02 ` Paul Jackson
@ 2008-03-27 9:25 ` Huang, Ying
2008-03-27 9:47 ` Ingo Molnar
1 sibling, 1 reply; 9+ messages in thread
From: Huang, Ying @ 2008-03-27 9:25 UTC (permalink / raw)
To: Ingo Molnar; +Cc: H. Peter Anvin, andi, mingo, tglx, Paul Jackson, linux-kernel
On Thu, 2008-03-27 at 09:32 +0100, Ingo Molnar wrote:
> * Huang, Ying <ying.huang@intel.com> wrote:
>
> > 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.
>
> 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.
> ?
>
> 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.
> > Now, only the x86_64 is 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH -mm 0/4] x86_64 boot: Add linked listof struct setup_data to boot protocol
2008-03-27 9:21 ` Paul Jackson
@ 2008-03-27 9:46 ` Ingo Molnar
0 siblings, 0 replies; 9+ messages in thread
From: Ingo Molnar @ 2008-03-27 9:46 UTC (permalink / raw)
To: Paul Jackson; +Cc: ying.huang, hpa, andi, mingo, tglx, linux-kernel
* Paul Jackson <pj@sgi.com> wrote:
> Ingo wrote:
> > 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH -mm 0/4] x86_64 boot: Add linked listof struct setup_data to boot protocol
2008-03-27 9:25 ` Huang, Ying
@ 2008-03-27 9:47 ` Ingo Molnar
2008-03-27 16:36 ` H. Peter Anvin
0 siblings, 1 reply; 9+ messages in thread
From: Ingo Molnar @ 2008-03-27 9:47 UTC (permalink / raw)
To: Huang, Ying; +Cc: H. Peter Anvin, andi, mingo, tglx, Paul Jackson, linux-kernel
* Huang, Ying <ying.huang@intel.com> wrote:
> > 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.
correct, e820 space manipulations is how it should be done. Peter, any
progress on that project?
Ingo
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH -mm 0/4] x86_64 boot: Add linked listof struct setup_data to boot protocol
2008-03-27 9:47 ` Ingo Molnar
@ 2008-03-27 16:36 ` H. Peter Anvin
0 siblings, 0 replies; 9+ messages in thread
From: H. Peter Anvin @ 2008-03-27 16:36 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Huang, Ying, andi, mingo, tglx, Paul Jackson, linux-kernel
Ingo Molnar wrote:
> * Huang, Ying <ying.huang@intel.com> wrote:
>
>>> 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.
>
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-03-27 16:38 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-03-27 7:09 [PATCH -mm 0/4] x86_64 boot: Add linked listof struct setup_data to boot protocol Huang, Ying
2008-03-27 8:32 ` Ingo Molnar
2008-03-27 9:02 ` Paul Jackson
2008-03-27 9:09 ` Ingo Molnar
2008-03-27 9:21 ` Paul Jackson
2008-03-27 9:46 ` Ingo Molnar
2008-03-27 9:25 ` Huang, Ying
2008-03-27 9:47 ` Ingo Molnar
2008-03-27 16:36 ` H. Peter Anvin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox