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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1214205686.26437.18.camel@caritas-dev.intel.com>
Date:	Mon, 23 Jun 2008 15:21:26 +0800
From:	"Huang, Ying" <ying.huang@...el.com>
To:	Paul Jackson <pj@....com>
Cc:	mingo@...e.hu, hpa@...or.com, andi@...stfloor.org,
	mingo@...hat.com, tglx@...utronix.de, linux-kernel@...r.kernel.org,
	yhlu.kernel@...il.com
Subject: Re: [PATCH] x86 boot: Pass E820 memory map entries more than 128
	via linked list of setup data

On Mon, 2008-06-23 at 01:53 -0500, Paul Jackson wrote:
> Huang Ying wrote:
> > With this patch, your previous patch:
> > 
> > x86 boot: add code to add BIOS provided EFI memory entries to kernel
> > 
> > is not necessary, so can be reversed.
> > 
> > What do you think about that?
> 
> ... the same thing I thought about it when you asked this question
> last month, in post http://lkml.org/lkml/2008/5/26/307.
> 
> Please see my reply in http://lkml.org/lkml/2008/5/28/59.
> It was lengthy and carefully researched, so I won't repeat
> it here.
> 
> In short, we still need it.  The key kernel routine that adds
> additional EFI entries to the existing E820 map is just 20 or so
> fairly easy lines.  We agree that it doesn't handle some of what your
> more extended work with a linked list of setup data handles (such as
> additional EDD entries), but it does handle additional memory map
> (node) entries using the existing data structure interface between
> the firmware and kernel.

EFI memmap based code versus E820 EXT based code:

1. Copying from EFI memory map to E820 map in kernel is not necessary,
because now it can be done in boot-loader with extended E820 memory map
via linked list of setup data.

2. EFI memmap based code only works when CONFIG_EFI is defined, that is
EFI runtime service is enabled. If you do not want to enable EFI runtime
services, you lose some memory map entries. Considering that kexec does
not support EFI runtime service so far.

3. EFI memmap based code is EFI specific, while E820 EXT based code is
general. It can be used for such as legacy BIOS, LinuxBIOS, kexec, etc.

4. Current EFI memmap based code does not work properly in all
situation, for example it can not works with kernel parameter:
"memmap=exactmap, memmap=<xxx>, ...", "mem=<xxx>" or "noefi".

So, I think it is better to remove "EFI memmap based code".

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ