On 12/11/2012 04:27 PM, Yinghai Lu wrote: > On Tue, Dec 11, 2012 at 3:57 PM, H. Peter Anvin wrote: >> Well, we could invoke it on the bootloader page tables, but as you say >> it may not be a good idea... depending on how much memory we may be >> talking about. One solution -- which I have to admit is starting to >> sound really good -- is to set up a #PF handler which cycles through a >> set of page tables and creates a "virtual identity map"... it does have >> the advantage of making the entire physical address space available >> without any additional funnies. > > so that #PF handler will work before > arch/x86/kernel/setup.c::setup_arch/early_trap_init > > early_strap_intit will install another handler there for #PF > > for 64bit, moving early_ioremap_init ahead is very simple, like attach patch > > but for 32 bit looks like it is not that easy. > Here is an incomplete patch for illustration purposes only what I mean with an early-mapping #PF handler. This creates a set of transient page tables on demand which allows us to access memory as if it was all mapped, but using only O(1) storage. The replacement policy is trivial: if we run out, we start over from scratch. The "identity page tables" used during the transition to high virtual addresses are kind of magic; there is a bunch of extra aliases created, but the way it is done guarantees that the range we actually cares about is mapped correctly. The aliases don't matter and get scrubbed shortly thereafter anyway. This should, obviously, be used on native only -- in particular Xen should instead rely on the initial page tables provided by the domain builder, which should map all physical memory. Once the proper memory-map-aware page tables are built, we should turn this off by swapping to the newly built real init_level4_pgt instead. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.