mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Yinghai Lu" <yhlu.kernel@gmail.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: More e820 unification?
Date: Mon, 2 Jun 2008 12:44:55 -0700	[thread overview]
Message-ID: <86802c440806021244u1c57f74dq9e581438f1365bbb@mail.gmail.com> (raw)
In-Reply-To: <484448F6.9000403@goop.org>

On Mon, Jun 2, 2008 at 12:24 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> Yinghai Lu wrote:
>>
>> [PATCH] x86: cleanup max_pfn_mapped usage - 32bit
>> may need you update xen pv to specify max_pfn_mapped early stage...
>
> Ah, yes, I saw your mail.  What exactly does that value mean?  What should I
> set it to?

arch/x86/kernel/head_32.S doesn't know max_low_pfn yet, so it could
initialize initial_pg_table to cover much less of the max_low_pfn.
it will need paging_init/pagetable_init/kernel_phys... to initialize
mapping to max_low_pfn.
but that is too late. it said need to use alloc_bootmem_low_pages to
get bootmem, other wise even you can get it > mem_mapped, you can not
use.
two memory region must be get via find_e820_area even before bootmem is there.
bootmap for bootmem, and pgdat for node0 in numa_32. so it need to
take the really mapped as parameter for that func, instead of
max_low_pfn.

We can get the real max_pfn_mapped in head_32.S when finish the
initial page table.

for XEN PV, when you are preparing the init pg table in domain
builder, you should keep the max_pfn_mapped ...

64 bit doesn't need that, because it call init_memory_mapping very
earlier..., and it cover all memory.

YH

      reply	other threads:[~2008-06-02 19:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-02 16:08 Jeremy Fitzhardinge
2008-06-02 18:14 ` Yinghai Lu
2008-06-02 19:24   ` Jeremy Fitzhardinge
2008-06-02 19:44     ` Yinghai Lu [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=86802c440806021244u1c57f74dq9e581438f1365bbb@mail.gmail.com \
    --to=yhlu.kernel@gmail.com \
    --cc=jeremy@goop.org \
    --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

all inboxes | Powered by JetHome®