From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Sourabh Jain <sourabhjain@linux.ibm.com>, linuxppc-dev@lists.ozlabs.org
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>,
Baoquan he <bhe@redhat.com>,
Hari Bathini <hbathini@linux.ibm.com>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Mahesh Salgaonkar <mahesh@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Shivang Upadhyay <shivangu@linux.ibm.com>
Subject: Re: [PATCH 1/4] powerpc/mmu: do MMU type discovery before crashkernel reservation
Date: Fri, 31 Oct 2025 10:23:55 +0530 [thread overview]
Message-ID: <87ms577jto.ritesh.list@gmail.com> (raw)
In-Reply-To: <20251027151338.819957-2-sourabhjain@linux.ibm.com>
Sourabh Jain <sourabhjain@linux.ibm.com> writes:
> Crashkernel reservation on high memory depends on the MMU type, so
> finalize the MMU type before calling arch_reserve_crashkernel().
>
> With the changes introduced here, early_radix_enabled() becomes usable
> and will be used in arch_reserve_crashkernel() in the upcoming patch.
>
> early_radix_enabled() depends on cur_cpu_spec->mmu_features to find
> out if the radix MMU is enabled. The radix MMU bit in mmu_features is
> discovered from the FDT and kernel configs. To make sure the MMU type is
> finalized before arch_reserve_crashkernel() is called, the function that
> scans the FDT and sets mmu_features, along with some bits from
> mmu_early_type_finalize(), has been moved above
> arch_reserve_crashkernel().
>
That is correct. mmu_features may as well get set from this path too...
early_init_dt_scan_cpus() ->
if (!dt_cpu_ftrs_in_use())
-> check_cpu_features(node, "ibm_pa_features",...
cur_cpu_spec->mmu_features |= fp->mmu_features
...which I guess is controlled using CONFIG_PPC_DT_CPU_FTRS.
so it make sense to move those dependent paths above.
Overall the patch looks good to me. Added few minor nits below.
> Cc: Baoquan he <bhe@redhat.com>
> Cc: Hari Bathini <hbathini@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---
> arch/powerpc/include/asm/book3s/64/mmu.h | 1 +
> arch/powerpc/include/asm/mmu.h | 1 +
> arch/powerpc/kernel/prom.c | 28 +++++++++++++-----------
> arch/powerpc/mm/init_64.c | 27 ++++++++++++++---------
> 4 files changed, 34 insertions(+), 23 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h
> index 48631365b48c..7a3b2ff02041 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
> @@ -208,6 +208,7 @@ extern int mmu_vmemmap_psize;
>
> /* MMU initialization */
> void mmu_early_init_devtree(void);
> +void mmu_early_type_finalize(void);
Minor nit:
Can we please rename this function to - mmu_early_init_vec5()?
Your naming isn't wrong, but it's just known that after vec5 call, we
finalize the mmu early init type.. So keeping this function name as
"mmu_early_init_vec5()" makes slightly more sense to me.
And then the order of function declarations can also be kept like below -
/* MMU initialization */
+void mmu_early_init_vec5(void);
void mmu_early_init_devtree(void);
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
+static inline void mmu_early_init_vec5(void) { }
static inline void mmu_early_init_devtree(void) { }
> void hash__early_init_devtree(void);
> void radix__early_init_devtree(void);
> #ifdef CONFIG_PPC_PKEY
> diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
> index 5f9c5d436e17..c40dc6349e55 100644
> --- a/arch/powerpc/include/asm/mmu.h
> +++ b/arch/powerpc/include/asm/mmu.h
> @@ -384,6 +384,7 @@ extern void early_init_mmu_secondary(void);
> extern void setup_initial_memory_limit(phys_addr_t first_memblock_base,
> phys_addr_t first_memblock_size);
> static inline void mmu_early_init_devtree(void) { }
> +static inline void mmu_early_type_finalize(void) { }
>
> static inline void pkey_early_init_devtree(void) {}
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 9ed9dde7d231..db1615f26075 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -853,6 +853,21 @@ void __init early_init_devtree(void *params)
> if (PHYSICAL_START > MEMORY_START)
> memblock_reserve(MEMORY_START, int_vector_size);
> reserve_kdump_trampoline();
> +
> + DBG("Scanning CPUs ...\n");
> +
> + dt_cpu_ftrs_scan();
> +
> + /* Retrieve CPU related informations from the flat tree
> + * (altivec support, boot CPU ID, ...)
> + */
> + of_scan_flat_dt(early_init_dt_scan_cpus, NULL);
> + if (boot_cpuid < 0) {
> + printk("Failed to identify boot CPU !\n");
> + BUG();
> + }
> +
> + mmu_early_type_finalize();
> #if defined(CONFIG_FA_DUMP) || defined(CONFIG_PRESERVE_FA_DUMP)
> /*
> * If we fail to reserve memory for firmware-assisted dump then
> @@ -884,19 +899,6 @@ void __init early_init_devtree(void *params)
> * FIXME .. and the initrd too? */
> move_device_tree();
>
> - DBG("Scanning CPUs ...\n");
> -
> - dt_cpu_ftrs_scan();
> -
> - /* Retrieve CPU related informations from the flat tree
> - * (altivec support, boot CPU ID, ...)
> - */
> - of_scan_flat_dt(early_init_dt_scan_cpus, NULL);
> - if (boot_cpuid < 0) {
> - printk("Failed to identify boot CPU !\n");
> - BUG();
> - }
> -
> save_fscr_to_task();
>
> #if defined(CONFIG_SMP) && defined(CONFIG_PPC64)
> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
> index b6f3ae03ca9e..cd52c1baa3bc 100644
> --- a/arch/powerpc/mm/init_64.c
> +++ b/arch/powerpc/mm/init_64.c
> @@ -622,8 +622,10 @@ static void __init early_init_memory_block_size(void)
> of_scan_flat_dt(probe_memory_block_size, &memory_block_size);
> }
>
> -void __init mmu_early_init_devtree(void)
Let's also add a comment here to be more explicit perhaps. Because it has
caused confusion in past.
/*
* mmu_early_init_vec5(): For non-hv mode (Pseries LPAR), whether we can do
* radix or not depend upon hypervisor vec5 values. This functions checks
* ibm,architecture-vec-5 and updates cur_cpu_spec->mmu_features bits
* accordingly.
* After this function returns, early_radix_enabled() can be used
* to check if radix is supported.
*/
> +
> +void __init mmu_early_type_finalize(void)
> {
> +
> bool hvmode = !!(mfmsr() & MSR_HV);
>
> /* Disable radix mode based on kernel command line. */
> @@ -634,6 +636,20 @@ void __init mmu_early_init_devtree(void)
> pr_warn("WARNING: Ignoring cmdline option disable_radix\n");
> }
>
> + /*
> + * Check /chosen/ibm,architecture-vec-5 if running as a guest.
> + * When running bare-metal, we can use radix if we like
> + * even though the ibm,architecture-vec-5 property created by
> + * skiboot doesn't have the necessary bits set.
> + */
> + if (!hvmode)
> + early_check_vec5();
> +}
-ritesh
next prev parent reply other threads:[~2025-10-31 5:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-27 15:13 [PATCH 0/4] powerpc/kdump: Support high crashkernel reservation Sourabh Jain
2025-10-27 15:13 ` [PATCH 1/4] powerpc/mmu: do MMU type discovery before " Sourabh Jain
2025-10-31 4:53 ` Ritesh Harjani [this message]
2025-10-27 15:13 ` [PATCH 2/4] powerpc: move to 64-bit RTAS Sourabh Jain
2025-10-29 12:52 ` Sourabh Jain
2025-10-27 15:13 ` [PATCH 3/4] powerpc/kdump: consider high crashkernel memory if enabled Sourabh Jain
2025-10-27 15:13 ` [PATCH 4/4] powerpc/kdump: add support for high crashkernel reservation Sourabh Jain
2025-10-28 6:23 ` [PATCH 0/4] powerpc/kdump: Support " Baoquan he
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ms577jto.ritesh.list@gmail.com \
--to=ritesh.list@gmail.com \
--cc=bhe@redhat.com \
--cc=hbathini@linux.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mahesh@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=shivangu@linux.ibm.com \
--cc=sourabhjain@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.