From: Ian Campbell <ijc@hellion.org.uk>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: huang ying <huang.ying.caritas@gmail.com>,
"Huang, Ying" <ying.huang@intel.com>,
akpm@linux-foundation.org, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org,
Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [PATCH -mm 1/3] i386 boot: replace boot_ioremap with enhanced bt_ioremap - enhance bt_ioremap
Date: Fri, 18 Jan 2008 15:54:25 +0000 [thread overview]
Message-ID: <1200671665.9891.45.camel@localhost.localdomain> (raw)
In-Reply-To: <4790BD90.9060303@zytor.com>
On Fri, 2008-01-18 at 09:54 -0500, H. Peter Anvin wrote:
> huang ying wrote:
> >
> > If CONFIG_X86_PAE is defined, the set_pte, clear_pte etc will operate
> > 3-level page tables, while on i386, the early page table is always
> > 2-level, so set_pte, clear_pte etc functions can not be used here. The
> > boot_ioremap use a trick to deal with this problem. The CONFIG_X86_PAE
> > is undefined in arch/x86/mm/boot_ioremap_32.c unconditionally, so the
> > 2-level page table handling function is always used.
> >
> > Is the method used by boot_ioremap better for Xen?
> >
>
> Eric Biederman had a patchset that makes a PAE kernel use PAE page
> tables from the start. That is really The Right Thing[TM].
That's much saner than dup'ing up the early ioremap stuff to support
both PAE and non-PAE at runtime, which is about the only idea I've got
for fixing this right now...
I think I'll just back out the early_ioremap patches locally for now and
wait for Eric's patches which should cause the fix for this issue to
just fall out in the wash.
Ian.
--
Ian Campbell
Current Noise: Mistress - Mistress
Everything should be built top-down, except this time.
next prev parent reply other threads:[~2008-01-18 15:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-15 5:45 [PATCH -mm 1/3] i386 boot: replace boot_ioremap with enhanced bt_ioremap - enhance bt_ioremap Huang, Ying
2008-01-18 8:48 ` Ian Campbell
2008-01-18 12:50 ` Ingo Molnar
2008-01-18 14:54 ` huang ying
2008-01-18 14:54 ` H. Peter Anvin
2008-01-18 15:54 ` Ian Campbell [this message]
2008-01-18 16:22 ` Ingo Molnar
2008-01-18 17:27 ` Jeremy Fitzhardinge
2008-01-18 17:45 ` Ian Campbell
2008-01-18 15:23 ` Ian Campbell
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=1200671665.9891.45.camel@localhost.localdomain \
--to=ijc@hellion.org.uk \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=huang.ying.caritas@gmail.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.