LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Alexander van Heukelum" <heukelum@fastmail.fm>
To: "Ingo Molnar" <mingo@elte.hu>
Cc: "Andi Kleen" <ak@suse.de>, "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: Sun, 24 Feb 2008 21:53:50 +0100	[thread overview]
Message-ID: <1203886430.22409.1238738169@webmail.messagingengine.com> (raw)
In-Reply-To: <20080224194121.GA26451@elte.hu>

On Sun, 24 Feb 2008 20:41:21 +0100, "Ingo Molnar" <mingo@elte.hu> said:
> 
> * Alexander van Heukelum <heukelum@mailshack.com> wrote:
> 
> > Hi Andi,
> > 
> > My eyes fell on the following table in the boot messages:
> > 
> > early res: 0 [0-fff] BIOS data page
> > early res: 1 [6000-7fff] SMP_TRAMPOLINE
> > early res: 2 [200000-374557] TEXT DATA BSS
> > early res: 3 [9fc00-a0bff] EBDA
> > early res: 4 [8000-afff] PGTABLE
> > 
> > The memory reserved for the EBDA overflows into the area normally 
> > reserved for the VGA adaptor. It seems that you wanted to force the 
> > allocation to cover whole pages, like:
> 
> well, that's what your EBDA descriptor says - it's set to 9fc00 which is 
> 512 bytes below the VGA range.

It's 1024 bytes below, but yes, the EBDA starts there. Then the first
two
bytes of the EBDA contain the value 0x0001, which means that its size is
1kb, so the BIOS is correct.

> This behavior didnt really change over 
> v2.6.24 (which reserved 'into' the VGA range too), it's just that in 
> v2.6.25 we also print out these early reservations.

Correct. I thought it was new code, but looking more closely, the
behaviour
has indeed not changed recently (note to self: git log -p somefile.c
does
not indicate in any way that code was moved from some other place.)

> Can you see any 
> regression? There should be no harm from overlapping into the VGA range 
> - these "reservations" only make RAM unavailable for normal allocations.

No regressions, it's just cosmetic.

> your patch on the other hand rounds the EBDA area down which could in 
> theory be unsafe on other boxes (where there could be real RAM above the 
> EBDA area): the safest approach is to round the beginning of it down, 
> the end of it up (to page boundary).

Not really: ebda_addr is just a local variable. If the system needs to
find the start of the EBDA, it will just have to look at the 16 bit
value
at address 0x40E again.

> Your patch _should_ be OK, but in 
> practice it doesnt hurt to reserve a bit more around the edges than to 
> accidentally give a page to the OS that the BIOS might rely upon.

The patch is exactly trying to do that. The code that was there seemed
to
imply that the author wanted to allocate whole pages, in such a way that
the allocation contained the whole EBDA. I think that is what it does
after this patch.

Greetings,
    Alexander
-- 
  Alexander van Heukelum
  heukelum@fastmail.fm

-- 
http://www.fastmail.fm - And now for something completely different…


  reply	other threads:[~2008-02-24 20:54 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-24 17:46 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 [this message]
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     ` [PATCH] Fix alignment of early reservation for EBDA Andi Kleen

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=1203886430.22409.1238738169@webmail.messagingengine.com \
    --to=heukelum@fastmail.fm \
    --cc=ak@suse.de \
    --cc=heukelum@mailshack.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --subject='Re: [PATCH] Fix alignment of early reservation for EBDA' \
    /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

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).