* [RESEND PATCH v2 1/3] fixup mmu_features immediately after getting cpu pa features.
2021-10-18 8:44 [RESEND PATCH v2 0/3] Update crashkernel offset to allow kernel to boot on large config LPARs Sourabh Jain
@ 2021-10-18 8:44 ` Sourabh Jain
2021-11-18 6:12 ` Sourabh Jain
2021-10-18 8:44 ` [RESEND PATCH v2 2/3] Remove 256MB limit restriction for boot cpu paca allocation Sourabh Jain
2021-10-18 8:44 ` [RESEND PATCH v2 3/3] powerpc: Set crashkernel offset to mid of RMA region Sourabh Jain
2 siblings, 1 reply; 5+ messages in thread
From: Sourabh Jain @ 2021-10-18 8:44 UTC (permalink / raw)
To: linuxppc-dev
Cc: Mahesh Salgaonkar, mahesh, Abdul haleem, aneesh.kumar, hbathini
From: Mahesh Salgaonkar <mahesh@linux.ibm.com>
On system with radix support available, early_radix_enabled() starts
returning true for a small window (until mmu_early_init_devtree() is
called) even when radix mode disabled on kernel command line. This causes
ppc64_bolted_size() to return ULONG_MAX in HPT mode instead of supported
segment size, during boot cpu paca allocation.
Withi kernel command line = "... disable_radix":
early_init_devtree: <- early_radix_enabled() = false
early_init_dt_scan_cpus: <- early_radix_enabled() = false
...
check_cpu_pa_features: <- early_radix_enabled() = false
... ^ <- early_radix_enabled() = TRUE
allocate_paca: | <- early_radix_enabled() = TRUE
... |
ppc64_bolted_size: | <- early_radix_enabled() = TRUE
if (early_radix_enabled())| <- early_radix_enabled() = TRUE
return ULONG_MAX; |
... |
... | <- early_radix_enabled() = TRUE
... | <- early_radix_enabled() = TRUE
mmu_early_init_devtree() V
... <- early_radix_enabled() = false
So far we have not seen any issue because allocate_paca() takes minimum of
ppc64_bolted_size and rma_size while allocating paca. However it is better
to close this window by fixing up the mmu features as early as possible.
This fixes early_radix_enabled() and ppc64_bolted_size() to return valid
values in radix disable mode. This patch will help subsequent patch to
depend on early_radix_enabled() check while detecting supported segment
size in HPT mode.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Reported-and-tested-by: Abdul haleem <abdhalee@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/book3s/64/mmu.h | 1 +
arch/powerpc/include/asm/mmu.h | 1 +
arch/powerpc/kernel/prom.c | 2 ++
arch/powerpc/mm/init_64.c | 5 ++++-
4 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h
index c02f42d1031e..d60be5051d60 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu.h
@@ -197,6 +197,7 @@ extern int mmu_vmemmap_psize;
extern int mmu_io_psize;
/* MMU initialization */
+void update_cpu_features(void);
void mmu_early_init_devtree(void);
void hash__early_init_devtree(void);
void radix__early_init_devtree(void);
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 8abe8e42e045..5eb494ea85d7 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -401,6 +401,7 @@ extern void early_init_mmu(void);
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 update_cpu_features(void) { }
static inline void mmu_early_init_devtree(void) { }
static inline void pkey_early_init_devtree(void) {}
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 2e67588f6f6e..889c909e4ed4 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -380,6 +380,8 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
check_cpu_pa_features(node);
}
+ /* Update cpu features based on kernel command line */
+ update_cpu_features();
identical_pvr_fixup(node);
init_mmu_slb_size(node);
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index 386be136026e..19680b42898f 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -437,12 +437,15 @@ static void __init early_check_vec5(void)
}
}
-void __init mmu_early_init_devtree(void)
+void __init update_cpu_features(void)
{
/* Disable radix mode based on kernel command line. */
if (disable_radix)
cur_cpu_spec->mmu_features &= ~MMU_FTR_TYPE_RADIX;
+}
+void __init mmu_early_init_devtree(void)
+{
/*
* Check /chosen/ibm,architecture-vec-5 if running as a guest.
* When running bare-metal, we can use radix if we like
--
2.31.1
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [RESEND PATCH v2 1/3] fixup mmu_features immediately after getting cpu pa features.
2021-10-18 8:44 ` [RESEND PATCH v2 1/3] fixup mmu_features immediately after getting cpu pa features Sourabh Jain
@ 2021-11-18 6:12 ` Sourabh Jain
0 siblings, 0 replies; 5+ messages in thread
From: Sourabh Jain @ 2021-11-18 6:12 UTC (permalink / raw)
To: linuxppc-dev, Michael Ellerman
Hi MPE,
Any comments or suggestion on list patch series?
Thanks,
Sourabh Jain
On 18/10/21 14:14, Sourabh Jain wrote:
> From: Mahesh Salgaonkar <mahesh@linux.ibm.com>
>
> On system with radix support available, early_radix_enabled() starts
> returning true for a small window (until mmu_early_init_devtree() is
> called) even when radix mode disabled on kernel command line. This causes
> ppc64_bolted_size() to return ULONG_MAX in HPT mode instead of supported
> segment size, during boot cpu paca allocation.
>
> Withi kernel command line = "... disable_radix":
>
> early_init_devtree: <- early_radix_enabled() = false
> early_init_dt_scan_cpus: <- early_radix_enabled() = false
> ...
> check_cpu_pa_features: <- early_radix_enabled() = false
> ... ^ <- early_radix_enabled() = TRUE
> allocate_paca: | <- early_radix_enabled() = TRUE
> ... |
> ppc64_bolted_size: | <- early_radix_enabled() = TRUE
> if (early_radix_enabled())| <- early_radix_enabled() = TRUE
> return ULONG_MAX; |
> ... |
> ... | <- early_radix_enabled() = TRUE
> ... | <- early_radix_enabled() = TRUE
> mmu_early_init_devtree() V
> ... <- early_radix_enabled() = false
>
> So far we have not seen any issue because allocate_paca() takes minimum of
> ppc64_bolted_size and rma_size while allocating paca. However it is better
> to close this window by fixing up the mmu features as early as possible.
> This fixes early_radix_enabled() and ppc64_bolted_size() to return valid
> values in radix disable mode. This patch will help subsequent patch to
> depend on early_radix_enabled() check while detecting supported segment
> size in HPT mode.
>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Reported-and-tested-by: Abdul haleem <abdhalee@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/book3s/64/mmu.h | 1 +
> arch/powerpc/include/asm/mmu.h | 1 +
> arch/powerpc/kernel/prom.c | 2 ++
> arch/powerpc/mm/init_64.c | 5 ++++-
> 4 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h
> index c02f42d1031e..d60be5051d60 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
> @@ -197,6 +197,7 @@ extern int mmu_vmemmap_psize;
> extern int mmu_io_psize;
>
> /* MMU initialization */
> +void update_cpu_features(void);
> void mmu_early_init_devtree(void);
> void hash__early_init_devtree(void);
> void radix__early_init_devtree(void);
> diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
> index 8abe8e42e045..5eb494ea85d7 100644
> --- a/arch/powerpc/include/asm/mmu.h
> +++ b/arch/powerpc/include/asm/mmu.h
> @@ -401,6 +401,7 @@ extern void early_init_mmu(void);
> 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 update_cpu_features(void) { }
> static inline void mmu_early_init_devtree(void) { }
>
> static inline void pkey_early_init_devtree(void) {}
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 2e67588f6f6e..889c909e4ed4 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -380,6 +380,8 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
> check_cpu_pa_features(node);
> }
>
> + /* Update cpu features based on kernel command line */
> + update_cpu_features();
> identical_pvr_fixup(node);
> init_mmu_slb_size(node);
>
> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
> index 386be136026e..19680b42898f 100644
> --- a/arch/powerpc/mm/init_64.c
> +++ b/arch/powerpc/mm/init_64.c
> @@ -437,12 +437,15 @@ static void __init early_check_vec5(void)
> }
> }
>
> -void __init mmu_early_init_devtree(void)
> +void __init update_cpu_features(void)
> {
> /* Disable radix mode based on kernel command line. */
> if (disable_radix)
> cur_cpu_spec->mmu_features &= ~MMU_FTR_TYPE_RADIX;
> +}
>
> +void __init mmu_early_init_devtree(void)
> +{
> /*
> * Check /chosen/ibm,architecture-vec-5 if running as a guest.
> * When running bare-metal, we can use radix if we like
^ permalink raw reply [flat|nested] 5+ messages in thread
* [RESEND PATCH v2 2/3] Remove 256MB limit restriction for boot cpu paca allocation
2021-10-18 8:44 [RESEND PATCH v2 0/3] Update crashkernel offset to allow kernel to boot on large config LPARs Sourabh Jain
2021-10-18 8:44 ` [RESEND PATCH v2 1/3] fixup mmu_features immediately after getting cpu pa features Sourabh Jain
@ 2021-10-18 8:44 ` Sourabh Jain
2021-10-18 8:44 ` [RESEND PATCH v2 3/3] powerpc: Set crashkernel offset to mid of RMA region Sourabh Jain
2 siblings, 0 replies; 5+ messages in thread
From: Sourabh Jain @ 2021-10-18 8:44 UTC (permalink / raw)
To: linuxppc-dev
Cc: Mahesh Salgaonkar, mahesh, Abdul haleem, aneesh.kumar, hbathini
From: Mahesh Salgaonkar <mahesh@linux.ibm.com>
At the time when we detect and allocate paca for boot cpu, we havn't yet
detected mmu feature of 1T segments support (not until
mmu_early_init_devtree() call). This causes ppc64_bolted_size() to return
256MB as limit forcing boot cpu paca allocation below 256MB always.
This works fine for kdump kernel boot as long as crashkernel reservation is
at offset below 256MB. But when we move kdump offset to 256MB or above,
kdump kernel fails to allocate paca for boot cpu below 256MB and crashes in
allocate_paca().
Moving the detection of segment sizes just before paca allocation for boot
cpu removes this restriction of 256MB limit. This allows kdump kernel to
successfully boot and capture vmcore.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Reported-and-tested-by: Abdul haleem <abdhalee@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/book3s/64/mmu.h | 1 +
arch/powerpc/kernel/prom.c | 6 ++++++
arch/powerpc/mm/book3s64/hash_utils.c | 5 ++++-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h
index d60be5051d60..9b05a84313bb 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu.h
@@ -199,6 +199,7 @@ extern int mmu_io_psize;
/* MMU initialization */
void update_cpu_features(void);
void mmu_early_init_devtree(void);
+void hash__early_detect_seg_size(void);
void hash__early_init_devtree(void);
void radix__early_init_devtree(void);
#ifdef CONFIG_PPC_PKEY
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 889c909e4ed4..5da2bfff4dea 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -385,6 +385,12 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
identical_pvr_fixup(node);
init_mmu_slb_size(node);
+#ifdef CONFIG_PPC_BOOK3S_64
+ /* Initialize segment sizes */
+ if (!early_radix_enabled())
+ hash__early_detect_seg_size();
+#endif
+
#ifdef CONFIG_PPC64
if (nthreads == 1)
cur_cpu_spec->cpu_features &= ~CPU_FTR_SMT;
diff --git a/arch/powerpc/mm/book3s64/hash_utils.c b/arch/powerpc/mm/book3s64/hash_utils.c
index c145776d3ae5..ef4fc6bb1b30 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -1020,11 +1020,14 @@ static void __init htab_initialize(void)
#undef KB
#undef MB
-void __init hash__early_init_devtree(void)
+void __init hash__early_detect_seg_size(void)
{
/* Initialize segment sizes */
of_scan_flat_dt(htab_dt_scan_seg_sizes, NULL);
+}
+void __init hash__early_init_devtree(void)
+{
/* Initialize page sizes */
htab_scan_page_sizes();
}
--
2.31.1
^ permalink raw reply related [flat|nested] 5+ messages in thread* [RESEND PATCH v2 3/3] powerpc: Set crashkernel offset to mid of RMA region
2021-10-18 8:44 [RESEND PATCH v2 0/3] Update crashkernel offset to allow kernel to boot on large config LPARs Sourabh Jain
2021-10-18 8:44 ` [RESEND PATCH v2 1/3] fixup mmu_features immediately after getting cpu pa features Sourabh Jain
2021-10-18 8:44 ` [RESEND PATCH v2 2/3] Remove 256MB limit restriction for boot cpu paca allocation Sourabh Jain
@ 2021-10-18 8:44 ` Sourabh Jain
2 siblings, 0 replies; 5+ messages in thread
From: Sourabh Jain @ 2021-10-18 8:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Abdul haleem, aneesh.kumar, hbathini, mahesh
On large config LPARs (having 192 and more cores), Linux fails to boot
due to insufficient memory in the first memblock. It is due to the
memory reservation for the crash kernel which starts at 128MB offset of
the first memblock. This memory reservation for the crash kernel doesn't
leave enough space in the first memblock to accommodate other essential
system resources.
The crash kernel start address was set to 128MB offset by default to
ensure that the crash kernel get some memory below the RMA region which
is used to be of size 256MB. But given that the RMA region size can be
512MB or more, setting the crash kernel offset to mid of RMA size will
leave enough space for kernel to allocate memory for other system
resources.
Since the above crash kernel offset change is only applicable to the LPAR
platform, the LPAR feature detection is pushed before the crash kernel
reservation. The rest of LPAR specific initialization will still
be done during pseries_probe_fw_features as usual.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Reported-and-tested-by: Abdul haleem <abdhalee@linux.vnet.ibm.com>
---
arch/powerpc/kernel/rtas.c | 4 ++++
arch/powerpc/kexec/core.c | 15 +++++++++++----
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index ff80bbad22a5..a49137727370 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1235,6 +1235,10 @@ int __init early_init_dt_scan_rtas(unsigned long node,
entryp = of_get_flat_dt_prop(node, "linux,rtas-entry", NULL);
sizep = of_get_flat_dt_prop(node, "rtas-size", NULL);
+ /* need this feature to decide the crashkernel offset */
+ if (of_get_flat_dt_prop(node, "ibm,hypertas-functions", NULL))
+ powerpc_firmware_features |= FW_FEATURE_LPAR;
+
if (basep && entryp && sizep) {
rtas.base = *basep;
rtas.entry = *entryp;
diff --git a/arch/powerpc/kexec/core.c b/arch/powerpc/kexec/core.c
index 48525e8b5730..71b1bfdadd76 100644
--- a/arch/powerpc/kexec/core.c
+++ b/arch/powerpc/kexec/core.c
@@ -147,11 +147,18 @@ void __init reserve_crashkernel(void)
if (!crashk_res.start) {
#ifdef CONFIG_PPC64
/*
- * On 64bit we split the RMO in half but cap it at half of
- * a small SLB (128MB) since the crash kernel needs to place
- * itself and some stacks to be in the first segment.
+ * On the LPAR platform place the crash kernel to mid of
+ * RMA size (512MB or more) to ensure the crash kernel
+ * gets enough space to place itself and some stack to be
+ * in the first segment. At the same time normal kernel
+ * also get enough space to allocate memory for essential
+ * system resource in the first segment. Keep the crash
+ * kernel starts at 128MB offset on other platforms.
*/
- crashk_res.start = min(0x8000000ULL, (ppc64_rma_size / 2));
+ if (firmware_has_feature(FW_FEATURE_LPAR))
+ crashk_res.start = ppc64_rma_size / 2;
+ else
+ crashk_res.start = min(0x8000000ULL, (ppc64_rma_size / 2));
#else
crashk_res.start = KDUMP_KERNELBASE;
#endif
--
2.31.1
^ permalink raw reply related [flat|nested] 5+ messages in thread