Messages in this thread | | | Date | Mon, 2 Jun 2008 12:44:55 -0700 | From | "Yinghai Lu" <> | Subject | Re: More e820 unification? |
| |
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
| |