Re: [PATCH v15 09/10] of: fdt: Add memory for devices by DT property "linux,usable-memory-range"

2021-10-20 Thread Leizhen (ThunderTown)



On 2021/10/20 22:19, Rob Herring wrote:
> On Wed, Oct 20, 2021 at 10:03:16AM +0800, Zhen Lei wrote:
>> From: Chen Zhou 
>>
>> When reserving crashkernel in high memory, some low memory is reserved
>> for crash dump kernel devices and never mapped by the first kernel.
>> This memory range is advertised to crash dump kernel via DT property
>> under /chosen,
>> linux,usable-memory-range = 
>>
>> We reused the DT property linux,usable-memory-range and made the low
>> memory region as the second range "BASE2 SIZE2", which keeps compatibility
>> with existing user-space and older kdump kernels.
>>
>> Crash dump kernel reads this property at boot time and call memblock_add()
>> to add the low memory region after memblock_cap_memory_range() has been
>> called.
>>
>> Signed-off-by: Chen Zhou 
>> Signed-off-by: Zhen Lei 
>> ---
>>  drivers/of/fdt.c | 47 ---
>>  1 file changed, 36 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 4546572af24bbf1..cf59c847b2c28a5 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -969,8 +969,16 @@ static void __init 
>> early_init_dt_check_for_elfcorehdr(unsigned long node)
>>   elfcorehdr_addr, elfcorehdr_size);
>>  }
>>  
>> -static phys_addr_t cap_mem_addr;
>> -static phys_addr_t cap_mem_size;
>> +/*
>> + * The main usage of linux,usable-memory-range is for crash dump kernel.
>> + * Originally, the number of usable-memory regions is one. Now there may
>> + * be two regions, low region and high region.
>> + * To make compatibility with existing user-space and older kdump, the low
>> + * region is always the last range of linux,usable-memory-range if exist.
>> + */
>> +#define MAX_USABLE_RANGES   2
>> +
>> +static struct memblock_region cap_mem_regions[MAX_USABLE_RANGES];
>>  
>>  /**
>>   * early_init_dt_check_for_usable_mem_range - Decode usable memory range
>> @@ -979,20 +987,30 @@ static phys_addr_t cap_mem_size;
>>   */
>>  static void __init early_init_dt_check_for_usable_mem_range(unsigned long 
>> node)
>>  {
>> -const __be32 *prop;
>> -int len;
>> +const __be32 *prop, *endp;
>> +int len, nr = 0;
>> +struct memblock_region *rgn = &cap_mem_regions[0];
>>  
>>  pr_debug("Looking for usable-memory-range property... ");
>>  
>>  prop = of_get_flat_dt_prop(node, "linux,usable-memory-range", &len);
>> -if (!prop || (len < (dt_root_addr_cells + dt_root_size_cells)))
>> +if (!prop)
>>  return;
>>  
>> -cap_mem_addr = dt_mem_next_cell(dt_root_addr_cells, &prop);
>> -cap_mem_size = dt_mem_next_cell(dt_root_size_cells, &prop);
>> +endp = prop + (len / sizeof(__be32));
>> +while ((endp - prop) >= (dt_root_addr_cells + dt_root_size_cells)) {
>> +rgn->base = dt_mem_next_cell(dt_root_addr_cells, &prop);
>> +rgn->size = dt_mem_next_cell(dt_root_size_cells, &prop);
>> +
>> +pr_debug("cap_mem_regions[%d]: base=%pa, size=%pa\n",
>> + nr, &rgn->base, &rgn->size);
>> +
>> +if (++nr >= MAX_USABLE_RANGES)
>> +break;
>> +
>> +rgn++;
>> +}
>>  
>> -pr_debug("cap_mem_start=%pa cap_mem_size=%pa\n", &cap_mem_addr,
>> - &cap_mem_size);
>>  }
>>  
>>  #ifdef CONFIG_SERIAL_EARLYCON
>> @@ -1265,7 +1283,8 @@ bool __init early_init_dt_verify(void *params)
>>  
>>  void __init early_init_dt_scan_nodes(void)
>>  {
>> -int rc = 0;
>> +int i, rc = 0;
>> +struct memblock_region *rgn = &cap_mem_regions[0];
>>  
>>  /* Initialize {size,address}-cells info */
>>  of_scan_flat_dt(early_init_dt_scan_root, NULL);
>> @@ -1279,7 +1298,13 @@ void __init early_init_dt_scan_nodes(void)
>>  of_scan_flat_dt(early_init_dt_scan_memory, NULL);
>>  
>>  /* Handle linux,usable-memory-range property */
>> -memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
>> +memblock_cap_memory_range(rgn->base, rgn->size);
>> +for (i = 1; i < MAX_USABLE_RANGES; i++) {
>> +rgn++;
> 
> Just use rgn[i].

OK.

> 
>> +
>> +if (rgn->size)
> 
> This check can be in the 'for' conditions check.

Yes, this node is added by kexec tool, it is impossible that
the first range is zero and the second range is not zero.

> 
>> +memblock_add(rgn->base, rgn->size);
>> +}
> 
> 
> There's not really any point in doing all this in 2 steps. I'm 
> assuming this needs to be handled after scanning the memory nodes, so 
> can you refactor this moving early_init_dt_check_for_usable_mem_range 
> out of early_init_dt_scan_chosen() and call it here. You'll have to get 
> the offset for /chosen twice or save the offset.

This's a good suggestion. I'll refactor it. Thanks.

Zhen Lei

> 
> Rob
> .
> 

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


Re: [PATCH v15 09/10] of: fdt: Add memory for devices by DT property "linux,usable-memory-range"

2021-10-20 Thread Rob Herring
On Wed, Oct 20, 2021 at 10:03:16AM +0800, Zhen Lei wrote:
> From: Chen Zhou 
> 
> When reserving crashkernel in high memory, some low memory is reserved
> for crash dump kernel devices and never mapped by the first kernel.
> This memory range is advertised to crash dump kernel via DT property
> under /chosen,
> linux,usable-memory-range = 
> 
> We reused the DT property linux,usable-memory-range and made the low
> memory region as the second range "BASE2 SIZE2", which keeps compatibility
> with existing user-space and older kdump kernels.
> 
> Crash dump kernel reads this property at boot time and call memblock_add()
> to add the low memory region after memblock_cap_memory_range() has been
> called.
> 
> Signed-off-by: Chen Zhou 
> Signed-off-by: Zhen Lei 
> ---
>  drivers/of/fdt.c | 47 ---
>  1 file changed, 36 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 4546572af24bbf1..cf59c847b2c28a5 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -969,8 +969,16 @@ static void __init 
> early_init_dt_check_for_elfcorehdr(unsigned long node)
>elfcorehdr_addr, elfcorehdr_size);
>  }
>  
> -static phys_addr_t cap_mem_addr;
> -static phys_addr_t cap_mem_size;
> +/*
> + * The main usage of linux,usable-memory-range is for crash dump kernel.
> + * Originally, the number of usable-memory regions is one. Now there may
> + * be two regions, low region and high region.
> + * To make compatibility with existing user-space and older kdump, the low
> + * region is always the last range of linux,usable-memory-range if exist.
> + */
> +#define MAX_USABLE_RANGES2
> +
> +static struct memblock_region cap_mem_regions[MAX_USABLE_RANGES];
>  
>  /**
>   * early_init_dt_check_for_usable_mem_range - Decode usable memory range
> @@ -979,20 +987,30 @@ static phys_addr_t cap_mem_size;
>   */
>  static void __init early_init_dt_check_for_usable_mem_range(unsigned long 
> node)
>  {
> - const __be32 *prop;
> - int len;
> + const __be32 *prop, *endp;
> + int len, nr = 0;
> + struct memblock_region *rgn = &cap_mem_regions[0];
>  
>   pr_debug("Looking for usable-memory-range property... ");
>  
>   prop = of_get_flat_dt_prop(node, "linux,usable-memory-range", &len);
> - if (!prop || (len < (dt_root_addr_cells + dt_root_size_cells)))
> + if (!prop)
>   return;
>  
> - cap_mem_addr = dt_mem_next_cell(dt_root_addr_cells, &prop);
> - cap_mem_size = dt_mem_next_cell(dt_root_size_cells, &prop);
> + endp = prop + (len / sizeof(__be32));
> + while ((endp - prop) >= (dt_root_addr_cells + dt_root_size_cells)) {
> + rgn->base = dt_mem_next_cell(dt_root_addr_cells, &prop);
> + rgn->size = dt_mem_next_cell(dt_root_size_cells, &prop);
> +
> + pr_debug("cap_mem_regions[%d]: base=%pa, size=%pa\n",
> +  nr, &rgn->base, &rgn->size);
> +
> + if (++nr >= MAX_USABLE_RANGES)
> + break;
> +
> + rgn++;
> + }
>  
> - pr_debug("cap_mem_start=%pa cap_mem_size=%pa\n", &cap_mem_addr,
> -  &cap_mem_size);
>  }
>  
>  #ifdef CONFIG_SERIAL_EARLYCON
> @@ -1265,7 +1283,8 @@ bool __init early_init_dt_verify(void *params)
>  
>  void __init early_init_dt_scan_nodes(void)
>  {
> - int rc = 0;
> + int i, rc = 0;
> + struct memblock_region *rgn = &cap_mem_regions[0];
>  
>   /* Initialize {size,address}-cells info */
>   of_scan_flat_dt(early_init_dt_scan_root, NULL);
> @@ -1279,7 +1298,13 @@ void __init early_init_dt_scan_nodes(void)
>   of_scan_flat_dt(early_init_dt_scan_memory, NULL);
>  
>   /* Handle linux,usable-memory-range property */
> - memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
> + memblock_cap_memory_range(rgn->base, rgn->size);
> + for (i = 1; i < MAX_USABLE_RANGES; i++) {
> + rgn++;

Just use rgn[i].

> +
> + if (rgn->size)

This check can be in the 'for' conditions check.

> + memblock_add(rgn->base, rgn->size);
> + }


There's not really any point in doing all this in 2 steps. I'm 
assuming this needs to be handled after scanning the memory nodes, so 
can you refactor this moving early_init_dt_check_for_usable_mem_range 
out of early_init_dt_scan_chosen() and call it here. You'll have to get 
the offset for /chosen twice or save the offset.

Rob

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


[ANNOUNCE] kexec-tools v2.0.23 preparation

2021-10-20 Thread Simon Horman
Hi all,

I am planning to release kexec-tools v2.0.23 in the next two weeks
to roughly coincide with the release of the v5.15 kernel.

I would like to ask interested parties to send any patches they would like
included in v2.0.23 within one week so they can be considered for inclusion
in an rc release.

For reference the patches queued up since v2.0.22 are as follows.

Thanks to everyone who has contributed to kexec-tools!

5f8d632 arm: kdump: Add DT properties to crash dump kernel's DTB
bb1c95c kexec-tools: multiboot2: Correct BASIC_MEMINFO memory units
a4d49e8 Add some necessary free() calls
bcee4f2 Add some necessary fclose() calls
84ef6cb ppc64: Fix memory leak problem in zImage_ppc64_load()
35dec3d i386: Remove unused local variable in get_kernel_page_offset()
dbc151e multiboot2: Accept x86-64 images
e388195 multiboot2: Avoid first 0x500 bytes
1d02758 multiboot2: Use rel_min and rel_max for buffer destinations
4f8d667 multiboot2: Correct MBI size calculation
bfaebfb x86: Consolidate elf_x86_probe routines
091f9e9 Refer FDT tokens with symbolic names
61b8c79 arm64/crashdump-arm64: deduce the paddr of _text
5e7ce27 kexec-tools: Remove duplicate definition of ramdisk
a2ba3cd kexec-tools 2.0.21.git

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


Re: [PATCH] crash_dump: fix boolreturn.cocci warning

2021-10-20 Thread Simon Horman
On Wed, Oct 20, 2021 at 08:39:05AM +, cgel@gmail.com wrote:
> From: Changcheng Deng 
> 
> ./include/linux/crash_dump.h: 119: 50-51: WARNING: return of 0/1 in
> function 'is_kdump_kernel' with return type bool
> 
> Return statements in functions returning bool should use true/false
> instead of 1/0.
> 
> Reported-by: Zeal Robot 
> Signed-off-by: Changcheng Deng 

Reviewed-by: Simon Horman 

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


Re: [PATCH v2] arm: kdump: Add DT properties to crash dump kernel's DTB

2021-10-20 Thread Simon Horman
On Tue, Oct 05, 2021 at 02:40:32PM +0200, Geert Uytterhoeven wrote:
> Pass the following properties to the crash dump kernel, to provide a
> modern DT interface between kexec and the crash dump kernel:
> 
>   - linux,elfcorehdr: ELF core header segment, similar to the
> "elfcorehdr=" kernel parameter.
>   - linux,usable-memory-range: Usable memory reserved for the crash dump
> kernel.
> This makes the memory reservation explicit, so Linux no longer needs
> to mask the program counter, and rely on the "mem=" kernel parameter
> to obtain the start and size of usable memory.
> 
> For backwards compatibility, the "elfcorehdr=" and "mem=" kernel
> parameters are still appended to the kernel command line.
> 
> Loosely based on the ARM64 version by Akashi Takahiro.
> 
> Signed-off-by: Geert Uytterhoeven 

Thanks Geert, applied.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


Re: [PATCH] kexec-tools: multiboot2: Correct BASIC_MEMINFO memory units

2021-10-20 Thread Simon Horman
On Tue, Oct 05, 2021 at 11:13:45AM +0200, dinhngoc...@irit.fr wrote:
> > Thanks,
> > 
> > I'm curious to know how the current code could have worked.
> > Do we have some testing to verify this change?
> 
> Hi,
> 
> The current code is not actually used very often when loading Xen (which is
> one of the few things that actually support Multiboot2), as Xen uses the
> EBDA instead of the MB2 memory information on the MB2 boot path.
> However this blows up on EFI systems without CSM (as EBDA is no longer
> available).
> 
> I tested the loading of KVM->Xen and Xen->Xen with this patch and a patched
> version of Xen that trusts the MB2 information, on a laptop and a server.
> 
> The Multiboot2 documentation at
> https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html#Basic-mem
> ory-information also supports the change.

Thanks, and sorry for the delay.

Applied.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


[PATCH v2] crash_dump: remove duplicate include in crash_dump.h

2021-10-20 Thread cgel . zte
From: Ye Guojin 

In crash_dump.h, header file  is included twice. This
duplication was introduced in commit 65fddcfca8ad("mm: reorder includes
after introduction of linux/pgtable.h") where the order of the header
files is adjusted, while the old one was not removed.

Clean it up here.

Reported-by: Zeal Robot 
Acked-by: Baoquan He 
Signed-off-by: Ye Guojin 
---
v2:
- update the commit log
---
 include/linux/crash_dump.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index 0c547d866f1e..b7b255b23b99 100644
--- a/include/linux/crash_dump.h
+++ b/include/linux/crash_dump.h
@@ -8,8 +8,6 @@
 #include 
 #include 

-#include  /* for pgprot_t */
-
 /* For IS_ENABLED(CONFIG_CRASH_DUMP) */
 #define ELFCORE_ADDR_MAX   (-1ULL)
 #define ELFCORE_ADDR_ERR   (-2ULL)
-- 
2.25.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


[PATCH] crash_dump: fix boolreturn.cocci warning

2021-10-20 Thread cgel . zte
From: Changcheng Deng 

./include/linux/crash_dump.h: 119: 50-51: WARNING: return of 0/1 in
function 'is_kdump_kernel' with return type bool

Return statements in functions returning bool should use true/false
instead of 1/0.

Reported-by: Zeal Robot 
Signed-off-by: Changcheng Deng 
---
 include/linux/crash_dump.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index 0c547d866f1e..979c26176c1d 100644
--- a/include/linux/crash_dump.h
+++ b/include/linux/crash_dump.h
@@ -116,7 +116,7 @@ extern void register_vmcore_cb(struct vmcore_cb *cb);
 extern void unregister_vmcore_cb(struct vmcore_cb *cb);
 
 #else /* !CONFIG_CRASH_DUMP */
-static inline bool is_kdump_kernel(void) { return 0; }
+static inline bool is_kdump_kernel(void) { return false; }
 #endif /* CONFIG_CRASH_DUMP */
 
 /* Device Dump information to be filled by drivers */
-- 
2.25.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec