[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47990BDC.4070008@zytor.com>
Date: Thu, 24 Jan 2008 14:06:20 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Ian Campbell <ijc@...lion.org.uk>
CC: Jeremy Fitzhardinge <jeremy@...p.org>, Ingo Molnar <mingo@...e.hu>,
Mika Penttilä <mika.penttila@...umbus.fi>,
linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH] x86: Construct 32 bit boot time page tables in native
format.
Ian Campbell wrote:
>
> I'm not sure how PSE comes to be used ever though -- an EFI only thing?
> Using the qemu monitor I could see a bunch of NX bits used when NX was
> available.
>
This is part of the trickiness with re-using the early pagetables
instead of rebuilding them from scratch - if PSE is available, we have
two options:
- either we build PSE page tables early (which means detecting PSE,
which means if there are any chip-specific CPUID workarounds they have
to be present in the early code), or
- when building the "complete" page tables, coalesce !PSE pagetables
into PSE entries where appropriate.
For PAT to work right, the first chunk probably should *not* be a PSE
page table, which complicates things further. (There is no TLB impact,
since a PSE page table at offset zero or that otherwise have an MTRR
conflict will be broken apart in hardware.) In the former case, it
means splitting it apart later; in the latter case it just means
excluding it from coalescing.
In other words, reusing the early page tables isn't all that
straightforward. It may easily be that it's better to build a new set
of page tables from scratch, however, it would *still* be beneficial to
have the early page tables be in the same format as the later one, since
it lets us use the fixmap area, and therefore {bt,early}_ioremap() much
sooner.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists