linux-kernel - Re: early_res and find_e820

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]

Message-Id: <200803041141.28404.ak@suse.de>
Date:	Tue, 4 Mar 2008 11:41:28 +0100
From:	Andi Kleen <ak@...e.de>
To:	"Huang, Ying" <ying.huang@...el.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: early_res and find_e820_area for i386?

On Tuesday 04 March 2008 04:38:03 Huang, Ying wrote:

> Is it better to implement early_res and find_e820_area on i386? Can we
> trust E820 table on i386?

The 64bit code is certainly more flexible and cleaner, but also
much more complicated.. But on the other hand i386 has simpler requirements 
so it didn't really need the full power. I didn't think that had changed.

The key change if you wanted to do that would be to change all the unsigned longs to
pfns -- the 64bit code is not all together 32bit clean. Or perhaps better
pfns + page offset since some of the allocations don't need to be page aligned
and would waste memory if they were forced to pfns.

An alternative might be to use the new allocators only for <4GB
on i386 and keep handling >4GB in some other way.

-Andi
--
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/