Re: [PATCH] x86 boot: Pass E820 memory map entries more than 128via linked list of setup data

[Huang, Ying]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/