linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Alexander van Heukelum <heukelum@fastmail.fm>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Alexander van Heukelum <heukelum@mailshack.com>
Subject: Re: [PATCH] Fix alignment of early reservation for EBDA
Date: Wed, 27 Feb 2008 15:25:14 +0100	[thread overview]
Message-ID: <47C572CA.2010604@suse.de> (raw)
In-Reply-To: <1203958478.20033.1239002461@webmail.messagingengine.com>

Alexander van Heukelum wrote:
> On Sun, 24 Feb 2008 18:18:16 -0800, "H. Peter Anvin" <hpa@zytor.com>
> said:
>> Alexander van Heukelum wrote:
>>> early res: 3 [9f000-9ffff] EBDA
>>>
>>> Is it really necessary to force the allocation to a page boundary?
>> It is, but that rounding gets done in reserve_bootmem() anyway, so there 
>> is no need for the arch-specific code to do it.
>>
>> The 32-bit EBDA code hard-codes a size of 4K, which is probably equally 
>> wrong; my gut feel is that the right thing to do is to reserve from the 
>> EBDA up to the 640K mark (some BIOSes use an area like that for SMM 
>> stuff), possibly with some sanity checking.

It's not needed, the e820 maps are always correct for modern systems in
this case as far  as I know.


> 
>         /* reserve all memory between lowmem and the 1MB mark */
>         reserve_early(lowmem, 0x100000, "BIOS reserved");

The i386 kernel did this always, but I intentionally removed it from the
64bit kernel because all the modern BIOS seem to correctly report holes
in this area. Only didn't do it on i386 because there were some concerns
of very old systems not doing this correctly.

My suspicion is that modern Windows systems rely on this, that is why
BIOSes typically get it correct now.

I think it should be only undone if you have a concrete case where it
breaks not just based on someone's gut feel. Sure it's not a lot of
memory, but why waste memory unnecessarily?

-Andi


      parent reply	other threads:[~2008-02-27 14:23 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-24 17:46 [PATCH] Fix alignment of early reservation for EBDA Alexander van Heukelum
2008-02-24 19:27 ` Andi Kleen
2008-02-24 19:41 ` Ingo Molnar
2008-02-24 20:53   ` Alexander van Heukelum
2008-02-25  2:18 ` H. Peter Anvin
2008-02-25 16:54   ` Alexander van Heukelum
2008-02-25 17:01     ` Ingo Molnar
2008-02-25 18:07       ` [PATCH] reserve_early end-of-conventional-memory to 1MB Alexander van Heukelum
2008-02-25 18:13         ` H. Peter Anvin
2008-02-25 19:46           ` Alexander van Heukelum
2008-02-25 21:17             ` H. Peter Anvin
2008-02-26  9:30             ` Ingo Molnar
2008-02-27 14:26               ` Andi Kleen
2008-02-27 14:38               ` [PATCH] reserve_early end-of-conventional-memory to 1MB II - some numbers to put it into perspective Andi Kleen
2008-02-27 16:44                 ` H. Peter Anvin
2008-02-27 20:01                 ` Alexander van Heukelum
2008-02-28 13:13         ` [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit Alexander van Heukelum
2008-02-28 13:28           ` [RFC] use realmode code to reserve end-of-conventional-memory to 1MB Alexander van Heukelum
2008-02-28 21:12             ` Ian Campbell
2008-02-28 21:14               ` H. Peter Anvin
2008-02-28 23:16                 ` Ian Campbell
2008-02-29 20:00                   ` Ingo Molnar
2008-03-04 11:41                   ` Mark McLoughlin
2008-03-04 14:33                     ` Ingo Molnar
2008-03-04 15:12                       ` Ian Campbell
2008-03-04 15:13                       ` Jeremy Fitzhardinge
2008-03-04 15:25                         ` Ingo Molnar
2008-03-04 16:02                           ` Jeremy Fitzhardinge
2008-03-04 16:15                             ` Ingo Molnar
2008-03-04 16:15                       ` Mark McLoughlin
2008-03-04 16:23                         ` Ingo Molnar
2008-03-04 17:44                   ` Jeremy Fitzhardinge
2008-03-05 15:59                   ` Eduardo Habkost
2008-03-05 16:08                     ` H. Peter Anvin
2008-03-05 16:53                       ` Eduardo Habkost
2008-03-05 17:28                         ` H. Peter Anvin
2008-03-05 17:28                           ` Jeremy Fitzhardinge
2008-03-05 17:38                             ` H. Peter Anvin
2008-03-05 16:38                     ` Jeremy Fitzhardinge
2008-03-05 17:27                       ` H. Peter Anvin
2008-02-28 21:09           ` [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit Ian Campbell
2008-02-29 11:49             ` Alexander van Heukelum
2008-02-29 17:14               ` Mark McLoughlin
2008-02-29 18:38                 ` Alexander van Heukelum
2008-02-29 18:44                   ` H. Peter Anvin
2008-02-29 18:56                     ` Alexander van Heukelum
2008-02-29 22:06                   ` Mark McLoughlin
2008-02-29 22:26                     ` Alexander van Heukelum
2008-03-01 16:09                     ` [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit v2 Alexander van Heukelum
2008-03-01 16:12                       ` [PATCH] reserve end-of-conventional-memory to 1MB on 64-bit add-on Alexander van Heukelum
2008-03-04 11:44                       ` [PATCH] reserve end-of-conventional-memory to 1MB on 32-bit v2 Mark McLoughlin
2008-03-04 13:31                         ` Alexander van Heukelum
2008-03-04 14:49                         ` Ingo Molnar
2008-03-04 15:16                           ` Mark McLoughlin
2008-03-04 15:24                             ` Ingo Molnar
2008-03-04 15:18                         ` Jeremy Fitzhardinge
2008-03-04 16:51                           ` Alexander van Heukelum
2008-03-04 17:05                             ` H. Peter Anvin
2008-03-04 17:11                             ` Jeremy Fitzhardinge
2008-03-04 18:57                               ` [PATCH] reserve end-of-conventional-memory to 1MB, 32-bit, use paravirt_enabled Alexander van Heukelum
2008-03-04 19:12                                 ` [PATCH] reserve end-of-conventional-memory to 1MB, 64-bit, " Alexander van Heukelum
2008-02-27 14:25     ` Andi Kleen [this message]

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=47C572CA.2010604@suse.de \
    --to=ak@suse.de \
    --cc=heukelum@fastmail.fm \
    --cc=heukelum@mailshack.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).