public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86 Boot enhancements, boot protocol 2.04 7/9
Date: Thu, 04 Apr 2002 10:30:44 -0800	[thread overview]
Message-ID: <3CAC9BD4.5050500@zytor.com> (raw)
In-Reply-To: <m1ofh0spik.fsf@frodo.biederman.org>	<a8flgc$ms2$1@cesium.transmeta.com> <m1lmc3qtaz.fsf@frodo.biederman.org>

Eric W. Biederman wrote:
> 
> It's not legacy it is still the optimal address.  The amount of memory
> required to load the kernel is directly related to how much low memory
> the decompresser can use.  If you move it lower you need more memory
> above 1MB to load the kernel.
> 
> To load the real mode code at < 0x90000 requires a fairly
> sophisticated bootloader.  You have already convinced me how it is bad
> for bootloaders to make BIOS calls on behalf of the kernel, and how
> bad it is to need bootloaders to change.  So unless the real mode code
> does the int 12 call itself and relocates itself as high as it can go
> I really don't see the default load address changing.  And I am
> documenting the default load address.
> 

No, that's not how that works in reality.  In practice, the boot loader 
picks the lowest address it can practically use, in order to minimize 
the conventional memory ceiling.  For example, PXELINUX always loads at 
0x50000, simply because odds that you have a PXE stack and can use 
0x90000 is about zero to none.  In fact, these days there are enough 
BIOSes that load stuff in the high part of memory that using 0x90000 is 
actively dangerous and **needs to be avoided**.  Theoretically, you're 
right; it adds a  very small amount of memory to the decompression.  If 
that matters, there is actually a very easy way to deal with it: for any 
boot loader there is a Lowest Usable Address (conventional memory 
ceiling).  You can use INT 12h and adjust the load address all the way 
up to 0x90000 if the conventional memory ceiling permits; this usually 
is something like five lines of assembly.

> I'd like to change the way we do this, so I'm going to stare at this
> problem a little bit more.  Changing the default load address and
> still being able to compute how much memory the kernel is going
> to use is a challenge.

There can't be a "default load address".  0x90000 is actively dangerous 
and trying to encourage it for anything than legacy kernels is WRONG. 
If you can't handle this, then you need to go back to the drawing board.

	-hpa





  reply	other threads:[~2002-04-04 18:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-03 16:41 [PATCH] x86 Boot enhancements, boot protocol 2.04 7/9 Eric W. Biederman
2002-04-03 19:15 ` Tom Rini
2002-04-04  3:23   ` Eric W. Biederman
2002-04-04 14:10     ` Tom Rini
2002-04-04 15:38       ` Eric W. Biederman
2002-04-03 19:34 ` H. Peter Anvin
2002-04-04 17:15   ` Eric W. Biederman
2002-04-04 18:30     ` H. Peter Anvin [this message]
2002-04-04 19:04       ` Eric W. Biederman
2002-04-04 19:19         ` H. Peter Anvin
2002-04-04 19:32           ` Eric W. Biederman
2002-04-05 21:30           ` Eric W. Biederman
2002-04-05 22:04             ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3CAC9BD4.5050500@zytor.com \
    --to=hpa@zytor.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox