• Baoquan He's avatar
    arm64: kdump: simplify the reservation behaviour of crashkernel=,high · 6c4dcadd
    Baoquan He authored
    On arm64, reservation for 'crashkernel=xM,high' is taken by searching for
    suitable memory region top down. If the 'xM' of crashkernel high memory
    is reserved from high memory successfully, it will try to reserve
    crashkernel low memory later accoringly. Otherwise, it will try to search
    low memory area for the 'xM' suitable region. Please see the details in
    Documentation/admin-guide/kernel-parameters.txt.
    
    While we observed an unexpected case where a reserved region crosses the
    high and low meomry boundary. E.g on a system with 4G as low memory end,
    user added the kernel parameters like: 'crashkernel=512M,high', it could
    finally have [4G-126M, 4G+386M], [1G, 1G+128M] regions in running kernel.
    The crashkernel high region crossing low and high memory boudary will bring
    issues:
    
    1) For crashkernel=x,high, if getting crashkernel high region across
    low and high memory boundary, then user will see two memory regions in
    low memory, and one memory region in high memory. The two crashkernel
    low memory regions are confusing as shown in above example.
    
    2) If people explicityly specify "crashkernel=x,high crashkernel=y,low"
    and y <= 128M, when crashkernel high region crosses low and high memory
    boundary and the part of crashkernel high reservation below boundary is
    bigger than y, the expected crahskernel low reservation will be skipped.
    But the expected crashkernel high reservation is shrank and could not
    satisfy user space requirement.
    
    3) The crossing boundary behaviour of crahskernel high reservation is
    different than x86 arch. On x86_64, the low memory end is 4G fixedly,
    and the memory near 4G is reserved by system, e.g for mapping firmware,
    pci mapping, so the crashkernel reservation crossing boundary never happens.
    From distros point of view, this brings inconsistency and confusion. Users
    need to dig into x86 and arm64 system details to find out why.
    
    For kernel itself, the impact of issue 3) could be slight. While issue
    1) and 2) cause actual impact because it brings obscure semantics and
    behaviour to crashkernel=,high reservation.
    
    Here, for crashkernel=xM,high, search the high memory for the suitable
    region only in high memory. If failed, try reserving the suitable
    region only in low memory. Like this, the crashkernel high region will
    only exist in high memory, and crashkernel low region only exists in low
    memory. The reservation behaviour for crashkernel=,high is clearer and
    simpler.
    
    Note: RPi4 has different zone ranges than normal memory. Its DMA zone is
    0~1G, and DMA32 zone is 1G~4G if CONFIG_ZONE_DMA|DMA32 are enabled by
    default. The low memory end is 1G in order to validate all devices, high
    memory starts at 1G memory. However, for being consistent with normal
    arm64 system, its low memory end is still 1G, while reserving crashkernel
    high memory from 4G if crashkernel=size,high specified. This will remove
    confusion.
    
    With above change applied, summary of arm64 crashkernel reservation range:
    1)
    RPi4(zone DMA:0~1G; DMA32:1G~4G):
     crashkernel=size
      0~1G: low memory | 1G~top: high memory
    
     crashkernel=size,high
      0~1G: low memory | 4G~top: high memory
    
    2)
    Other normal system:
     crashkernel=size
     crashkernel=size,high
      0~4G: low memory | 4G~top: high memory
    
    3)
    Systems w/o zone DMA|DMA32
     crashkernel=size
     crashkernel=size,high
      0~top: low memory
    Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
    Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
    Reviewed-by: default avatarZhen Lei <thunder.leizhen@huawei.com>
    Link: https://lore.kernel.org/r/ZGIBSEoZ7VRVvP8H@MiWiFi-R3L-srvSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
    6c4dcadd
init.c 15.1 KB