[PATCH] makedumpfile: Support ARM64

[PATCH] makedumpfile: Support ARM64

[Pratyush Anand]

Patch adds support for ARM64 in makedumpfile. It takes care of vmalloc,
vmemmap, module and directly map kernel memory region's translation.

Currently we only support 2 leverl 64K pages and VA_BITS as 42. Support
to find these machine specific parameters dynamically and then to act
accordingly can be added latter.

Signed-off-by: Pratyush Anand <panand@redhat.com>
---
 Makefile       |   1 +
 arch/arm64.c   | 255 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 makedumpfile.h |  48 +++++++++++
 3 files changed, 304 insertions(+)
 create mode 100644 arch/arm64.c

diff --git a/Makefile b/Makefile
index 2d2b1b72929a..fc21a3f0e50a 100644
--- a/Makefile
+++ b/Makefile
@@ -49,6 +49,7 @@ SRC_BASE = makedumpfile.c makedumpfile.h diskdump_mod.h sadump_mod.h sadump_info
 SRC_PART = print_info.c dwarf_info.c elf_info.c erase_info.c sadump_info.c cache.c
 OBJ_PART=$(patsubst %.c,%.o,$(SRC_PART))
 SRC_ARCH = arch/arm.c arch/x86.c arch/x86_64.c arch/ia64.c arch/ppc64.c arch/s390x.c arch/ppc.c
+SRC_ARCH = arch/arm.c arch/arm64.c arch/x86.c arch/x86_64.c arch/ia64.c arch/ppc64.c arch/s390x.c arch/ppc.c
 OBJ_ARCH=$(patsubst %.c,%.o,$(SRC_ARCH))
 
 LIBS = -ldw -lbz2 -lebl -ldl -lelf -lz
diff --git a/arch/arm64.c b/arch/arm64.c
new file mode 100644
index 000000000000..23aabf09b332
--- /dev/null
+++ b/arch/arm64.c
@@ -0,0 +1,255 @@
+/*
+ * arch/arm64.c : Based on arch/arm.c
+ *
+ * Copyright (C) 2015 Red Hat, Pratyush Anand <panand@redhat.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation (version 2 of the License).
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifdef __aarch64__
+
+#include "../elf_info.h"
+#include "../makedumpfile.h"
+#include "../print_info.h"
+
+#if CONFIG_ARM64_PGTABLE_LEVELS == 2
+typedef struct {
+	unsigned long pgd;
+} pgd_t;
+
+typedef struct {
+	pgd_t pgd;
+} pud_t;
+
+typedef struct {
+	pud_t pud;
+} pmd_t;
+
+#define pud_offset(pgd, vaddr) 	((pud_t *)pgd)
+#define pmd_offset(pud, vaddr) 	((pmd_t *)pud)
+#define pgd_val(x)		((x).pgd)
+#define pud_val(x)		(pgd_val((x).pgd))
+#define pmd_val(x)		(pud_val((x).pud))
+
+#define PUD_SHIFT		PGDIR_SHIFT
+#define PUD_SIZE		(1UL << PUD_SHIFT)
+
+#endif
+
+typedef struct {
+	unsigned long pte;
+} pte_t;
+#define pte_val(x)		((x).pte)
+
+#define PAGE_SIZE		(1UL << PAGE_SHIFT)
+#define PAGE_MASK		(~(PAGE_SIZE - 1))
+#define PGDIR_SHIFT		((PAGE_SHIFT - 3) * ARM64_PGTABLE_LEVELS + 3)
+#define PTRS_PER_PGD		(1 << (VA_BITS - PGDIR_SHIFT))
+#define PMD_SHIFT		((PAGE_SHIFT - 3) * 2 + 3)
+#define PTRS_PER_PTE		(1 << (PAGE_SHIFT - 3))
+#define PMD_SHIFT		((PAGE_SHIFT - 3) * 2 + 3)
+#define PMD_SIZE		(1UL << PMD_SHIFT)
+#define PMD_MASK		(~(PMD_SIZE - 1))
+#define PTRS_PER_PMD		PTRS_PER_PTE
+
+#define PAGE_PRESENT		(1 << 0)
+#define SECTIONS_SIZE_BITS	30
+/*
+
+* Highest possible physical address supported.
+*/
+#define PHYS_MASK_SHIFT		48
+#define PHYS_MASK		((1UL << PHYS_MASK_SHIFT) - 1)
+
+#define PMD_TYPE_MASK		3
+#define PMD_TYPE_SECT		1
+#define PMD_TYPE_TABLE		3
+
+#define __va(paddr) 			((paddr) - info->phys_base + PAGE_OFFSET)
+#define __pa(vaddr) 			((vaddr) - PAGE_OFFSET + info->phys_base)
+
+#define pgd_index(vaddr) 		(((vaddr) >> PGDIR_SHIFT) & (PTRS_PER_PGD - 1))
+#define pgd_offset(pgdir, vaddr)	((pgd_t *)(pgdir) + pgd_index(vaddr))
+
+#define pte_index(addr) 		(((addr) >> PAGE_SHIFT) & (PTRS_PER_PTE - 1))
+#define pmd_page_vaddr(pmd)		(__va(pmd_val(pmd) & PHYS_MASK & (int32_t)PAGE_MASK))
+#define pte_offset(dir, vaddr) 		((pte_t*)pmd_page_vaddr((*dir)) + pte_index(vaddr))
+
+/* kernel struct page size can be kernel version dependent, currently
+ * keep it constant.
+ */
+#define KERN_STRUCT_PAGE_SIZE		64
+#define ALIGN(x, a) 			(((x) + (a) - 1) & ~((a) - 1))
+#define PFN_DOWN(x)			((x) >> PAGE_SHIFT)
+#define VMEMMAP_SIZE			ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * KERN_STRUCT_PAGE_SIZE, PUD_SIZE)
+#define MODULES_END			PAGE_OFFSET
+#define MODULES_VADDR			(MODULES_END - 0x4000000)
+
+
+static int is_vtop_from_page_table_arm64(unsigned long vaddr)
+{
+	/* If virtual address lies in vmalloc, vmemmap or module space
+	 * region then, get the physical address from page table.
+	 */
+	return ((vaddr >= VMALLOC_START && vaddr <= VMALLOC_END)
+		|| (vaddr >= VMEMMAP_START && vaddr <= VMEMMAP_END)
+		|| (vaddr >= MODULES_VADDR && vaddr <= MODULES_END));
+}
+
+int get_phys_base_arm64(void)
+{
+	unsigned long phys_base = ULONG_MAX;
+	unsigned long long phys_start;
+	int i;
+	/*
+	 * We resolve phys_base from PT_LOAD segments. LMA contains physical
+	 * address of the segment, and we use the lowest start as
+	 * phys_base.
+	 */
+	for (i = 0; get_pt_load(i, &phys_start, NULL, NULL, NULL); i++) {
+		if (phys_start < phys_base)
+			phys_base = phys_start;
+	}
+
+	if (phys_base == ULONG_MAX) {
+		ERRMSG("Can't determine phys_base\n");
+		return FALSE;
+	}
+
+	info->phys_base = phys_base;
+
+	DEBUG_MSG("phys_base    : %lx\n", phys_base);
+
+	return TRUE;
+}
+
+int get_machdep_info_arm64(void)
+{
+	info->max_physmem_bits = PHYS_MASK_SHIFT;
+	info->section_size_bits = SECTIONS_SIZE_BITS;
+	info->page_offset = KVBASE;
+	info->vmalloc_start = 0xffffffffffffffffUL << VA_BITS;
+	info->vmalloc_end = PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - 0x10000;
+	info->vmemmap_start = VMALLOC_END + 0x10000;
+	info->vmemmap_end = VMEMMAP_START + VMEMMAP_SIZE;
+
+	DEBUG_MSG("max_physmem_bits : %lx\n", info->max_physmem_bits);
+	DEBUG_MSG("section_size_bits: %lx\n", info->section_size_bits);
+	DEBUG_MSG("page_offset      : %lx\n", info->page_offset);
+	DEBUG_MSG("vmalloc_start    : %lx\n", info->vmalloc_start);
+	DEBUG_MSG("vmalloc_end      : %lx\n", info->vmalloc_end);
+	DEBUG_MSG("vmemmap_start    : %lx\n", info->vmemmap_start);
+	DEBUG_MSG("vmemmap_end      : %lx\n", info->vmemmap_end);
+	DEBUG_MSG("modules_start    : %lx\n", MODULES_VADDR);
+	DEBUG_MSG("modules_end      : %lx\n", MODULES_END);
+
+	return TRUE;
+}
+
+unsigned long long kvtop_xen_arm64(unsigned long kvaddr)
+{
+	return ERROR;
+}
+
+int get_xen_basic_info_arm64(void)
+{
+	return ERROR;
+}
+
+int get_xen_info_arm64(void)
+{
+	return ERROR;
+}
+
+int get_versiondep_info_arm64(void)
+{
+	return TRUE;
+}
+
+/*
+ * vtop_arm64() - translate arbitrary virtual address to physical
+ * @vaddr: virtual address to translate
+ *
+ * Function translates @vaddr into physical address using page tables. This
+ * address can be any virtual address. Returns physical address of the
+ * corresponding virtual address or %NOT_PADDR when there is no translation.
+ */
+static unsigned long long vtop_arm64(unsigned long vaddr)
+{
+	unsigned long long paddr = NOT_PADDR;
+	pgd_t	*pgda, pgdv;
+	pud_t	*puda;
+	pmd_t	*pmda, pmdv;
+	pte_t 	*ptea, ptev;
+
+	if (SYMBOL(swapper_pg_dir) == NOT_FOUND_SYMBOL) {
+		ERRMSG("Can't get the symbol of swapper_pg_dir.\n");
+		return NOT_PADDR;
+	}
+
+	pgda = pgd_offset(SYMBOL(swapper_pg_dir), vaddr);
+	if (!readmem(VADDR, (unsigned long long)pgda, &pgdv, sizeof(pgdv))) {
+		ERRMSG("Can't read pgd\n");
+		return NOT_PADDR;
+	}
+
+	puda = pud_offset(pgda, vaddr);
+	pmda = pmd_offset(puda, vaddr);
+	if (!readmem(VADDR, (unsigned long long)pmda, &pmdv, sizeof(pmdv))) {
+		ERRMSG("Can't read pmd\n");
+		return NOT_PADDR;
+	}
+
+	switch (pmd_val(pmdv) & PMD_TYPE_MASK) {
+	case PMD_TYPE_TABLE:
+		ptea = pte_offset(&pmdv, vaddr);
+		/* 64k page */
+		if (!readmem(VADDR, (unsigned long long)ptea, &ptev, sizeof(ptev))) {
+			ERRMSG("Can't read pte\n");
+			return NOT_PADDR;
+		}
+
+		if (!(pte_val(ptev) & PAGE_PRESENT)) {
+			ERRMSG("Can't get a valid pte.\n");
+			return NOT_PADDR;
+		} else {
+
+			paddr = (PAGEBASE(pte_val(ptev)) & PHYS_MASK)
+					+ (vaddr & (PAGESIZE() - 1));
+		}
+		break;
+	case PMD_TYPE_SECT:
+		/* 1GB section */
+		paddr = (pmd_val(pmdv) & PMD_MASK) + (vaddr & (PMD_SIZE - 1));
+		break;
+	}
+
+	return paddr;
+}
+
+unsigned long long vaddr_to_paddr_arm64(unsigned long vaddr)
+{
+	/*
+	 * use translation tables when a) user has explicitly requested us to
+	 * perform translation for a given address. b) virtual address lies in
+	 * vmalloc, vmemmap or modules memory region. Otherwise we assume that
+	 * the translation is done within the kernel direct mapped region.
+	 */
+	if ((info->vaddr_for_vtop == vaddr) ||
+			is_vtop_from_page_table_arm64(vaddr))
+		return vtop_arm64(vaddr);
+
+	return __pa(vaddr);
+}
+#endif
diff --git a/makedumpfile.h b/makedumpfile.h
index d2fadbd1f985..92a2bb629bcb 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -483,6 +483,33 @@ do { \
 #define VMEMMAP_START		(info->vmemmap_start)
 #define VMEMMAP_END		(info->vmemmap_end)
 
+#ifdef __aarch64__
+#define CONFIG_ARM64_PGTABLE_LEVELS	2
+#define CONFIG_ARM64_VA_BITS		42
+#define CONFIG_ARM64_64K_PAGES		1
+
+/* Currently we only suport following defines based on above
+ * config definitions.
+ * TODOs: We need to find a way to get above defines dynamically and
+ * then to support following definitions based on that
+ */
+
+#if CONFIG_ARM64_PGTABLE_LEVELS == 2
+#define ARM64_PGTABLE_LEVELS	2
+#endif
+
+#if CONFIG_ARM64_VA_BITS == 42
+#define VA_BITS			42
+#endif
+
+#ifdef CONFIG_ARM64_64K_PAGES
+#define PAGE_SHIFT		16
+#endif
+
+#define KVBASE_MASK		(0xffffffffffffffffUL << (VA_BITS - 1))
+#define KVBASE			(SYMBOL(_stext) & KVBASE_MASK)
+#endif /* aarch64 */
+
 #ifdef __arm__
 #define KVBASE_MASK		(0xffff)
 #define KVBASE			(SYMBOL(_stext) & ~KVBASE_MASK)
@@ -761,6 +788,22 @@ do { \
  */
 static inline int stub_true() { return TRUE; }
 static inline int stub_true_ul(unsigned long x) { return TRUE; }
+#ifdef __aarch64__
+int get_phys_base_arm64(void);
+int get_machdep_info_arm64(void);
+unsigned long long vaddr_to_paddr_arm64(unsigned long vaddr);
+int get_versiondep_info_arm64(void);
+int get_xen_basic_info_arm64(void);
+int get_xen_info_arm64(void);
+#define vaddr_to_paddr(X)	vaddr_to_paddr_arm64(X)
+#define get_phys_base()		get_phys_base_arm64()
+#define get_machdep_info()	get_machdep_info_arm64()
+#define get_versiondep_info()	get_versiondep_info_arm64()
+#define get_xen_basic_info_arch(X) get_xen_basic_info_arm64(X)
+#define get_xen_info_arch(X) get_xen_info_arm64(X)
+#define is_phys_addr(X)		stub_true_ul(X)
+#endif /* aarch64 */
+
 #ifdef __arm__
 int get_phys_base_arm(void);
 int get_machdep_info_arm(void);
@@ -1608,6 +1651,11 @@ struct domain_list {
 #define PAGES_PER_MAPWORD 	(sizeof(unsigned long) * 8)
 #define MFNS_PER_FRAME		(info->page_size / sizeof(unsigned long))
 
+#ifdef __aarch64__
+unsigned long long kvtop_xen_arm64(unsigned long kvaddr);
+#define kvtop_xen(X)	kvtop_xen_arm64(X)
+#endif /* aarch64 */
+
 #ifdef __arm__
 #define kvtop_xen(X)	FALSE
 #define get_xen_basic_info_arch(X) FALSE
-- 
2.1.0


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

RE: [PATCH] makedumpfile: Support ARM64

[Atsushi Kumagai]

Hello Pratyush,

>Patch adds support for ARM64 in makedumpfile. It takes care of vmalloc,
>vmemmap, module and directly map kernel memory region's translation.
>
>Currently we only support 2 leverl 64K pages and VA_BITS as 42. Support
>to find these machine specific parameters dynamically and then to act
>accordingly can be added latter.
>
>Signed-off-by: Pratyush Anand <panand@redhat.com>

Thanks for your work, I'll merge this into v1.5.9.


Regards,
Atsushi Kumagai

>---
> Makefile       |   1 +
> arch/arm64.c   | 255 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> makedumpfile.h |  48 +++++++++++
> 3 files changed, 304 insertions(+)
> create mode 100644 arch/arm64.c
>
>diff --git a/Makefile b/Makefile
>index 2d2b1b72929a..fc21a3f0e50a 100644
>--- a/Makefile
>+++ b/Makefile
>@@ -49,6 +49,7 @@ SRC_BASE = makedumpfile.c makedumpfile.h diskdump_mod.h sadump_mod.h sadump_info
> SRC_PART = print_info.c dwarf_info.c elf_info.c erase_info.c sadump_info.c cache.c
> OBJ_PART=$(patsubst %.c,%.o,$(SRC_PART))
> SRC_ARCH = arch/arm.c arch/x86.c arch/x86_64.c arch/ia64.c arch/ppc64.c arch/s390x.c arch/ppc.c
>+SRC_ARCH = arch/arm.c arch/arm64.c arch/x86.c arch/x86_64.c arch/ia64.c arch/ppc64.c arch/s390x.c arch/ppc.c
> OBJ_ARCH=$(patsubst %.c,%.o,$(SRC_ARCH))
>
> LIBS = -ldw -lbz2 -lebl -ldl -lelf -lz
>diff --git a/arch/arm64.c b/arch/arm64.c
>new file mode 100644
>index 000000000000..23aabf09b332
>--- /dev/null
>+++ b/arch/arm64.c
>@@ -0,0 +1,255 @@
>+/*
>+ * arch/arm64.c : Based on arch/arm.c
>+ *
>+ * Copyright (C) 2015 Red Hat, Pratyush Anand <panand@redhat.com>
>+ *
>+ * This program is free software; you can redistribute it and/or modify
>+ * it under the terms of the GNU General Public License as published by
>+ * the Free Software Foundation (version 2 of the License).
>+ *
>+ * This program is distributed in the hope that it will be useful,
>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
>+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>+ * GNU General Public License for more details.
>+ *
>+ * You should have received a copy of the GNU General Public License
>+ * along with this program; if not, write to the Free Software
>+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>+ */
>+
>+#ifdef __aarch64__
>+
>+#include "../elf_info.h"
>+#include "../makedumpfile.h"
>+#include "../print_info.h"
>+
>+#if CONFIG_ARM64_PGTABLE_LEVELS == 2
>+typedef struct {
>+	unsigned long pgd;
>+} pgd_t;
>+
>+typedef struct {
>+	pgd_t pgd;
>+} pud_t;
>+
>+typedef struct {
>+	pud_t pud;
>+} pmd_t;
>+
>+#define pud_offset(pgd, vaddr) 	((pud_t *)pgd)
>+#define pmd_offset(pud, vaddr) 	((pmd_t *)pud)
>+#define pgd_val(x)		((x).pgd)
>+#define pud_val(x)		(pgd_val((x).pgd))
>+#define pmd_val(x)		(pud_val((x).pud))
>+
>+#define PUD_SHIFT		PGDIR_SHIFT
>+#define PUD_SIZE		(1UL << PUD_SHIFT)
>+
>+#endif
>+
>+typedef struct {
>+	unsigned long pte;
>+} pte_t;
>+#define pte_val(x)		((x).pte)
>+
>+#define PAGE_SIZE		(1UL << PAGE_SHIFT)
>+#define PAGE_MASK		(~(PAGE_SIZE - 1))
>+#define PGDIR_SHIFT		((PAGE_SHIFT - 3) * ARM64_PGTABLE_LEVELS + 3)
>+#define PTRS_PER_PGD		(1 << (VA_BITS - PGDIR_SHIFT))
>+#define PMD_SHIFT		((PAGE_SHIFT - 3) * 2 + 3)
>+#define PTRS_PER_PTE		(1 << (PAGE_SHIFT - 3))
>+#define PMD_SHIFT		((PAGE_SHIFT - 3) * 2 + 3)
>+#define PMD_SIZE		(1UL << PMD_SHIFT)
>+#define PMD_MASK		(~(PMD_SIZE - 1))
>+#define PTRS_PER_PMD		PTRS_PER_PTE
>+
>+#define PAGE_PRESENT		(1 << 0)
>+#define SECTIONS_SIZE_BITS	30
>+/*
>+
>+* Highest possible physical address supported.
>+*/
>+#define PHYS_MASK_SHIFT		48
>+#define PHYS_MASK		((1UL << PHYS_MASK_SHIFT) - 1)
>+
>+#define PMD_TYPE_MASK		3
>+#define PMD_TYPE_SECT		1
>+#define PMD_TYPE_TABLE		3
>+
>+#define __va(paddr) 			((paddr) - info->phys_base + PAGE_OFFSET)
>+#define __pa(vaddr) 			((vaddr) - PAGE_OFFSET + info->phys_base)
>+
>+#define pgd_index(vaddr) 		(((vaddr) >> PGDIR_SHIFT) & (PTRS_PER_PGD - 1))
>+#define pgd_offset(pgdir, vaddr)	((pgd_t *)(pgdir) + pgd_index(vaddr))
>+
>+#define pte_index(addr) 		(((addr) >> PAGE_SHIFT) & (PTRS_PER_PTE - 1))
>+#define pmd_page_vaddr(pmd)		(__va(pmd_val(pmd) & PHYS_MASK & (int32_t)PAGE_MASK))
>+#define pte_offset(dir, vaddr) 		((pte_t*)pmd_page_vaddr((*dir)) + pte_index(vaddr))
>+
>+/* kernel struct page size can be kernel version dependent, currently
>+ * keep it constant.
>+ */
>+#define KERN_STRUCT_PAGE_SIZE		64
>+#define ALIGN(x, a) 			(((x) + (a) - 1) & ~((a) - 1))
>+#define PFN_DOWN(x)			((x) >> PAGE_SHIFT)
>+#define VMEMMAP_SIZE			ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * KERN_STRUCT_PAGE_SIZE, PUD_SIZE)
>+#define MODULES_END			PAGE_OFFSET
>+#define MODULES_VADDR			(MODULES_END - 0x4000000)
>+
>+
>+static int is_vtop_from_page_table_arm64(unsigned long vaddr)
>+{
>+	/* If virtual address lies in vmalloc, vmemmap or module space
>+	 * region then, get the physical address from page table.
>+	 */
>+	return ((vaddr >= VMALLOC_START && vaddr <= VMALLOC_END)
>+		|| (vaddr >= VMEMMAP_START && vaddr <= VMEMMAP_END)
>+		|| (vaddr >= MODULES_VADDR && vaddr <= MODULES_END));
>+}
>+
>+int get_phys_base_arm64(void)
>+{
>+	unsigned long phys_base = ULONG_MAX;
>+	unsigned long long phys_start;
>+	int i;
>+	/*
>+	 * We resolve phys_base from PT_LOAD segments. LMA contains physical
>+	 * address of the segment, and we use the lowest start as
>+	 * phys_base.
>+	 */
>+	for (i = 0; get_pt_load(i, &phys_start, NULL, NULL, NULL); i++) {
>+		if (phys_start < phys_base)
>+			phys_base = phys_start;
>+	}
>+
>+	if (phys_base == ULONG_MAX) {
>+		ERRMSG("Can't determine phys_base\n");
>+		return FALSE;
>+	}
>+
>+	info->phys_base = phys_base;
>+
>+	DEBUG_MSG("phys_base    : %lx\n", phys_base);
>+
>+	return TRUE;
>+}
>+
>+int get_machdep_info_arm64(void)
>+{
>+	info->max_physmem_bits = PHYS_MASK_SHIFT;
>+	info->section_size_bits = SECTIONS_SIZE_BITS;
>+	info->page_offset = KVBASE;
>+	info->vmalloc_start = 0xffffffffffffffffUL << VA_BITS;
>+	info->vmalloc_end = PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - 0x10000;
>+	info->vmemmap_start = VMALLOC_END + 0x10000;
>+	info->vmemmap_end = VMEMMAP_START + VMEMMAP_SIZE;
>+
>+	DEBUG_MSG("max_physmem_bits : %lx\n", info->max_physmem_bits);
>+	DEBUG_MSG("section_size_bits: %lx\n", info->section_size_bits);
>+	DEBUG_MSG("page_offset      : %lx\n", info->page_offset);
>+	DEBUG_MSG("vmalloc_start    : %lx\n", info->vmalloc_start);
>+	DEBUG_MSG("vmalloc_end      : %lx\n", info->vmalloc_end);
>+	DEBUG_MSG("vmemmap_start    : %lx\n", info->vmemmap_start);
>+	DEBUG_MSG("vmemmap_end      : %lx\n", info->vmemmap_end);
>+	DEBUG_MSG("modules_start    : %lx\n", MODULES_VADDR);
>+	DEBUG_MSG("modules_end      : %lx\n", MODULES_END);
>+
>+	return TRUE;
>+}
>+
>+unsigned long long kvtop_xen_arm64(unsigned long kvaddr)
>+{
>+	return ERROR;
>+}
>+
>+int get_xen_basic_info_arm64(void)
>+{
>+	return ERROR;
>+}
>+
>+int get_xen_info_arm64(void)
>+{
>+	return ERROR;
>+}
>+
>+int get_versiondep_info_arm64(void)
>+{
>+	return TRUE;
>+}
>+
>+/*
>+ * vtop_arm64() - translate arbitrary virtual address to physical
>+ * @vaddr: virtual address to translate
>+ *
>+ * Function translates @vaddr into physical address using page tables. This
>+ * address can be any virtual address. Returns physical address of the
>+ * corresponding virtual address or %NOT_PADDR when there is no translation.
>+ */
>+static unsigned long long vtop_arm64(unsigned long vaddr)
>+{
>+	unsigned long long paddr = NOT_PADDR;
>+	pgd_t	*pgda, pgdv;
>+	pud_t	*puda;
>+	pmd_t	*pmda, pmdv;
>+	pte_t 	*ptea, ptev;
>+
>+	if (SYMBOL(swapper_pg_dir) == NOT_FOUND_SYMBOL) {
>+		ERRMSG("Can't get the symbol of swapper_pg_dir.\n");
>+		return NOT_PADDR;
>+	}
>+
>+	pgda = pgd_offset(SYMBOL(swapper_pg_dir), vaddr);
>+	if (!readmem(VADDR, (unsigned long long)pgda, &pgdv, sizeof(pgdv))) {
>+		ERRMSG("Can't read pgd\n");
>+		return NOT_PADDR;
>+	}
>+
>+	puda = pud_offset(pgda, vaddr);
>+	pmda = pmd_offset(puda, vaddr);
>+	if (!readmem(VADDR, (unsigned long long)pmda, &pmdv, sizeof(pmdv))) {
>+		ERRMSG("Can't read pmd\n");
>+		return NOT_PADDR;
>+	}
>+
>+	switch (pmd_val(pmdv) & PMD_TYPE_MASK) {
>+	case PMD_TYPE_TABLE:
>+		ptea = pte_offset(&pmdv, vaddr);
>+		/* 64k page */
>+		if (!readmem(VADDR, (unsigned long long)ptea, &ptev, sizeof(ptev))) {
>+			ERRMSG("Can't read pte\n");
>+			return NOT_PADDR;
>+		}
>+
>+		if (!(pte_val(ptev) & PAGE_PRESENT)) {
>+			ERRMSG("Can't get a valid pte.\n");
>+			return NOT_PADDR;
>+		} else {
>+
>+			paddr = (PAGEBASE(pte_val(ptev)) & PHYS_MASK)
>+					+ (vaddr & (PAGESIZE() - 1));
>+		}
>+		break;
>+	case PMD_TYPE_SECT:
>+		/* 1GB section */
>+		paddr = (pmd_val(pmdv) & PMD_MASK) + (vaddr & (PMD_SIZE - 1));
>+		break;
>+	}
>+
>+	return paddr;
>+}
>+
>+unsigned long long vaddr_to_paddr_arm64(unsigned long vaddr)
>+{
>+	/*
>+	 * use translation tables when a) user has explicitly requested us to
>+	 * perform translation for a given address. b) virtual address lies in
>+	 * vmalloc, vmemmap or modules memory region. Otherwise we assume that
>+	 * the translation is done within the kernel direct mapped region.
>+	 */
>+	if ((info->vaddr_for_vtop == vaddr) ||
>+			is_vtop_from_page_table_arm64(vaddr))
>+		return vtop_arm64(vaddr);
>+
>+	return __pa(vaddr);
>+}
>+#endif
>diff --git a/makedumpfile.h b/makedumpfile.h
>index d2fadbd1f985..92a2bb629bcb 100644
>--- a/makedumpfile.h
>+++ b/makedumpfile.h
>@@ -483,6 +483,33 @@ do { \
> #define VMEMMAP_START		(info->vmemmap_start)
> #define VMEMMAP_END		(info->vmemmap_end)
>
>+#ifdef __aarch64__
>+#define CONFIG_ARM64_PGTABLE_LEVELS	2
>+#define CONFIG_ARM64_VA_BITS		42
>+#define CONFIG_ARM64_64K_PAGES		1
>+
>+/* Currently we only suport following defines based on above
>+ * config definitions.
>+ * TODOs: We need to find a way to get above defines dynamically and
>+ * then to support following definitions based on that
>+ */
>+
>+#if CONFIG_ARM64_PGTABLE_LEVELS == 2
>+#define ARM64_PGTABLE_LEVELS	2
>+#endif
>+
>+#if CONFIG_ARM64_VA_BITS == 42
>+#define VA_BITS			42
>+#endif
>+
>+#ifdef CONFIG_ARM64_64K_PAGES
>+#define PAGE_SHIFT		16
>+#endif
>+
>+#define KVBASE_MASK		(0xffffffffffffffffUL << (VA_BITS - 1))
>+#define KVBASE			(SYMBOL(_stext) & KVBASE_MASK)
>+#endif /* aarch64 */
>+
> #ifdef __arm__
> #define KVBASE_MASK		(0xffff)
> #define KVBASE			(SYMBOL(_stext) & ~KVBASE_MASK)
>@@ -761,6 +788,22 @@ do { \
>  */
> static inline int stub_true() { return TRUE; }
> static inline int stub_true_ul(unsigned long x) { return TRUE; }
>+#ifdef __aarch64__
>+int get_phys_base_arm64(void);
>+int get_machdep_info_arm64(void);
>+unsigned long long vaddr_to_paddr_arm64(unsigned long vaddr);
>+int get_versiondep_info_arm64(void);
>+int get_xen_basic_info_arm64(void);
>+int get_xen_info_arm64(void);
>+#define vaddr_to_paddr(X)	vaddr_to_paddr_arm64(X)
>+#define get_phys_base()		get_phys_base_arm64()
>+#define get_machdep_info()	get_machdep_info_arm64()
>+#define get_versiondep_info()	get_versiondep_info_arm64()
>+#define get_xen_basic_info_arch(X) get_xen_basic_info_arm64(X)
>+#define get_xen_info_arch(X) get_xen_info_arm64(X)
>+#define is_phys_addr(X)		stub_true_ul(X)
>+#endif /* aarch64 */
>+
> #ifdef __arm__
> int get_phys_base_arm(void);
> int get_machdep_info_arm(void);
>@@ -1608,6 +1651,11 @@ struct domain_list {
> #define PAGES_PER_MAPWORD 	(sizeof(unsigned long) * 8)
> #define MFNS_PER_FRAME		(info->page_size / sizeof(unsigned long))
>
>+#ifdef __aarch64__
>+unsigned long long kvtop_xen_arm64(unsigned long kvaddr);
>+#define kvtop_xen(X)	kvtop_xen_arm64(X)
>+#endif /* aarch64 */
>+
> #ifdef __arm__
> #define kvtop_xen(X)	FALSE
> #define get_xen_basic_info_arch(X) FALSE
>--
>2.1.0

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

Re: [PATCH] makedumpfile: Support ARM64

[Timur Tabi]

On Fri, May 15, 2015 at 1:30 PM, Pratyush Anand <panand@redhat.com> wrote:
> Patch adds support for ARM64 in makedumpfile. It takes care of vmalloc,
> vmemmap, module and directly map kernel memory region's translation.
>
> Currently we only support 2 leverl 64K pages and VA_BITS as 42. Support
> to find these machine specific parameters dynamically and then to act
> accordingly can be added latter.

So ARM64 kernels are typically compiled with 3-level 4KB pages:

CONFIG_ARM64_4K_PAGES=y
# CONFIG_ARM64_64K_PAGES is not set
CONFIG_ARM64_VA_BITS_39=y
# CONFIG_ARM64_VA_BITS_48 is not set
CONFIG_ARM64_VA_BITS=39

Does this mean that your patch won't work on such a kernel?  If so, do
you have any plans to add support for 4K 3-level pages?

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

Re: [PATCH] makedumpfile: Support ARM64

[Pratyush Anand]

Hi Timur,

On 23/06/2015:06:19:01 PM, Timur Tabi wrote:
> On Fri, May 15, 2015 at 1:30 PM, Pratyush Anand <panand@redhat.com> wrote:
> > Patch adds support for ARM64 in makedumpfile. It takes care of vmalloc,
> > vmemmap, module and directly map kernel memory region's translation.
> >
> > Currently we only support 2 leverl 64K pages and VA_BITS as 42. Support
> > to find these machine specific parameters dynamically and then to act
> > accordingly can be added latter.
> 
> So ARM64 kernels are typically compiled with 3-level 4KB pages:
> 
> CONFIG_ARM64_4K_PAGES=y
> # CONFIG_ARM64_64K_PAGES is not set
> CONFIG_ARM64_VA_BITS_39=y
> # CONFIG_ARM64_VA_BITS_48 is not set
> CONFIG_ARM64_VA_BITS=39
> 
> Does this mean that your patch won't work on such a kernel?  If so, do

Yes, it will not work with above kernel.

> you have any plans to add support for 4K 3-level pages?

I can try to find out some time in weekend to refactor arm64 code
and then add 3 level, 4K support. May be I will need a Tested-by.

~Pratyush

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

Re: [PATCH] makedumpfile: Support ARM64

[Timur Tabi]

Pratyush Anand wrote:
> I can try to find out some time in weekend to refactor arm64 code
> and then add 3 level, 4K support. May be I will need a Tested-by.

We'd be more than happy to test any code from you promptly.  We're eager 
to get this to work.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.

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

Re: [PATCH] makedumpfile: Support ARM64

[Pratyush Anand]

Hi Timur,

On 23/06/2015:10:36:03 PM, Timur Tabi wrote:
> Pratyush Anand wrote:
> >I can try to find out some time in weekend to refactor arm64 code
> >and then add 3 level, 4K support. May be I will need a Tested-by.
> 
> We'd be more than happy to test any code from you promptly.  We're eager to
> get this to work.

I have done the changes, hopefully it should work, but have not
tested. Let me know, if it works will send them as formal patches
to upstream.

https://github.com/pratyushanand/makedumpfile.git : arm64_support
(9b95423bcea0)

~Pratyush

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

Re: [PATCH] makedumpfile: Support ARM64

[Azriel Samson]

Hi Pratyush,

I am working with Timur and we are testing your version of makedumpfile.
The tool is unable to get the kernel version and quits from check_release().

I tried to debug the vmcore file with gdb but the file looks corrupt.

Let me know if you have any ideas on what could be wrong?

> Hi Timur,
>
> On 23/06/2015:10:36:03 PM, Timur Tabi wrote:
>> Pratyush Anand wrote:
>> >I can try to find out some time in weekend to refactor arm64 code
>> >and then add 3 level, 4K support. May be I will need a Tested-by.
>>
>> We'd be more than happy to test any code from you promptly.  We're eager
>> to
>> get this to work.
>
> I have done the changes, hopefully it should work, but have not
> tested. Let me know, if it works will send them as formal patches
> to upstream.
>
> https://github.com/pratyushanand/makedumpfile.git : arm64_support
> (9b95423bcea0)
>
> ~Pratyush
>

-- 
Thanks,
Azriel Samson
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, 
a Linux Foundation Collaborative Project


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

Re: [PATCH] makedumpfile: Support ARM64

[Pratyush Anand]

Hi Azriel,

On 01/07/2015:06:42:46 PM, Azriel Samson wrote:
> Hi Pratyush,
> 
> I am working with Timur and we are testing your version of makedumpfile.

Thanks for testing.

> The tool is unable to get the kernel version and quits from check_release().

Couple of questions:

1. Can you please let me know VA_BITS configured in your case?

2. Do you expect any regions other than vmalloc, vmemmap or modules,
which are not directly mapped and their physical address need to be
found from swapper_pg_dir?

In my vmcore, I did not had any address where
is_vtop_from_page_table_arm64 would be true. So, vtop_arm64 function
has been only cross checked logically. So,
a) Please put a print in vtop_arm64 and check if control goes there?
b) if yes, then please print vaddr and paddr at the end of vtop_arm64
and see if that is correct. If not we need to debug vtop_arm64.

~Pratyush

> 
> I tried to debug the vmcore file with gdb but the file looks corrupt.
> 
> Let me know if you have any ideas on what could be wrong?
> 
> > Hi Timur,
> >
> > On 23/06/2015:10:36:03 PM, Timur Tabi wrote:
> >> Pratyush Anand wrote:
> >> >I can try to find out some time in weekend to refactor arm64 code
> >> >and then add 3 level, 4K support. May be I will need a Tested-by.
> >>
> >> We'd be more than happy to test any code from you promptly.  We're eager
> >> to
> >> get this to work.
> >
> > I have done the changes, hopefully it should work, but have not
> > tested. Let me know, if it works will send them as formal patches
> > to upstream.
> >
> > https://github.com/pratyushanand/makedumpfile.git : arm64_support
> > (9b95423bcea0)
> >
> > ~Pratyush
> >
> 
> -- 
> Thanks,
> Azriel Samson
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, 
> a Linux Foundation Collaborative Project

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

Re: [PATCH] makedumpfile: Support ARM64

[Azriel Samson]

Hi Pratyush,

I was able to run makedumpfile with "-d 31" but the dumpfile was
approximately the same size as that of vmcore (~16GB).

Answers inline.

> Hi Azriel,
>
> On 01/07/2015:06:42:46 PM, Azriel Samson wrote:
>> Hi Pratyush,
>>
>> I am working with Timur and we are testing your version of makedumpfile.
>
> Thanks for testing.
>
>> The tool is unable to get the kernel version and quits from
>> check_release().
>
> Couple of questions:
>
> 1. Can you please let me know VA_BITS configured in your case?
VA_BITS=39
> 2. Do you expect any regions other than vmalloc, vmemmap or modules,
> which are not directly mapped and their physical address need to be
> found from swapper_pg_dir?
No
> In my vmcore, I did not had any address where
> is_vtop_from_page_table_arm64 would be true. So, vtop_arm64 function
> has been only cross checked logically. So,
> a) Please put a print in vtop_arm64 and check if control goes there?
> b) if yes, then please print vaddr and paddr at the end of vtop_arm64
> and see if that is correct. If not we need to debug vtop_arm64.
I still need to try this. Will get back when I do.
> ~Pratyush
>
>>
>> I tried to debug the vmcore file with gdb but the file looks corrupt.
>>
>> Let me know if you have any ideas on what could be wrong?
>>
>> > Hi Timur,
>> >
>> > On 23/06/2015:10:36:03 PM, Timur Tabi wrote:
>> >> Pratyush Anand wrote:
>> >> >I can try to find out some time in weekend to refactor arm64 code
>> >> >and then add 3 level, 4K support. May be I will need a Tested-by.
>> >>
>> >> We'd be more than happy to test any code from you promptly.  We're
>> eager
>> >> to
>> >> get this to work.
>> >
>> > I have done the changes, hopefully it should work, but have not
>> > tested. Let me know, if it works will send them as formal patches
>> > to upstream.
>> >
>> > https://github.com/pratyushanand/makedumpfile.git : arm64_support
>> > (9b95423bcea0)
>> >
>> > ~Pratyush
>> >
>>
>> --
>> Thanks,
>> Azriel Samson
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>> Forum, 
>> a Linux Foundation Collaborative Project
>


-- 
Thanks,
Azriel Samson
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, 
a Linux Foundation Collaborative Project


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

Re: [PATCH] makedumpfile: Support ARM64

[Azriel Samson]

Adding Sameer as he has a few questions on kvbase.

> Hi Pratyush,
>
> I was able to run makedumpfile with "-d 31" but the dumpfile was
> approximately the same size as that of vmcore (~16GB).
>
> Answers inline.
>
>> Hi Azriel,
>>
>> On 01/07/2015:06:42:46 PM, Azriel Samson wrote:
>>> Hi Pratyush,
>>>
>>> I am working with Timur and we are testing your version of
>>> makedumpfile.
>>
>> Thanks for testing.
>>
>>> The tool is unable to get the kernel version and quits from
>>> check_release().
>>
>> Couple of questions:
>>
>> 1. Can you please let me know VA_BITS configured in your case?
> VA_BITS=39
>> 2. Do you expect any regions other than vmalloc, vmemmap or modules,
>> which are not directly mapped and their physical address need to be
>> found from swapper_pg_dir?
> No
>> In my vmcore, I did not had any address where
>> is_vtop_from_page_table_arm64 would be true. So, vtop_arm64 function
>> has been only cross checked logically. So,
>> a) Please put a print in vtop_arm64 and check if control goes there?
>> b) if yes, then please print vaddr and paddr at the end of vtop_arm64
>> and see if that is correct. If not we need to debug vtop_arm64.
> I still need to try this. Will get back when I do.
>> ~Pratyush
>>
>>>
>>> I tried to debug the vmcore file with gdb but the file looks corrupt.
>>>
>>> Let me know if you have any ideas on what could be wrong?
>>>
>>> > Hi Timur,
>>> >
>>> > On 23/06/2015:10:36:03 PM, Timur Tabi wrote:
>>> >> Pratyush Anand wrote:
>>> >> >I can try to find out some time in weekend to refactor arm64 code
>>> >> >and then add 3 level, 4K support. May be I will need a Tested-by.
>>> >>
>>> >> We'd be more than happy to test any code from you promptly.  We're
>>> eager
>>> >> to
>>> >> get this to work.
>>> >
>>> > I have done the changes, hopefully it should work, but have not
>>> > tested. Let me know, if it works will send them as formal patches
>>> > to upstream.
>>> >
>>> > https://github.com/pratyushanand/makedumpfile.git : arm64_support
>>> > (9b95423bcea0)
>>> >
>>> > ~Pratyush
>>> >
>>>
>>> --
>>> Thanks,
>>> Azriel Samson
>>> Qualcomm Innovation Center, Inc.
>>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>>> Forum, 
>>> a Linux Foundation Collaborative Project
>>
>
>
> --
> Thanks,
> Azriel Samson
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> Forum, 
> a Linux Foundation Collaborative Project
>


-- 
Thanks,
Azriel Samson
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, 
a Linux Foundation Collaborative Project


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

Re: [PATCH] makedumpfile: Support ARM64

[sgoel]

Hi Pratyush,

I made the following changes to the code:

KVBASE was being mapped to page_offset, so the mem_map that I saw using
the kmem command in crash did not seem to audit with the data generated by
make dumpfile. I changed this to vmalloc_start.

After making the above change the mem_map was getting generated fine. But
still I am always failing in:
================================
ptea = pte_offset(&pmdv, vaddr);
		/* 64k page */
		if (!readmem(VADDR, (unsigned long long)ptea, &ptev, sizeof(ptev))) {
			ERRMSG("Can't read pte\n");
			return NOT_PADDR;
		}
=================================


The KERN_STRUCT_PAGE_SIZE evaluates to 56 and not 64. I changed the
required value and the arch info is now valid.

I am still failing in the page translation. I will highly appreciate any
help with this.

Thanks,
Sameer

> Adding Sameer as he has a few questions on kvbase.
>
>> Hi Pratyush,
>>
>> I was able to run makedumpfile with "-d 31" but the dumpfile was
>> approximately the same size as that of vmcore (~16GB).
>>
>> Answers inline.
>>
>>> Hi Azriel,
>>>
>>> On 01/07/2015:06:42:46 PM, Azriel Samson wrote:
>>>> Hi Pratyush,
>>>>
>>>> I am working with Timur and we are testing your version of
>>>> makedumpfile.
>>>
>>> Thanks for testing.
>>>
>>>> The tool is unable to get the kernel version and quits from
>>>> check_release().
>>>
>>> Couple of questions:
>>>
>>> 1. Can you please let me know VA_BITS configured in your case?
>> VA_BITS=39
>>> 2. Do you expect any regions other than vmalloc, vmemmap or modules,
>>> which are not directly mapped and their physical address need to be
>>> found from swapper_pg_dir?
>> No
>>> In my vmcore, I did not had any address where
>>> is_vtop_from_page_table_arm64 would be true. So, vtop_arm64 function
>>> has been only cross checked logically. So,
>>> a) Please put a print in vtop_arm64 and check if control goes there?
>>> b) if yes, then please print vaddr and paddr at the end of vtop_arm64
>>> and see if that is correct. If not we need to debug vtop_arm64.
>> I still need to try this. Will get back when I do.
>>> ~Pratyush
>>>
>>>>
>>>> I tried to debug the vmcore file with gdb but the file looks corrupt.
>>>>
>>>> Let me know if you have any ideas on what could be wrong?
>>>>
>>>> > Hi Timur,
>>>> >
>>>> > On 23/06/2015:10:36:03 PM, Timur Tabi wrote:
>>>> >> Pratyush Anand wrote:
>>>> >> >I can try to find out some time in weekend to refactor arm64 code
>>>> >> >and then add 3 level, 4K support. May be I will need a Tested-by.
>>>> >>
>>>> >> We'd be more than happy to test any code from you promptly.  We're
>>>> eager
>>>> >> to
>>>> >> get this to work.
>>>> >
>>>> > I have done the changes, hopefully it should work, but have not
>>>> > tested. Let me know, if it works will send them as formal patches
>>>> > to upstream.
>>>> >
>>>> > https://github.com/pratyushanand/makedumpfile.git : arm64_support
>>>> > (9b95423bcea0)
>>>> >
>>>> > ~Pratyush
>>>> >
>>>>
>>>> --
>>>> Thanks,
>>>> Azriel Samson
>>>> Qualcomm Innovation Center, Inc.
>>>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>>>> Forum, 
>>>> a Linux Foundation Collaborative Project
>>>
>>
>>
>> --
>> Thanks,
>> Azriel Samson
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>> Forum, 
>> a Linux Foundation Collaborative Project
>>
>
>
> --
> Thanks,
> Azriel Samson
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> Forum, 
> a Linux Foundation Collaborative Project
>
>



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

Re: [PATCH] makedumpfile: Support ARM64

[Pratyush Anand]

Hi Sameer,

On 19/08/2015:11:16:07 PM, sgoel@codeaurora.org wrote:
> Hi Pratyush,
> 
> I made the following changes to the code:
> 
> KVBASE was being mapped to page_offset, so the mem_map that I saw using
> the kmem command in crash did not seem to audit with the data generated by
> make dumpfile. I changed this to vmalloc_start.

I am not sure if KVBASE should be VMALLOC_START. May be Atsushi can comment on
that. But if so, did you correct info->page_offset definition in
get_machdep_info_arm64? Something like following...

diff --git a/arch/arm64.c b/arch/arm64.c
index 4d50012529c3..a94a4ba16dd5 100644
--- a/arch/arm64.c
+++ b/arch/arm64.c
@@ -199,7 +199,8 @@ get_machdep_info_arm64(void)
 {
 	info->max_physmem_bits = PHYS_MASK_SHIFT;
 	info->section_size_bits = SECTIONS_SIZE_BITS;
-	info->page_offset = KVBASE;
+	info->page_offset = SYMBOL(_stext)
+		& (0xffffffffffffffffUL << (VA_BITS - 1));
 	info->vmalloc_start = 0xffffffffffffffffUL << VA_BITS;
 	info->vmalloc_end = PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - 0x10000;
 	info->vmemmap_start = VMALLOC_END + 0x10000;
diff --git a/makedumpfile.h b/makedumpfile.h
index c33b5f321d9a..f7d6fbefe98e 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -488,8 +488,7 @@ int get_va_bits_arm64(void);
 #define ARM64_PGTABLE_LEVELS	get_pgtable_level_arm64()
 #define VA_BITS			get_va_bits_arm64()
 #define PAGE_SHIFT		get_page_shift_arm64()
-#define KVBASE_MASK		(0xffffffffffffffffUL << (VA_BITS - 1))
-#define KVBASE			(SYMBOL(_stext) & KVBASE_MASK)
+#define KVBASE			VMALLOC_START
 #endif /* aarch64 */
 
 #ifdef __arm__

~Pratyush

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

Re: [PATCH] makedumpfile: Support ARM64

[sgoel]

Hi Pratush,
I have made the change now.

The reason for changing the KVBASE was to get non zero value for mem_map
as seen from the crash tool. If KVBASE stays at page offset we do not get
into the function that looks for the free pages.

After looking at the page usage using the crash tool it seems that ~80% of
the pages are free.

Maybe there is something else that I am missing here. The page look up
fails when writing the crashdump file.
Thanks,
Sameer

> Hi Sameer,
>
> On 19/08/2015:11:16:07 PM, sgoel@codeaurora.org wrote:
>> Hi Pratyush,
>>
>> I made the following changes to the code:
>>
>> KVBASE was being mapped to page_offset, so the mem_map that I saw using
>> the kmem command in crash did not seem to audit with the data generated
>> by
>> make dumpfile. I changed this to vmalloc_start.
>
> I am not sure if KVBASE should be VMALLOC_START. May be Atsushi can
> comment on
> that. But if so, did you correct info->page_offset definition in
> get_machdep_info_arm64? Something like following...
>
> diff --git a/arch/arm64.c b/arch/arm64.c
> index 4d50012529c3..a94a4ba16dd5 100644
> --- a/arch/arm64.c
> +++ b/arch/arm64.c
> @@ -199,7 +199,8 @@ get_machdep_info_arm64(void)
>  {
>  	info->max_physmem_bits = PHYS_MASK_SHIFT;
>  	info->section_size_bits = SECTIONS_SIZE_BITS;
> -	info->page_offset = KVBASE;
> +	info->page_offset = SYMBOL(_stext)
> +		& (0xffffffffffffffffUL << (VA_BITS - 1));
>  	info->vmalloc_start = 0xffffffffffffffffUL << VA_BITS;
>  	info->vmalloc_end = PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - 0x10000;
>  	info->vmemmap_start = VMALLOC_END + 0x10000;
> diff --git a/makedumpfile.h b/makedumpfile.h
> index c33b5f321d9a..f7d6fbefe98e 100644
> --- a/makedumpfile.h
> +++ b/makedumpfile.h
> @@ -488,8 +488,7 @@ int get_va_bits_arm64(void);
>  #define ARM64_PGTABLE_LEVELS	get_pgtable_level_arm64()
>  #define VA_BITS			get_va_bits_arm64()
>  #define PAGE_SHIFT		get_page_shift_arm64()
> -#define KVBASE_MASK		(0xffffffffffffffffUL << (VA_BITS - 1))
> -#define KVBASE			(SYMBOL(_stext) & KVBASE_MASK)
> +#define KVBASE			VMALLOC_START
>  #endif /* aarch64 */
>
>  #ifdef __arm__
>
> ~Pratyush
>



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

Re: [PATCH] makedumpfile: Support ARM64

[Pratyush Anand]

Hi Sameer,

On 20/08/2015:04:11:24 PM, sgoel@codeaurora.org wrote:
> Hi Pratush,
> I have made the change now.
> 
> The reason for changing the KVBASE was to get non zero value for mem_map
> as seen from the crash tool. If KVBASE stays at page offset we do not get
> into the function that looks for the free pages.

OK.. I made the change for KVBASE and pushed it to my github repo.

> 
> After looking at the page usage using the crash tool it seems that ~80% of
> the pages are free.
> 
> Maybe there is something else that I am missing here. The page look up
> fails when writing the crashdump file.

Not sure if you can share the output with --message-level 31, but do you see any
thing susceptible there?

# makedumpfile -l --message-level 31 rawvmcore makedumpfilevmcore

Can you compare "Virtual kernel memory layout:" print of Linux kernel boot with
makedumpfile print for page_offset, vmalloc_start, vmemmap_start etc, and see if
they match?

They should match.

~Pratyush

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

RE: [PATCH] makedumpfile: Support ARM64

[Atsushi Kumagai]

Hello,

>> I am not sure if KVBASE should be VMALLOC_START. May be Atsushi can
>> comment on that.

This is a just reply to the above.

[snip]
>> The reason for changing the KVBASE was to get non zero value for mem_map
>> as seen from the crash tool. If KVBASE stays at page offset we do not get
>> into the function that looks for the free pages.
>
>OK.. I made the change for KVBASE and pushed it to my github repo.

KVBASE just means where kernel address spaces begins, it is just set to
PAGE_OFFSET(0xffff880000000000) in x86_64 as an implementation according to
the specification.

In arm64, I'm not sure the memory model but you also should set it
according to the specification of the memory layout of arm64 to walk the
page table correctly.
In my quick check, it looks the kernel address space begins at the vmalloc
region in arm64, so I guess your change is reasonable.


Thanks,
Atsushi Kumagai

>>
>> After looking at the page usage using the crash tool it seems that ~80% of
>> the pages are free.
>>
>> Maybe there is something else that I am missing here. The page look up
>> fails when writing the crashdump file.
>
>Not sure if you can share the output with --message-level 31, but do you see any
>thing susceptible there?
>
># makedumpfile -l --message-level 31 rawvmcore makedumpfilevmcore
>
>Can you compare "Virtual kernel memory layout:" print of Linux kernel boot with
>makedumpfile print for page_offset, vmalloc_start, vmemmap_start etc, and see if
>they match?
>
>They should match.
>
>~Pratyush
>
>_______________________________________________
>kexec mailing list
>kexec@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/kexec

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

Re: [PATCH] makedumpfile: Support ARM64

[sgoel]

> Can you compare "Virtual kernel memory layout:" print of Linux kernel boot
> with
> makedumpfile print for page_offset, vmalloc_start, vmemmap_start etc, and
> see if
> they match?
>
> They should match.


Yes this was a problem. The assumed Kernel struct page size in the tool is
64. For our platform this evaluates to 56. After changing this value all
the memory mapping values match.

I wanted to ask if the page table translation function would be any
different if the page size is 4k instead of 64k?

Thanks,
Sameer


> Hi Sameer,
>
> On 20/08/2015:04:11:24 PM, sgoel@codeaurora.org wrote:
>> Hi Pratush,
>> I have made the change now.
>>
>> The reason for changing the KVBASE was to get non zero value for mem_map
>> as seen from the crash tool. If KVBASE stays at page offset we do not
>> get
>> into the function that looks for the free pages.
>
> OK.. I made the change for KVBASE and pushed it to my github repo.
>
>>
>> After looking at the page usage using the crash tool it seems that ~80%
>> of
>> the pages are free.
>>
>> Maybe there is something else that I am missing here. The page look up
>> fails when writing the crashdump file.
>
> Not sure if you can share the output with --message-level 31, but do you
> see any
> thing susceptible there?
>
> # makedumpfile -l --message-level 31 rawvmcore makedumpfilevmcore
>
> Can you compare "Virtual kernel memory layout:" print of Linux kernel boot
> with
> makedumpfile print for page_offset, vmalloc_start, vmemmap_start etc, and
> see if
> they match?
>
> They should match.
>
> ~Pratyush
>



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

Re: [PATCH] makedumpfile: Support ARM64

[Pratyush Anand]

On 21/08/2015:08:37:57 PM, sgoel@codeaurora.org wrote:
> > Can you compare "Virtual kernel memory layout:" print of Linux kernel boot
> > with
> > makedumpfile print for page_offset, vmalloc_start, vmemmap_start etc, and
> > see if
> > they match?
> >
> > They should match.
> 
> 
> Yes this was a problem. The assumed Kernel struct page size in the tool is
> 64. For our platform this evaluates to 56. After changing this value all
> the memory mapping values match.

Great !!!

To be on the same page:
* You did following changes on top of
https://github.com/pratyushanand/makedumpfile.git:arm64_support (last commit
597ea74d40b7 arm64: Fix KVBASE) and it worked for you, right? If yes, then is
there out of mainline change in struct page for you? If it is mainline, then can
you please let me know the kernel version, so that on the basic of kernel
version I can fix it.

diff --git a/arch/arm64.c b/arch/arm64.c
index a94a4ba16dd5..4154ed6fe4a5 100644
--- a/arch/arm64.c
+++ b/arch/arm64.c
@@ -86,7 +86,7 @@ typedef struct {
 /* kernel struct page size can be kernel version dependent, currently
  * keep it constant.
  */
-#define KERN_STRUCT_PAGE_SIZE		64
+#define KERN_STRUCT_PAGE_SIZE		56
 #define ALIGN(x, a) 			(((x) + (a) - 1) & ~((a) - 1))
 #define PFN_DOWN(x)			((x) >> PAGE_SHIFT)
 #define VMEMMAP_SIZE			ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * KERN_STRUCT_PAGE_SIZE, PUD_SIZE)

> 
> I wanted to ask if the page table translation function would be any
> different if the page size is 4k instead of 64k?

I believe, if we have programmed pgtable_level, va_bits and page_shift
correctly, then vtop_arm64 should be able to calculate it for both 4K and 64K.

~Pratyush

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

Re: [PATCH] makedumpfile: Support ARM64

[sgoel]

> * You did following changes on top of
> https://github.com/pratyushanand/makedumpfile.git:arm64_support (last
> commit
> 597ea74d40b7 arm64: Fix KVBASE) and it worked for you, right?

Yes. Making the change to kernel struct page size fixed the memory map
values. We are using a 4.0.0 kernel. I checked the struct page and there
are some changes to it between the kernel versions. There is no platform
specific change that we have made.

The code still cannot find the free pages as it is exiting due to a
virtual to physical translation.
readmem: Can't convert a virtual address(ffffffbee0023000) to physical
address.
readmem: type_addr: 0, addr:ffffffbee0023000, size:28672
__exclude_unnecessary_pages: Can't read the buffer of struct page.
create_2nd_bitmap: Can't exclude unnecessary pages.

The above is a valid virtual address and maps to a correct physical
address when I check this using kmem -p using the crash tool. Any help
will be appreciated.

Thanks,
Sameer



> On 21/08/2015:08:37:57 PM, sgoel@codeaurora.org wrote:
>> > Can you compare "Virtual kernel memory layout:" print of Linux kernel
>> boot
>> > with
>> > makedumpfile print for page_offset, vmalloc_start, vmemmap_start etc,
>> and
>> > see if
>> > they match?
>> >
>> > They should match.
>>
>>
>> Yes this was a problem. The assumed Kernel struct page size in the tool
>> is
>> 64. For our platform this evaluates to 56. After changing this value all
>> the memory mapping values match.
>
> Great !!!
>
> To be on the same page:
> * You did following changes on top of
> https://github.com/pratyushanand/makedumpfile.git:arm64_support (last
> commit
> 597ea74d40b7 arm64: Fix KVBASE) and it worked for you, right? If yes, then
> is
> there out of mainline change in struct page for you? If it is mainline,
> then can
> you please let me know the kernel version, so that on the basic of kernel
> version I can fix it.
>
> diff --git a/arch/arm64.c b/arch/arm64.c
> index a94a4ba16dd5..4154ed6fe4a5 100644
> --- a/arch/arm64.c
> +++ b/arch/arm64.c
> @@ -86,7 +86,7 @@ typedef struct {
>  /* kernel struct page size can be kernel version dependent, currently
>   * keep it constant.
>   */
> -#define KERN_STRUCT_PAGE_SIZE		64
> +#define KERN_STRUCT_PAGE_SIZE		56
>  #define ALIGN(x, a) 			(((x) + (a) - 1) & ~((a) - 1))
>  #define PFN_DOWN(x)			((x) >> PAGE_SHIFT)
>  #define VMEMMAP_SIZE			ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) *
> KERN_STRUCT_PAGE_SIZE, PUD_SIZE)
>
>>
>> I wanted to ask if the page table translation function would be any
>> different if the page size is 4k instead of 64k?
>
> I believe, if we have programmed pgtable_level, va_bits and page_shift
> correctly, then vtop_arm64 should be able to calculate it for both 4K and
> 64K.
>
> ~Pratyush
>



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

Re: [PATCH] makedumpfile: Support ARM64

[sgoel]

I also looked at the definitions for PMD_OFFSET in the code and this is
evaluating to no PMD. This should not be the case. So, I am wondering if
these defines should change?

I tried changing these but still the virtual address to physical address
translation is failing.

Please comment.
Thanks,
Sameer



>> * You did following changes on top of
>> https://github.com/pratyushanand/makedumpfile.git:arm64_support (last
>> commit
>> 597ea74d40b7 arm64: Fix KVBASE) and it worked for you, right?
>
> Yes. Making the change to kernel struct page size fixed the memory map
> values. We are using a 4.0.0 kernel. I checked the struct page and there
> are some changes to it between the kernel versions. There is no platform
> specific change that we have made.
>
> The code still cannot find the free pages as it is exiting due to a
> virtual to physical translation.
> readmem: Can't convert a virtual address(ffffffbee0023000) to physical
> address.
> readmem: type_addr: 0, addr:ffffffbee0023000, size:28672
> __exclude_unnecessary_pages: Can't read the buffer of struct page.
> create_2nd_bitmap: Can't exclude unnecessary pages.
>
> The above is a valid virtual address and maps to a correct physical
> address when I check this using kmem -p using the crash tool. Any help
> will be appreciated.
>
> Thanks,
> Sameer
>
>
>
>> On 21/08/2015:08:37:57 PM, sgoel@codeaurora.org wrote:
>>> > Can you compare "Virtual kernel memory layout:" print of Linux kernel
>>> boot
>>> > with
>>> > makedumpfile print for page_offset, vmalloc_start, vmemmap_start etc,
>>> and
>>> > see if
>>> > they match?
>>> >
>>> > They should match.
>>>
>>>
>>> Yes this was a problem. The assumed Kernel struct page size in the tool
>>> is
>>> 64. For our platform this evaluates to 56. After changing this value
>>> all
>>> the memory mapping values match.
>>
>> Great !!!
>>
>> To be on the same page:
>> * You did following changes on top of
>> https://github.com/pratyushanand/makedumpfile.git:arm64_support (last
>> commit
>> 597ea74d40b7 arm64: Fix KVBASE) and it worked for you, right? If yes,
>> then
>> is
>> there out of mainline change in struct page for you? If it is mainline,
>> then can
>> you please let me know the kernel version, so that on the basic of
>> kernel
>> version I can fix it.
>>
>> diff --git a/arch/arm64.c b/arch/arm64.c
>> index a94a4ba16dd5..4154ed6fe4a5 100644
>> --- a/arch/arm64.c
>> +++ b/arch/arm64.c
>> @@ -86,7 +86,7 @@ typedef struct {
>>  /* kernel struct page size can be kernel version dependent, currently
>>   * keep it constant.
>>   */
>> -#define KERN_STRUCT_PAGE_SIZE		64
>> +#define KERN_STRUCT_PAGE_SIZE		56
>>  #define ALIGN(x, a) 			(((x) + (a) - 1) & ~((a) - 1))
>>  #define PFN_DOWN(x)			((x) >> PAGE_SHIFT)
>>  #define VMEMMAP_SIZE			ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) *
>> KERN_STRUCT_PAGE_SIZE, PUD_SIZE)
>>
>>>
>>> I wanted to ask if the page table translation function would be any
>>> different if the page size is 4k instead of 64k?
>>
>> I believe, if we have programmed pgtable_level, va_bits and page_shift
>> correctly, then vtop_arm64 should be able to calculate it for both 4K
>> and
>> 64K.
>>
>> ~Pratyush
>>
>
>
>



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

Re: [PATCH] makedumpfile: Support ARM64

[sgoel]

Hi Pratush,
 I added the mappings for PMD translations to the vtop function. This
helped in translating the address to physical. Issues seen:
1. If PMD translates to a section. The physical translations does not get
rid of the PMD flags. So, the physical address shows up as invalid and
code crashes when it tries to read this address from ELF.
2. After treating this as a PTE table address, we see a compression of
around 50%.

But the final file generated not does not load using the crash tool. Any
recommendations will be helpful.
Thanks,
Sameer



> I also looked at the definitions for PMD_OFFSET in the code and this is
> evaluating to no PMD. This should not be the case. So, I am wondering if
> these defines should change?
>
> I tried changing these but still the virtual address to physical address
> translation is failing.
>
> Please comment.
> Thanks,
> Sameer
>
>
>
>>> * You did following changes on top of
>>> https://github.com/pratyushanand/makedumpfile.git:arm64_support (last
>>> commit
>>> 597ea74d40b7 arm64: Fix KVBASE) and it worked for you, right?
>>
>> Yes. Making the change to kernel struct page size fixed the memory map
>> values. We are using a 4.0.0 kernel. I checked the struct page and there
>> are some changes to it between the kernel versions. There is no platform
>> specific change that we have made.
>>
>> The code still cannot find the free pages as it is exiting due to a
>> virtual to physical translation.
>> readmem: Can't convert a virtual address(ffffffbee0023000) to physical
>> address.
>> readmem: type_addr: 0, addr:ffffffbee0023000, size:28672
>> __exclude_unnecessary_pages: Can't read the buffer of struct page.
>> create_2nd_bitmap: Can't exclude unnecessary pages.
>>
>> The above is a valid virtual address and maps to a correct physical
>> address when I check this using kmem -p using the crash tool. Any help
>> will be appreciated.
>>
>> Thanks,
>> Sameer
>>
>>
>>
>>> On 21/08/2015:08:37:57 PM, sgoel@codeaurora.org wrote:
>>>> > Can you compare "Virtual kernel memory layout:" print of Linux
>>>> kernel
>>>> boot
>>>> > with
>>>> > makedumpfile print for page_offset, vmalloc_start, vmemmap_start
>>>> etc,
>>>> and
>>>> > see if
>>>> > they match?
>>>> >
>>>> > They should match.
>>>>
>>>>
>>>> Yes this was a problem. The assumed Kernel struct page size in the
>>>> tool
>>>> is
>>>> 64. For our platform this evaluates to 56. After changing this value
>>>> all
>>>> the memory mapping values match.
>>>
>>> Great !!!
>>>
>>> To be on the same page:
>>> * You did following changes on top of
>>> https://github.com/pratyushanand/makedumpfile.git:arm64_support (last
>>> commit
>>> 597ea74d40b7 arm64: Fix KVBASE) and it worked for you, right? If yes,
>>> then
>>> is
>>> there out of mainline change in struct page for you? If it is mainline,
>>> then can
>>> you please let me know the kernel version, so that on the basic of
>>> kernel
>>> version I can fix it.
>>>
>>> diff --git a/arch/arm64.c b/arch/arm64.c
>>> index a94a4ba16dd5..4154ed6fe4a5 100644
>>> --- a/arch/arm64.c
>>> +++ b/arch/arm64.c
>>> @@ -86,7 +86,7 @@ typedef struct {
>>>  /* kernel struct page size can be kernel version dependent, currently
>>>   * keep it constant.
>>>   */
>>> -#define KERN_STRUCT_PAGE_SIZE		64
>>> +#define KERN_STRUCT_PAGE_SIZE		56
>>>  #define ALIGN(x, a) 			(((x) + (a) - 1) & ~((a) - 1))
>>>  #define PFN_DOWN(x)			((x) >> PAGE_SHIFT)
>>>  #define VMEMMAP_SIZE			ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) *
>>> KERN_STRUCT_PAGE_SIZE, PUD_SIZE)
>>>
>>>>
>>>> I wanted to ask if the page table translation function would be any
>>>> different if the page size is 4k instead of 64k?
>>>
>>> I believe, if we have programmed pgtable_level, va_bits and page_shift
>>> correctly, then vtop_arm64 should be able to calculate it for both 4K
>>> and
>>> 64K.
>>>
>>> ~Pratyush
>>>
>>
>>
>>
>
>
>



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

Re: [PATCH] makedumpfile: Support ARM64

[Pratyush Anand]

HI Sameer,


On Wed, Sep 9, 2015 at 4:02 AM,  <sgoel@codeaurora.org> wrote:
> Hi Pratush,
>  I added the mappings for PMD translations to the vtop function. This
> helped in translating the address to physical. Issues seen:
> 1. If PMD translates to a section. The physical translations does not get
> rid of the PMD flags. So, the physical address shows up as invalid and
> code crashes when it tries to read this address from ELF.
> 2. After treating this as a PTE table address, we see a compression of
> around 50%.
>

Is it possible for you to share the modification you would have done
on top of https://github.com/pratyushanand/makedumpfile.git:arm64_support.
Actually, I have lost track of all the modifications you have done on
top of my changes.

I would like to review it closely this weekend and will suggest you
whatever I find.

~Pratyush

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

Re: [PATCH] makedumpfile: Support ARM64

[sgoel]

hi Pratyush,
 Most of the chages are translation level and architecture related. I was
able to get this working on Friday for 3 level tables on arm64. I am
trying to get this code back to you now.
Thanks,
Sameer

> HI Sameer,
>
>
> On Wed, Sep 9, 2015 at 4:02 AM,  <sgoel@codeaurora.org> wrote:
>> Hi Pratush,
>>  I added the mappings for PMD translations to the vtop function. This
>> helped in translating the address to physical. Issues seen:
>> 1. If PMD translates to a section. The physical translations does not
>> get
>> rid of the PMD flags. So, the physical address shows up as invalid and
>> code crashes when it tries to read this address from ELF.
>> 2. After treating this as a PTE table address, we see a compression of
>> around 50%.
>>
>
> Is it possible for you to share the modification you would have done
> on top of https://github.com/pratyushanand/makedumpfile.git:arm64_support.
> Actually, I have lost track of all the modifications you have done on
> top of my changes.
>
> I would like to review it closely this weekend and will suggest you
> whatever I find.
>
> ~Pratyush
>



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