On Tue, Nov 13, 2012 at 12:01 PM, H. Peter Anvin <h...@zytor.com> wrote: > On 11/13/2012 11:59 AM, Yinghai Lu wrote: >>> >>> The changes to init_mem_mapping are a bit iffy but they aren't too >>> unreasonable. >>> Overall the patch is OK even though I would certainly appreciate more >>> comments and better variable names (real_end?), see below. >> >> real_end is not good? >> >> xen put big reserved range between real_end and end. >> >> that real_end is some kind of end of real usable areas. >> >> so change to real_usable_end or usable_end? >> > > A description of a variable that includes the words "some kind of" > clearly indicates major confusion. We need to know what the semantics > are, here.
originally, we map range in this sequence: 1. map [0, 1M], 2. map 2M near max_pfn. and end is max_pfn<<PAGE_SHIFT 3. use new mapped area, to map low range. 4. change step size if more ram get mapped. 5. goto 3, until reach 1M. now for xen, there is big chunk range under max_pfn and they are reserved in memblock.reserved. so even we map them, we still can not use them for page table. so 2 become: 2a. find real_end under max_pfn that we can use it for page table 2b, map [real_end - 2M, real_end) and need to add 6. map [real_end, max_pfn<<PAGE_SHIFT) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
