On 12/11/2012 03:53 PM, Yinghai Lu wrote: > On Tue, Dec 11, 2012 at 9:38 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >> On 12/11/2012 09:15 AM, Yinghai Lu wrote: >>> >>> >>> No, that is not right place. initrd could be loaded anywhere like way >>> high by bootloader. >>> >> >> Only *after* your changes... the current protocol doesn't allow that. > > before for-x86-boot change, > > bootloader put ramdisk just under 2g... > > [ 0.000000] memblock_reserve: [0x7d9dc000-0x7fffefff] RAMDISK > > and arch/x86/kernel/head_64.S only set ident mapping for [0,1g) > > so before init_memory_mapping, we need to use early_ioremap to access > ramdisk area. > > also even after init_memory_mapping, we still need use early_ioremap to access > it because user could use memmap to skip it. > > PS: this problem have nothing to do with mapping that is set by bootloader. > arch/x86/kernel/head_64.c will have it own mapping, and only cover [0,1g). > 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. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|