Re: [Patch 1/1] x86 efi: Fill all reserved memmap entries if add_efi_memmapspecified.

From: Mike Travis
Date: Wed May 26 2010 - 15:10:13 EST




H. Peter Anvin wrote:
On 05/26/2010 11:47 AM, Mike Travis wrote:
I didn't know bootloader had a problem two years ago And as I mentioned,
I'm open to suggestions but what I've heard is "fix the bootloader". What
I don't know is how to do that.

I see that BIOS sets up an e820 compatible memory map and extra memmap
entries "somewhere". EFI seems to pick this up via ELILO and somehow
the kernel finds these extra memmap entries.

So my question is what is broken? Should the bootloader not use the
standard e820 memmap at all, and invent another way of passing the
memmap entries? And what about EFI grub, shouldn't that also change?
And how does this affect compatibility?

I'm in the dark here as to how the bootloader manages to pass these
entries from BIOS to the kernel, and how far I can go modifying these
things when I don't completely understand them. The last problem I
worked on in ELILO I couldn't even print messages as that invalidated
the "magic key" and it would loop endlessly between ELILO and BIOS.

The other thing is priorities. If something is working and not
causing undue problems, it does not get higher priority than issues
that cause complete system failure. I've suggested a workable
(maybe short term solution), that gets us past the boot, and on to
the other potentially far more important problems.

And p.s. it's been way longer than two years... ;-) [the other thing
to consider is we haven't had real hardware that long, and many, many,
many problems have surfaced since then. The memmap problem only
showed up when we ran over 128 entries. When has that happened before?
And how was it handled then?]


The 128-entry limit (caused by the fixed array in struct setup_info) was
brought to our attention in 2007. At that time, a number of
alternatives were discussed; Linus in particular was adamant that this
should be handled in the bootloader, and not by the kernel.

The result was that we added a facility to the kernel to supply
arbitrary information via a linked list. That has been in there since
at least early 2008. However, noone who cares about this issue has
bothered stepping up and put the support into the bootloaders --
instead, we got suckered into accepting a "temporary hack" which only
has had the effect of giving you guys yet another excuse not to do what
you signed off to do in the first place.

Accordingly, the right answer for me to do is to veto this and any
further patches which enable you to skirt your responsibility, and I'm
getting damned close to doing so.

-hpa


Ahh, so you aren't referring to me personally, but someone else? I'll
do some digging into finding that mail thread to at least come up to
speed. Had it been tossed to me in 2007 I would have dealt with it,
but it's on my todo list now.

Thanks,
Mike

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