[PATCH 2/2] powerpc/fadump: fix additional param memory reservation for HASH MMU
Avnish Chouhan
avnish at linux.ibm.com
Fri Jan 24 01:24:33 AEDT 2025
On 2025-01-23 15:26, Hari Bathini wrote:
> On 20/01/25 11:05 pm, Sourabh Jain wrote:
>> Commit 683eab94da75bc ("powerpc/fadump: setup additional parameters
>> for
>> dump capture kernel") introduced the additional parameter feature in
>> fadump for HASH MMU with the understanding that GRUB does not use the
>> memory area between 640MB and 768MB for its operation.
>>
>> However, the patch ("powerpc: increase MIN RMA size for CAS
>> negotiation") changes the MIN RMA size to 768MB, allowing GRUB to use
>> memory up to 768MB. This makes the fadump reservation for the
>> additional
>> parameter feature for HASH MMU unreliable.
>>
>> To address this, adjust the memory range for the additional parameter
>> in
>> fadump for HASH MMU. This will ensure that GRUB does not overwrite the
>> memory reserved for fadump's additional parameter in HASH MMU.
>>
>
>> The new policy for the memory range for the additional parameter in
>> HASH
>> MMU is that the first memory block must be larger than the MIN_RMA
>> size,
>> as the bootloader can use memory up to the MIN_RMA size. The range
>> should be between MIN_RMA and the RMA size (ppc64_rma_size), and it
>> must
>> not overlap with the fadump reserved area.
>
> IIRC, even memory above MIN_RMA is used by the bootloader except for
> 640MB to 768MB (assuming RMA size is >768MB). So, how does this change
> guarantee that the bootloader is not using memory reserved for
> bootargs?
>
> Avnish, earlier, bootloader was using RUNTIME_MIN_SPACE (128MB)
> starting
> top-down at 768MB earlier. With MIN_RMA changed to 768MB, is bootloader
> still using the concept of RUNTIME_MIN_SPACE to set aside some memory
> for kernel to use. If yes, where exactly is it allocating this space
> now? Also, rtas instantiates top-down at 768MB. Would that not have
> a conflict with grub allocations without RUNTIME_MIN_SPACE at 768MB?
>
> - Hari
Hi Hari,
The RUNTIME_MIN_SPACE is the space left aside by Grub is within the
MIN_RMA size. Grub won't use memory beyond the MIN_RMA. With this
change, we haven't changed the RUNTIME_MIN_SPACE behavior. Grub will
still keep the 128 MB space in MIN_RMA for loading stock kernel and
initrd.
For your RTAS query, as it gets initiated just below the MIN_RMA. So it
will not have any impact with this RMA size change.
**
When MIN_RMA is 768MB, rtas will be instantiate at 0x000000002ec50000
(approximately at 748 MB).
**
Thank you!
Regards,
Avnish Chouhan
>
>>
>> Cc: Avnish Chouhan <avnish at linux.ibm.com>
>> Cc: Brian King <brking at linux.ibm.com>
>> Cc: Hari Bathini <hbathini at linux.ibm.com>
>> Cc: Madhavan Srinivasan <maddy at linux.ibm.com>
>> Cc: Michael Ellerman <mpe at ellerman.id.au>
>> Cc: Mahesh Salgaonkar <mahesh at linux.ibm.com>
>> Signed-off-by: Sourabh Jain <sourabhjain at linux.ibm.com>
>> ---
>> arch/powerpc/kernel/fadump.c | 21 +++++++++++----------
>> 1 file changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/fadump.c
>> b/arch/powerpc/kernel/fadump.c
>> index 4b371c738213..5831f3ec8561 100644
>> --- a/arch/powerpc/kernel/fadump.c
>> +++ b/arch/powerpc/kernel/fadump.c
>> @@ -33,6 +33,7 @@
>> #include <asm/fadump-internal.h>
>> #include <asm/setup.h>
>> #include <asm/interrupt.h>
>> +#include <asm/prom.h>
>> /*
>> * The CPU who acquired the lock to trigger the fadump crash should
>> @@ -1764,19 +1765,19 @@ void __init fadump_setup_param_area(void)
>> range_end = memblock_end_of_DRAM();
>> } else {
>> /*
>> - * Passing additional parameters is supported for hash MMU only
>> - * if the first memory block size is 768MB or higher.
>> + * Memory range for passing additional parameters for HASH MMU
>> + * must meet the following conditions:
>> + * 1. The first memory block size must be higher than the
>> + * minimum RMA (MIN_RMA) size. Bootloader can use memory
>> + * up to RMA size. So it should be avoided.
>> + * 2. The range should be between MIN_RMA and RMA size
>> (ppc64_rma_size)
>> + * 3. It must not overlap with the fadump reserved area.
>> */
>> - if (ppc64_rma_size < 0x30000000)
>> + if (ppc64_rma_size < MIN_RMA*1024*1024)
>> return;
>> - /*
>> - * 640 MB to 768 MB is not used by PFW/bootloader. So, try
>> reserving
>> - * memory for passing additional parameters in this range to avoid
>> - * being stomped on by PFW/bootloader.
>> - */
>> - range_start = 0x2A000000;
>> - range_end = range_start + 0x4000000;
>> + range_start = MIN_RMA * 1024 * 1024;
>> + range_end = min(ppc64_rma_size, fw_dump.boot_mem_top);
>> }
>> fw_dump.param_area = memblock_phys_alloc_range(COMMAND_LINE_SIZE,
More information about the Linuxppc-dev
mailing list