mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Yinghai Lu" <yhlu.kernel@gmail.com>
To: "Paul Jackson" <pj@sgi.com>, "Andi Kleen" <andi@firstfloor.org>,
	"H. Peter Anvin" <hpa@zytor.com>
Cc: mingo@elte.hu, bwalle@suse.de, hannes@saeurebad.de,
	ying.huang@intel.com, linux-kernel@vger.kernel.org,
	steiner@sgi.com
Subject: Re: Confusions with reserve_early, reserve_bootmem, e820, efi, ... on x86_64
Date: Thu, 12 Jun 2008 13:29:20 -0700	[thread overview]
Message-ID: <86802c440806121329s54bb1e6dobaaa15c26e7dc81c@mail.gmail.com> (raw)
In-Reply-To: <20080612151032.5a59309b.pj@sgi.com>

On Thu, Jun 12, 2008 at 1:10 PM, Paul Jackson <pj@sgi.com> wrote:
> Yinghai wrote:
>> that function seems to increase the ebda to workaround some broken
>> machine blindly.
>
> Yes, true.
>
> The reserve_ebda_region() has probably been like that for a while;
> do you understand why it would be a problem conflicting with the
> EFI memmap only now?
>
> My other two concerns remain as well:
>
>  2) Is what amounts to a change from calling reserve_bootmem()
>    to calling reserve_early(), at the end of reserve_ebda_region()
>    in the 32 bit case (now that it is merged with the 64 bit code)
>    understood to be a desired and correct change?
>
>  3) There has been quite a few patches restructuring this early
>    memory reservation code over the last week.  What is the
>    state of that work ... is it still "in progress" or is it
>    thought to be complete?

please check that commit that increase the range to 1M.
it seems at that time, andi and peter had different idea, because
increase 1M could waste K bytes memory.

also wonder if EFI is there, we still need to ebda?

YH

commit f6eb62b6924b99ec7da97fb6f554685a9ad6dce4
Author: Alexander van Heukelum <heukelum@mailshack.com>
Date:   Mon Feb 25 19:07:51 2008 +0100

    x86: reserve_early end-of-conventional-memory to 1MB, 64-bit

    Explicitly reserve_early the whole address range from the end of
    conventional memory as reported by the bios data area up to the
    1Mb mark. Regard the info retrieved from the BIOS data area with
    a bit of paranoia, though, because some biosses forget to register
    the EBDA correctly.

    Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

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

+/*
+ * The BIOS places the EBDA/XBDA at the top of conventional
+ * memory, and usually decreases the reported amount of
+ * conventional memory (int 0x12) too.
+ */
 static __init void reserve_ebda(void)
 {
-       unsigned ebda_addr, ebda_size;
+       unsigned int lowmem, ebda_addr;

-       /*
-        * there is a real-mode segmented pointer pointing to the
-        * 4K EBDA area at 0x40E
-        */
-       ebda_addr = *(unsigned short *)__va(EBDA_ADDR_POINTER);
+       /* end of low (conventional) memory */
+       lowmem = *(unsigned short *)__va(BIOS_LOWMEM_KILOBYTES);
+       lowmem <<= 10;
+
+       /* start of EBDA area */
+       ebda_addr = *(unsigned short *)__va(BIOS_EBDA_SEGMENT);
        ebda_addr <<= 4;

-       if (!ebda_addr)
-               return;
+       /* Fixup: bios puts an EBDA in the top 64K segment */
+       /* of conventional memory, but does not adjust lowmem. */
+       if ((lowmem - ebda_addr) <= 0x10000)
+               lowmem = ebda_addr;

-       ebda_size = *(unsigned short *)__va(ebda_addr);
+       /* Fixup: bios does not report an EBDA at all. */
+       /* Some old Dells seem to need 4k anyhow (bugzilla 2990) */
+       if ((ebda_addr == 0) && (lowmem >= 0x9f000))
+               lowmem = 0x9f000;

-       /* Round EBDA up to pages */
-       if (ebda_size == 0)
-               ebda_size = 1;
-       ebda_size <<= 10;
-       ebda_size = round_up(ebda_size + (ebda_addr & ~PAGE_MASK), PAGE_SIZE);
-       if (ebda_size > 64*1024)
-               ebda_size = 64*1024;
+       /* Paranoia: should never happen, but... */
+       if (lowmem >= 0x100000)
+               lowmem = 0xa0000;

-       reserve_early(ebda_addr, ebda_addr + ebda_size, "EBDA");
+       /* reserve all memory between lowmem and the 1MB mark */
+       reserve_early(lowmem, 0x100000, "BIOS reserved");
 }

 void __init x86_64_start_kernel(char * real_mode_data)

  reply	other threads:[~2008-06-12 20:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-12 10:06 Paul Jackson
2008-06-12 12:25 ` Yinghai Lu
2008-06-12 16:19   ` Paul Jackson
2008-06-12 17:05     ` Yinghai Lu
2008-06-12 20:10       ` Paul Jackson
2008-06-12 20:29         ` Yinghai Lu [this message]
2008-06-12 21:09           ` H. Peter Anvin
2008-06-12 21:52             ` Paul Jackson
2008-06-12 22:06               ` Yinghai Lu
2008-06-12 22:13                 ` Paul Jackson
2008-06-12 22:39               ` H. Peter Anvin
2008-06-13  0:59 ` Huang, Ying

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=86802c440806121329s54bb1e6dobaaa15c26e7dc81c@mail.gmail.com \
    --to=yhlu.kernel@gmail.com \
    --cc=andi@firstfloor.org \
    --cc=bwalle@suse.de \
    --cc=hannes@saeurebad.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pj@sgi.com \
    --cc=steiner@sgi.com \
    --cc=ying.huang@intel.com \
    /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

all inboxes | Powered by JetHome®