| Message ID | 04c4d231fb03a3810d72a45c8a5bc2272c5975f3.1626266516.git.geert+renesas@glider.be (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Add generic support for kdump DT properties | expand |
On Wed, Jul 14, 2021 at 02:50:12PM +0200, Geert Uytterhoeven wrote: > 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. Rob
Hi, On Wed, Jul 14, 2021 at 07:51:01AM -0600, Rob Herring wrote: > On Wed, Jul 14, 2021 at 02:50:12PM +0200, Geert Uytterhoeven wrote: > > 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. 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. 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. > Rob
Hi Mike, On Sun, Jul 18, 2021 at 11:31 AM Mike Rapoport <rppt@kernel.org> wrote: > On Wed, Jul 14, 2021 at 07:51:01AM -0600, Rob Herring wrote: > > On Wed, Jul 14, 2021 at 02:50:12PM +0200, Geert Uytterhoeven wrote: > > > 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
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 <rppt@kernel.org> wrote: > > On Wed, Jul 14, 2021 at 07:51:01AM -0600, Rob Herring wrote: > > > On Wed, Jul 14, 2021 at 02:50:12PM +0200, Geert Uytterhoeven wrote: > > > > 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. 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.
Hi Mike, On Tue, Jul 20, 2021 at 7:41 AM Mike Rapoport <rppt@kernel.org> wrote: > On Mon, Jul 19, 2021 at 08:59:03AM +0200, Geert Uytterhoeven wrote: > > On Sun, Jul 18, 2021 at 11:31 AM Mike Rapoport <rppt@kernel.org> wrote: > > > On Wed, Jul 14, 2021 at 07:51:01AM -0600, Rob Herring wrote: > > > > On Wed, Jul 14, 2021 at 02:50:12PM +0200, Geert Uytterhoeven wrote: > > > > > 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. Sorry, I misread "if memblock.memory is empty" as "if capmem 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. Yes, makes perfect sense now. Gr{oetje,eeting}s, Geert
On Wed, Jul 14, 2021 at 3:51 PM Rob Herring <robh@kernel.org> wrote: > On Wed, Jul 14, 2021 at 02:50:12PM +0200, Geert Uytterhoeven wrote: > > 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. Seems to work fine when called from early_init_dt_scan_nodes(). Hence v5 will no longer need to touch memblock. Gr{oetje,eeting}s, Geert
diff --git a/include/linux/memblock.h b/include/linux/memblock.h index cbf46f56d1053b68..07e2474c4c3901e9 100644 --- a/include/linux/memblock.h +++ b/include/linux/memblock.h @@ -25,6 +25,12 @@ extern unsigned long max_pfn; */ extern unsigned long long max_possible_pfn; +/* + * limited region in which memory may be considered usable by the kernel + */ +extern phys_addr_t cap_mem_addr; +extern phys_addr_t cap_mem_size; + /** * enum memblock_flags - definition of memory region attributes * @MEMBLOCK_NONE: no special request diff --git a/mm/memblock.c b/mm/memblock.c index 0041ff62c584e7e1..66659f2b10ed40ff 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -101,6 +101,8 @@ unsigned long max_low_pfn; unsigned long min_low_pfn; unsigned long max_pfn; unsigned long long max_possible_pfn; +phys_addr_t cap_mem_addr; +phys_addr_t cap_mem_size; static struct memblock_region memblock_memory_init_regions[INIT_MEMBLOCK_REGIONS] __initdata_memblock; static struct memblock_region memblock_reserved_init_regions[INIT_MEMBLOCK_RESERVED_REGIONS] __initdata_memblock;
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? v4: - New. --- include/linux/memblock.h | 6 ++++++ mm/memblock.c | 2 ++ 2 files changed, 8 insertions(+)