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, 15 May 2008 19:03:40 -0500
From:	Paul Jackson <pj@....com>
To:	"Huang, Ying" <ying.huang@...el.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Andi Kleen" <andi@...stfloor.org>, "Ingo Molnar" <mingo@...e.hu>
Cc:	akpm@...ux-foundation.org, tglx@...utronix.de, steiner@....com,
	travis@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/10] x86 boot: add code to add BIOS provided EFI
 memory entries to kernel

Ying Huang, H. Peter Anvin, Andi Kleen, Ingo Molnar (and anyone else
interested):

I invite your review of these patches, especially 7, 9 and 10 of the
set of 10, that I posted yesterday.

In combination, I believe that they allow passing more than E820MAX
(128) memory map entries from EFI firmware to a booting kernel, beyond
the E820 constraints of non-EFI legacy BIOS's, without changing the
EFI interface interface.  My understanding of the EFI interface is
that it already allows for this, and that we just needed to add the
ability, as done in these patches, for the kernel to make use of this.

The separate work of Ying Huang, to leverage Andi's reserve_early()
and to revise the EFI interface, to pass multiple pages of information
from the EFI firmware to the kernel at boot is, I presume, still needed
for other extensions, such as for passing more hard disk drive entries.

But the particular extension of interest to me, passing more memory map
entries (for future x86_64 systems with more than 128 memory nodes)
can I believe be done fairly easily, with these patches, with no need
of revising the EFI interface or reserving early memory, and with code
that is compatible across both x86_32 and x86_64 arch's.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@....com> 1.940.382.4214
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ