Thread (21 messages) 21 messages, 5 authors, 2021-08-11

Re: [PATCH v4 02/10] memblock: Add variables for usable memory limitation

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2021-07-19 06:59:19
Also in: kexec, linux-arm-kernel, linux-devicetree, linux-renesas-soc, linux-riscv, lkml

Hi Mike,

On Sun, Jul 18, 2021 at 11:31 AM Mike Rapoport [off-list ref] wrote:
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...
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 ;-)
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.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help