linux-kernel - Re: [PATCH -mm 0/4] x86_64 boot: Add linked listof struct setup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 27 Mar 2008 17:25:36 +0800
From:	"Huang, Ying" <ying.huang@...el.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"H. Peter Anvin" <hpa@...or.com>, andi@...stfloor.org,
	mingo@...hat.com, tglx@...utronix.de, Paul Jackson <pj@....com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm 0/4] x86_64 boot: Add linked listof struct
	setup_data to boot protocol

On Thu, 2008-03-27 at 09:32 +0100, Ingo Molnar wrote:
> * Huang, Ying <ying.huang@...el.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/