Skip to content
  • Yinghai Lu's avatar
    x86: Use memblock to replace early_res · 72d7c3b3
    Yinghai Lu authored
    
    
    1. replace find_e820_area with memblock_find_in_range
    2. replace reserve_early with memblock_x86_reserve_range
    3. replace free_early with memblock_x86_free_range.
    4. NO_BOOTMEM will switch to use memblock too.
    5. use _e820, _early wrap in the patch, in following patch, will
       replace them all
    6. because memblock_x86_free_range support partial free, we can remove some special care
    7. Need to make sure that memblock_find_in_range() is called after memblock_x86_fill()
       so adjust some calling later in setup.c::setup_arch()
       -- corruption_check and mptable_update
    
    -v2: Move reserve_brk() early
        Before fill_memblock_area, to avoid overlap between brk and memblock_find_in_range()
        that could happen We have more then 128 RAM entry in E820 tables, and
        memblock_x86_fill() could use memblock_find_in_range() to find a new place for
        memblock.memory.region array.
        and We don't need to use extend_brk() after fill_memblock_area()
        So move reserve_brk() early before fill_memblock_area().
    -v3: Move find_smp_config early
        To make sure memblock_find_in_range not find wrong place, if BIOS doesn't put mptable
        in right place.
    -v4: Treat RESERVED_KERN as RAM in memblock.memory. and they are already in
        memblock.reserved already..
        use __NOT_KEEP_MEMBLOCK to make sure memblock related code could be freed later.
    -v5: Generic version __memblock_find_in_range() is going from high to low, and for 32bit
        active_region for 32bit does include high pages
        need to replace the limit with memblock.default_alloc_limit, aka get_max_mapped()
    -v6: Use current_limit instead
    -v7: check with MEMBLOCK_ERROR instead of -1ULL or -1L
    -v8: Set memblock_can_resize early to handle EFI with more RAM entries
    -v9: update after kmemleak changes in mainline
    
    Suggested-by: default avatarDavid S. Miller <davem@davemloft.net>
    Suggested-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    Suggested-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
    Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
    72d7c3b3