Re: [PATCH] reserve_early end-of-conventional-memory to 1MB

From: Alexander van Heukelum
Date: Mon Feb 25 2008 - 14:47:29 EST


On Mon, 25 Feb 2008 10:13:17 -0800, "H. Peter Anvin" <hpa@xxxxxxxxx>
said:
> Alexander van Heukelum wrote:
> >
> > arch/x86/kernel/head64.c | 45 +++++++++++++++++++++++++++------------------
> > 1 files changed, 27 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
> > index 38f32e7..b684552 100644
> > --- a/arch/x86/kernel/head64.c
> > +++ b/arch/x86/kernel/head64.c
> > @@ -49,33 +49,42 @@ static void __init copy_bootdata(char *real_mode_data)
> > }
> > }
> >
> > -#define EBDA_ADDR_POINTER 0x40E
> > +#define BIOS_EBDA_SEGMENT 0x40E
> > +#define BIOS_LOWMEM_KILOBYTES 0x413
> >
>
> Linus has specific comments in the 32-bit code that states we do not
> want to use address 0x413 for anything - if nothing else because it's
> often lowered when there is boottime code involved like CD-ROM booting
> or PXE.

Hello hpa,

I failed to find a comment referring to 0x413 or int 0x12 in
arch/x86/kernel. I do know the comment in Documentation/i386/boot.txt,
however, suggesting that "INT 12h" _should_ be used, but that it would
be pointless for zImage and old bzImage kernels, because they _have_
to be started from 0x90000 anyway. New bzImage kernels do not have
this limitation, and smart bootloaders simply put them at much
lower addresses, like 0x40000. (I know: you know.) My point is just
that the argument not to use 0x413 in the bootloader is not valid
for this case.

That leaves the possibility that code/data is inserted at the top of
conventional memory by either the BIOS or some kind of bootloader.
My view on this is that this code/data should be preserved: it
was specifically asked from us by lowering 0x413. One just loses
a tiny bit of usable memory, and if the program booting the kernel
knows better it can unload the driver if it wants to. It's just
not a kernel problem.

> Either way, the code should be shared between 32 and 64 bits.
> There is nothing bitsize-specific about it!

Of course. That's also why I already added the old-Dell case ;).
But one problem at a time, please!

Greetings,
Alexander
--
Alexander van Heukelum
heukelum@xxxxxxxxxxx

--
http://www.fastmail.fm - I mean, what is it about a decent email service?

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