Re: [PATCH v4 02/10] memblock: Add variables for usable memory limitation
From: Mike Rapoport <rppt@kernel.org>
Date: 2021-07-20 05:41:41
Also in:
kexec, linux-arm-kernel, linux-devicetree, linux-renesas-soc, linux-riscv, lkml
Hi Geert, On Mon, Jul 19, 2021 at 08:59:03AM +0200, Geert Uytterhoeven wrote:
Hi Mike, On Sun, Jul 18, 2021 at 11:31 AM Mike Rapoport [off-list ref] wrote:quoted
On Wed, Jul 14, 2021 at 07:51:01AM -0600, Rob Herring wrote:quoted
On Wed, Jul 14, 2021 at 02:50:12PM +0200, Geert Uytterhoeven wrote:quoted
Add two global variables (cap_mem_addr and cap_mem_size) for storing a base address and size, describing a limited region in which memory may be considered available for use by the kernel. If enabled, memory outside of this range is not available for use. These variables can by filled by firmware-specific code, and used in calls to memblock_cap_memory_range() by architecture-specific code. An example user is the parser of the "linux,usable-memory-range" property in the DT "/chosen" node. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> --- This is similar to how the initial ramdisk (phys_initrd_{start,size}) and ELF core headers (elfcorehdr_{addr,size})) are handled. Does there exist a suitable place in the common memblock code to call "memblock_cap_memory_range(cap_mem_addr, cap_mem_size)", or does this have to be done in architecture-specific code?Can't you just call it from early_init_dt_scan_usablemem? If the property is present, you want to call it. If the property is not present, nothing happens.I will have a look...quoted
For memblock_cap_memory_range() to work properly it should be called after memory is detected and added to memblock with memblock_add[_node]() I'm not huge fan of adding more globals to memblock so if such ordering can be implemented on the DT side it would be great.Me neither ;-)quoted
I don't see a way to actually enforce this ordering, so maybe we'd want to add warning in memblock_cap_memory_range() if memblock.memory is empty."linux,usable-memory-range" is optional, and typically used only in crashdump kernels, so it would be a bad idea to add such a warning.
If I remember correctly, memblock_cap_memory_range() was added to support "linux,usable-memory-range" for crasdump kernels on arm64 and if it would be called before memory is registered we may silently corrupt the memory because the crash kernel will see all the memory as available. So while WARN() maybe too much a pr_warn() seems to me quite appropriate. -- Sincerely yours, Mike.