From: Aditya Gupta <adityag@linux.ibm.com>
To: <kexec@lists.infradead.org>
Cc: Hari Bathini <hbathini@linux.ibm.com>,
Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
Sourabh Jain <sourabhjain@linux.ibm.com>
Subject: [PATCH] makedumpfile: ppc64: read cur_mmu_type from vmcoreinfo
Date: Fri, 23 Feb 2024 11:23:06 +0530 [thread overview]
Message-ID: <20240223055306.34466-1-adityag@linux.ibm.com> (raw)
Currently makedumpfile depends on reading the 'cur_cpu_spec' kernel
symbol to get the current MMU type on PowerPC64.
The disadvantage with this approach was that it depends on bit '0x40'
('MMU_FTR_TYPE_RADIX') being set in 'cur_cpu_spec->mmu_features',
which implies kernel developers have to be careful of modifying
MMU_FTR_* defines
Instead a more stable approach was suggested by contributors in
https://lore.kernel.org/linuxppc-dev/87v8c3m70t.fsf@mail.lhotse/, to
pass information about the MMU type in vmcoreinfo itself, instead of
depending on the MMU_FTR_* defines
This was implemented in linux kernel in:
commit 36e826b568e4 ("powerpc/vmcore: Add MMU information to vmcoreinfo")
With this commit, if RADIX_MMU is there in the vmcoreinfo, we prefer it
to get current mmu type, instead of 'cur_cpu_spec'.
On older kernels, where RADIX_MMU number is not there, makedumpfile will
simply fall back to using 'cur_cpu_spec'.
The earlier defines for 'RADIX_MMU' have been renamed to 'MMU_TYPE_RADIX'
which avoids conflict with the vmcoreinfo string 'RADIX_MMU', as well as
being more clear about the value 0x40 with a comment about MMU_FTR_TYPE_RADIX
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
---
arch/ppc64.c | 15 ++++++++++-----
makedumpfile.c | 1 +
makedumpfile.h | 9 ++++++---
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/arch/ppc64.c b/arch/ppc64.c
index 96c357cb0335..3b4f91981f71 100644
--- a/arch/ppc64.c
+++ b/arch/ppc64.c
@@ -250,7 +250,7 @@ ppc64_vmalloc_init(void)
/*
* 64K pagesize
*/
- if (info->cur_mmu_type & RADIX_MMU) {
+ if (info->cur_mmu_type & MMU_TYPE_RADIX) {
info->l1_index_size = PTE_INDEX_SIZE_RADIX_64K;
info->l2_index_size = PMD_INDEX_SIZE_RADIX_64K;
info->l3_index_size = PUD_INDEX_SIZE_RADIX_64K;
@@ -300,7 +300,7 @@ ppc64_vmalloc_init(void)
/*
* 4K pagesize
*/
- if (info->cur_mmu_type & RADIX_MMU) {
+ if (info->cur_mmu_type & MMU_TYPE_RADIX) {
info->l1_index_size = PTE_INDEX_SIZE_RADIX_4K;
info->l2_index_size = PMD_INDEX_SIZE_RADIX_4K;
info->l3_index_size = PUD_INDEX_SIZE_RADIX_4K;
@@ -635,14 +635,19 @@ get_versiondep_info_ppc64()
* On PowerISA 3.0 based server processors, a kernel can run with
* radix MMU or standard MMU. Get the current MMU type.
*/
- info->cur_mmu_type = STD_MMU;
- if ((SYMBOL(cur_cpu_spec) != NOT_FOUND_SYMBOL)
+ info->cur_mmu_type = MMU_TYPE_STD;
+
+ if (NUMBER(RADIX_MMU) != NOT_FOUND_SYMBOL) {
+ if (NUMBER(RADIX_MMU) == 1) {
+ info->cur_mmu_type = MMU_TYPE_RADIX;
+ }
+ } else if ((SYMBOL(cur_cpu_spec) != NOT_FOUND_SYMBOL)
&& (OFFSET(cpu_spec.mmu_features) != NOT_FOUND_STRUCTURE)) {
if (readmem(VADDR, SYMBOL(cur_cpu_spec), &cur_cpu_spec,
sizeof(cur_cpu_spec))) {
if (readmem(VADDR, cur_cpu_spec + OFFSET(cpu_spec.mmu_features),
&mmu_features, sizeof(mmu_features)))
- info->cur_mmu_type = mmu_features & RADIX_MMU;
+ info->cur_mmu_type = mmu_features & MMU_TYPE_RADIX;
}
}
diff --git a/makedumpfile.c b/makedumpfile.c
index 3705bdd93deb..1bd7305f49ca 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -2987,6 +2987,7 @@ read_vmcoreinfo(void)
#endif
READ_NUMBER("HUGETLB_PAGE_DTOR", HUGETLB_PAGE_DTOR);
+ READ_NUMBER("RADIX_MMU", RADIX_MMU);
return TRUE;
}
diff --git a/makedumpfile.h b/makedumpfile.h
index 3ed3ba551d96..a7b344974636 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -747,12 +747,13 @@ unsigned long get_kvbase_arm64(void);
/*
* Supported MMU types
*/
-#define STD_MMU 0x0
+#define MMU_TYPE_STD 0x0
/*
* The flag bit for radix MMU in cpu_spec.mmu_features
- * in the kernel. Use the same flag here.
+ * in the kernel (MMU_FTR_TYPE_RADIX).
+ * Use the same flag here.
*/
-#define RADIX_MMU 0x40
+#define MMU_TYPE_RADIX 0x40
#define PGD_MASK_L4 \
@@ -2258,6 +2259,8 @@ struct number_table {
unsigned long kernel_link_addr;
unsigned long va_kernel_pa_offset;
#endif
+
+ unsigned long RADIX_MMU;
};
struct srcfile_table {
--
2.43.0
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next reply other threads:[~2024-02-23 5:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 5:53 Aditya Gupta [this message]
2024-02-23 7:54 ` [PATCH] makedumpfile: ppc64: read cur_mmu_type from vmcoreinfo Baoquan He
2024-02-23 8:37 ` Aditya Gupta
-- strict thread matches above, loose matches on Subject: below --
2024-02-23 8:39 Aditya Gupta
2024-02-28 0:25 ` HAGIO KAZUHITO(萩尾 一仁)
2024-02-28 9:37 ` Aditya Gupta
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=20240223055306.34466-1-adityag@linux.ibm.com \
--to=adityag@linux.ibm.com \
--cc=hbathini@linux.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=mahesh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).