| Message ID | 20210531122959.23499-1-rppt@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | consolidate "System RAM" resources setup | expand |
On Mon, May 31, 2021 at 03:29:54PM +0300, Mike Rapoport wrote: > * arm has "System RAM (boot alias)" that do not seem useful for any other > architecture This is VERY important for kexec and must _not_ be removed, since you will be causing a userspace regression by doing so.
On Tue, Jun 01, 2021 at 02:44:29PM +0100, Russell King (Oracle) wrote: > On Mon, May 31, 2021 at 03:29:54PM +0300, Mike Rapoport wrote: > > * arm has "System RAM (boot alias)" that do not seem useful for any other > > architecture > > This is VERY important for kexec and must _not_ be removed, since you > will be causing a userspace regression by doing so. I didn't remove these. I'll update the changelog and the cover letter to make it clear.
From: Mike Rapoport <rppt@linux.ibm.com> Hi, There are several architectures that use very similar code for setup if "System RAM" resources under iomem_resource tree and requesting memory resources corresponding to the kernel code, data etc. The flow for resources setup iterates over memory regions registered in memblock, adds a resource for each region as "System RAM" and than registers the areas used by the kernel image and, optionally, the crash kernel area, as children of the "System RAM" resources. The notable differences are: * arm/arm64 use [__text, __init_begin] range for kernel code resource and [_sdata, _end] range for kernel data, while most other architectures use more fine grained ranges. * arm has "System RAM (boot alias)" that do not seem useful for any other architecture * arm64 has special treatment for NOMAP areas and all the areas reserved in memblock * s390 has crashk_res in parallel with the "System RAM" resource, but it seems it was required some time ago but no longer actually needed. These patches use s390 implementation of the resource setup as the basis and then switch MIPS, arm and arm64 to use it with modifications required to support each architecture. The generic code loops over all memblock.memory regions, adds the NOMAP regions as "reserved" iomem resources and "normal" regions as "System RAM" iomem resrouces, reserves the areas occupied by the kernel code, rodata, data and bss, if there is crash kernel resource it is also reserved. In addition, if an architectures selects CONFIG_ARCH_WANT_RESERVE_MEMBLOCK_RESERVED_REGIONS (bad name, but I could not find a better one) the memblock.reserved regions are registered as "reserved" resources in iomem_resource. It would be also possible to convert other architectures (e.g, RISC-V and sh) to use the common infrastructure. Mike Rapoport (5): s390: make crashk_res resource a child of "System RAM" memblock: introduce generic memblock_setup_resources() arm: switch to generic memblock_setup_resources() MIPS: switch to generic memblock_setup_resources arm64: switch to generic memblock_setup_resources() arch/Kconfig | 7 ++ arch/arm/kernel/setup.c | 37 +---------- arch/arm64/Kconfig | 1 + arch/arm64/kernel/setup.c | 101 +---------------------------- arch/mips/kernel/setup.c | 78 ++-------------------- arch/s390/kernel/setup.c | 86 +------------------------ include/linux/memblock.h | 2 + mm/memblock.c | 132 ++++++++++++++++++++++++++++++++++++++ 8 files changed, 151 insertions(+), 293 deletions(-) base-commit: c4681547bcce777daf576925a966ffa824edd09d