[PATCH v2 0/7] (kexec-tools) arm64: add kdump support

[PATCH v2 0/7] (kexec-tools) arm64: add kdump support

[AKASHI Takahiro]

My kernel patches of kdump suport on arm64 are currently under reviews [1].

This patchset is synced with them (v24) and provides necessary changes for
kexec-tools. It should be applied on top of Geoff's kexec-tools patches
v3[2] along with a bugfix[3].

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447597.html
[2] http://lists.infradead.org/pipermail/kexec/2016-August/016768.html
[3] http://lists.infradead.org/pipermail/kexec/2016-July/016664.html

Changes for v2:
 - Trim a temoprary buffer in setup_2nd_dtb()
 - Add patch#6("kexec: generalize and rename get_kernel_stext_sym()")
 - Update patch#7 from Pratyush
   (re-worked by akashi)

AKASHI Takahiro (5):
  arm64: kdump: identify memory regions
  arm64: kdump: add elf core header segment
  arm64: kdump: set up kernel image segment
  arm64: kdump: set up other segments
  arm64: kdump: add DT properties to crash dump kernel's dtb

Pratyush Anand (2):
  kexec: generalize and rename get_kernel_stext_sym()
  arm64: kdump: Add support for binary image files

 kexec/arch/arm/crashdump-arm.c          |  40 +------
 kexec/arch/arm64/Makefile               |   2 +
 kexec/arch/arm64/crashdump-arm64.c      | 188 +++++++++++++++++++++++++++++++-
 kexec/arch/arm64/crashdump-arm64.h      |  18 ++-
 kexec/arch/arm64/include/arch/options.h |   8 +-
 kexec/arch/arm64/kexec-arm64.c          |  91 ++++++++++++++--
 kexec/arch/arm64/kexec-elf-arm64.c      |  23 +++-
 kexec/arch/arm64/kexec-image-arm64.c    |  60 +++++++++-
 kexec/arch/i386/crashdump-x86.c         |  32 +-----
 kexec/crashdump.c                       |  37 +++++++
 kexec/crashdump.h                       |   1 +
 11 files changed, 407 insertions(+), 93 deletions(-)

-- 
2.9.0


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

[PATCH v2 1/7] arm64: kdump: identify memory regions

[AKASHI Takahiro]

The following regions need to be identified for later use:
 a) memory regions which belong to the 1st kernel
 b) usable memory reserved for crash dump kernel

We go through /proc/iomem to find out a) and b) which are marked
as "System RAM" and "Crash kernel", respectively.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
 kexec/arch/arm64/Makefile          |   2 +
 kexec/arch/arm64/crashdump-arm64.c | 104 ++++++++++++++++++++++++++++++++++++-
 kexec/arch/arm64/crashdump-arm64.h |  14 ++++-
 3 files changed, 117 insertions(+), 3 deletions(-)

diff --git a/kexec/arch/arm64/Makefile b/kexec/arch/arm64/Makefile
index 37414dc..c2535c6 100644
--- a/kexec/arch/arm64/Makefile
+++ b/kexec/arch/arm64/Makefile
@@ -5,6 +5,8 @@ arm64_FS2DT_INCLUDE += -include $(srcdir)/kexec/arch/arm64/kexec-arm64.h \
 
 arm64_DT_OPS += kexec/dt-ops.c
 
+arm64_MEM_REGIONS = kexec/mem_regions.c
+
 arm64_CPPFLAGS += -I $(srcdir)/kexec/
 
 arm64_KEXEC_SRCS += \
diff --git a/kexec/arch/arm64/crashdump-arm64.c b/kexec/arch/arm64/crashdump-arm64.c
index d2272c8..5ab017c 100644
--- a/kexec/arch/arm64/crashdump-arm64.c
+++ b/kexec/arch/arm64/crashdump-arm64.c
@@ -1,5 +1,13 @@
 /*
  * ARM64 crashdump.
+ *     partly derived from arm implementation
+ *
+ * Copyright (c) 2014-2016 Linaro Limited
+ * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
  */
 
 #define _GNU_SOURCE
@@ -12,10 +20,104 @@
 #include "crashdump-arm64.h"
 #include "kexec-arm64.h"
 #include "kexec-elf.h"
+#include "mem_regions.h"
 
-struct memory_ranges usablemem_rgns = {};
+#define CRASH_KERNEL "Crash kernel"
+#define SYSTEM_RAM "System RAM"
+
+/* memory ranges on crashed kernel */
+static struct memory_range crash_memory_ranges[CRASH_MAX_MEMORY_RANGES];
+static struct memory_ranges crash_memory_rgns = {
+	.size = 0,
+	.max_size = CRASH_MAX_MEMORY_RANGES,
+	.ranges = crash_memory_ranges,
+};
+
+/* memory range reserved for crashkernel */
+struct memory_range crash_reserved_mem;
+struct memory_ranges usablemem_rgns = {
+	.size = 0,
+	.max_size = 1,
+	.ranges = &crash_reserved_mem,
+};
+
+/*
+ * iomem_range_callback() - callback called for each iomem region
+ * @data: not used
+ * @nr: not used
+ * @str: name of the memory region
+ * @base: start address of the memory region
+ * @length: size of the memory region
+ *
+ * This function is called once for each memory region found in /proc/iomem.
+ * It locates system RAM and crashkernel reserved memory and places these to
+ * variables, respectively, crash_memory_ranges and crash_reserved_mem.
+ */
+
+static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
+				char *str, unsigned long long base,
+				unsigned long long length)
+{
+	if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
+		return mem_regions_add(&usablemem_rgns,
+				       base, length, RANGE_RAM);
+	}
+	else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
+		return mem_regions_add(&crash_memory_rgns,
+				       base, length, RANGE_RAM);
+	}
+
+	return 0;
+}
 
 int is_crashkernel_mem_reserved(void)
 {
+	if (!crash_reserved_mem.end)
+		kexec_iomem_for_each_line(NULL, iomem_range_callback, NULL);
+
+	return crash_reserved_mem.start != crash_reserved_mem.end;
+}
+
+/*
+ * crash_get_memory_ranges() - read system physical memory
+ *
+ * Function reads through system physical memory and stores found memory
+ * regions in crash_memory_ranges.
+ * Regions are sorted in ascending order.
+ *
+ * Returns 0 in case of success and -1 otherwise (errno is set).
+ */
+static int crash_get_memory_ranges(void)
+{
+	/*
+	 * First read all memory regions that can be considered as
+	 * system memory including the crash area.
+	 */
+	if (!usablemem_rgns.size)
+		kexec_iomem_for_each_line(NULL, iomem_range_callback, NULL);
+
+	/* allow only a single region for crash dump kernel */
+	if (usablemem_rgns.size != 1) {
+		errno = EINVAL;
+		return -1;
+	}
+
+	dbgprint_mem_range("Reserved memory range", &crash_reserved_mem, 1);
+
+	if (mem_regions_exclude(&crash_memory_rgns, &crash_reserved_mem)) {
+		fprintf(stderr,
+			"Error: Number of crash memory ranges excedeed the max limit\n");
+		errno = ENOMEM;
+		return -1;
+	}
+
+	/*
+	 * Make sure that the memory regions are sorted.
+	 */
+	mem_regions_sort(&crash_memory_rgns);
+
+	dbgprint_mem_range("Coredump memory ranges",
+			   crash_memory_rgns.ranges, crash_memory_rgns.size);
+
 	return 0;
 }
diff --git a/kexec/arch/arm64/crashdump-arm64.h b/kexec/arch/arm64/crashdump-arm64.h
index f33c7a2..07a0ed0 100644
--- a/kexec/arch/arm64/crashdump-arm64.h
+++ b/kexec/arch/arm64/crashdump-arm64.h
@@ -1,12 +1,22 @@
 /*
  * ARM64 crashdump.
+ *
+ * Copyright (c) 2014-2016 Linaro Limited
+ * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
  */
 
-#if !defined(CRASHDUMP_ARM64_H)
+#ifndef CRASHDUMP_ARM64_H
 #define CRASHDUMP_ARM64_H
 
 #include "kexec.h"
 
+#define CRASH_MAX_MEMORY_RANGES	32
+
 extern struct memory_ranges usablemem_rgns;
+extern struct memory_range crash_reserved_mem;
 
-#endif
+#endif /* CRASHDUMP_ARM64_H */
-- 
2.9.0


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

[PATCH v2 2/7] arm64: kdump: add elf core header segment

[AKASHI Takahiro]

Elf core header contains the information necessary for the coredump of
the 1st kernel, including its physcal memory layout as well as cpu register
states at the panic.
The segment is allocated inside the reserved memory of crash dump kernel.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
 kexec/arch/arm64/crashdump-arm64.c | 61 ++++++++++++++++++++++++++++++++++++++
 kexec/arch/arm64/crashdump-arm64.h |  3 ++
 kexec/arch/arm64/kexec-elf-arm64.c | 11 +++++++
 3 files changed, 75 insertions(+)

diff --git a/kexec/arch/arm64/crashdump-arm64.c b/kexec/arch/arm64/crashdump-arm64.c
index 5ab017c..3af01a3 100644
--- a/kexec/arch/arm64/crashdump-arm64.c
+++ b/kexec/arch/arm64/crashdump-arm64.c
@@ -41,6 +41,18 @@ struct memory_ranges usablemem_rgns = {
 	.ranges = &crash_reserved_mem,
 };
 
+struct memory_range elfcorehdr_mem;
+
+static struct crash_elf_info elf_info = {
+	.class		= ELFCLASS64,
+#if (__BYTE_ORDER == __LITTLE_ENDIAN)
+	.data		= ELFDATA2LSB,
+#else
+	.data		= ELFDATA2MSB,
+#endif
+	.machine	= EM_AARCH64,
+};
+
 /*
  * iomem_range_callback() - callback called for each iomem region
  * @data: not used
@@ -121,3 +133,52 @@ static int crash_get_memory_ranges(void)
 
 	return 0;
 }
+
+/*
+ * load_crashdump_segments() - load the elf core header
+ * @info: kexec info structure
+ *
+ * This function creates and loads an additional segment of elf core header
+ : which is used to construct /proc/vmcore on crash dump kernel.
+ *
+ * Return 0 in case of success and -1 in case of error.
+ */
+
+int load_crashdump_segments(struct kexec_info *info)
+{
+	unsigned long elfcorehdr;
+	unsigned long bufsz;
+	void *buf;
+	int err;
+
+	/*
+	 * First fetch all the memory (RAM) ranges that we are going to
+	 * pass to the crash dump kernel during panic.
+	 */
+
+	err = crash_get_memory_ranges();
+
+	if (err)
+		return err;
+
+	elf_info.page_offset = arm64_mem.page_offset;
+
+	err = crash_create_elf64_headers(info, &elf_info,
+			crash_memory_rgns.ranges, crash_memory_rgns.size,
+			&buf, &bufsz, ELF_CORE_HEADER_ALIGN);
+
+	if (err)
+		return err;
+
+	elfcorehdr = add_buffer_phys_virt(info, buf, bufsz, bufsz, 0,
+		crash_reserved_mem.start, crash_reserved_mem.end,
+		-1, 0);
+
+	elfcorehdr_mem.start = elfcorehdr;
+	elfcorehdr_mem.end = elfcorehdr + bufsz - 1;
+
+	dbgprintf("%s: elfcorehdr 0x%llx-0x%llx\n", __func__,
+			elfcorehdr_mem.start, elfcorehdr_mem.end);
+
+	return 0;
+}
diff --git a/kexec/arch/arm64/crashdump-arm64.h b/kexec/arch/arm64/crashdump-arm64.h
index 07a0ed0..da75a2d 100644
--- a/kexec/arch/arm64/crashdump-arm64.h
+++ b/kexec/arch/arm64/crashdump-arm64.h
@@ -18,5 +18,8 @@
 
 extern struct memory_ranges usablemem_rgns;
 extern struct memory_range crash_reserved_mem;
+extern struct memory_range elfcorehdr_mem;
+
+extern int load_crashdump_segments(struct kexec_info *info);
 
 #endif /* CRASHDUMP_ARM64_H */
diff --git a/kexec/arch/arm64/kexec-elf-arm64.c b/kexec/arch/arm64/kexec-elf-arm64.c
index fcac9bb..fdbf619 100644
--- a/kexec/arch/arm64/kexec-elf-arm64.c
+++ b/kexec/arch/arm64/kexec-elf-arm64.c
@@ -100,6 +100,17 @@ int elf_arm64_load(int argc, char **argv, const char *kernel_buf,
 		dbgprintf("%s: PE format:     %s\n", __func__,
 			(arm64_header_check_pe_sig(h) ? "yes" : "no"));
 
+		if (info->kexec_flags & KEXEC_ON_CRASH) {
+			/* create and initialize elf core header segment */
+			result = load_crashdump_segments(info);
+
+			if (result) {
+				fprintf(stderr,
+					"kexec: creating eflcorehdr failed.\n");
+				goto exit;
+			}
+		}
+
 		result = elf_exec_load(&ehdr, info);
 
 		if (result) {
-- 
2.9.0


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

[PATCH v2 3/7] arm64: kdump: set up kernel image segment

[AKASHI Takahiro]

On arm64, we can use the same kernel image as 1st kernel, but
we have to modify the entry point as well as segments' addresses
in the kernel's elf header in order to load them into correct places.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
 kexec/arch/arm64/crashdump-arm64.c | 23 +++++++++++++++++++++++
 kexec/arch/arm64/crashdump-arm64.h |  1 +
 kexec/arch/arm64/kexec-elf-arm64.c |  7 +++++++
 3 files changed, 31 insertions(+)

diff --git a/kexec/arch/arm64/crashdump-arm64.c b/kexec/arch/arm64/crashdump-arm64.c
index 3af01a3..e8e0489 100644
--- a/kexec/arch/arm64/crashdump-arm64.c
+++ b/kexec/arch/arm64/crashdump-arm64.c
@@ -182,3 +182,26 @@ int load_crashdump_segments(struct kexec_info *info)
 
 	return 0;
 }
+
+/*
+ * e_entry and p_paddr are actually in virtual address space.
+ * Those values will be translated to physcal addresses by
+ * using virt_to_phys().
+ * So let's get ready for later use so the memory base (phys_offset)
+ * will be correctly replaced with crash_reserved_mem.start.
+ */
+void modify_ehdr_for_crashdump(struct mem_ehdr *ehdr)
+{
+	struct mem_phdr *phdr;
+	int i;
+
+	ehdr->e_entry += - arm64_mem.phys_offset + crash_reserved_mem.start;
+
+	for (i = 0; i < ehdr->e_phnum; i++) {
+		phdr = &ehdr->e_phdr[i];
+		if (phdr->p_type != PT_LOAD)
+			continue;
+		phdr->p_paddr +=
+			(-arm64_mem.phys_offset + crash_reserved_mem.start);
+	}
+}
diff --git a/kexec/arch/arm64/crashdump-arm64.h b/kexec/arch/arm64/crashdump-arm64.h
index da75a2d..382f571 100644
--- a/kexec/arch/arm64/crashdump-arm64.h
+++ b/kexec/arch/arm64/crashdump-arm64.h
@@ -21,5 +21,6 @@ extern struct memory_range crash_reserved_mem;
 extern struct memory_range elfcorehdr_mem;
 
 extern int load_crashdump_segments(struct kexec_info *info);
+extern void modify_ehdr_for_crashdump(struct mem_ehdr *ehdr);
 
 #endif /* CRASHDUMP_ARM64_H */
diff --git a/kexec/arch/arm64/kexec-elf-arm64.c b/kexec/arch/arm64/kexec-elf-arm64.c
index fdbf619..63209e8 100644
--- a/kexec/arch/arm64/kexec-elf-arm64.c
+++ b/kexec/arch/arm64/kexec-elf-arm64.c
@@ -8,6 +8,7 @@
 #include <stdlib.h>
 #include <linux/elf.h>
 
+#include "crashdump-arm64.h"
 #include "kexec-arm64.h"
 #include "kexec-elf.h"
 #include "kexec-syscall.h"
@@ -109,6 +110,12 @@ int elf_arm64_load(int argc, char **argv, const char *kernel_buf,
 					"kexec: creating eflcorehdr failed.\n");
 				goto exit;
 			}
+
+			/*
+			 * offset addresses in order to fit vmlinux
+			 * (elf_exec) into crash kernel's memory
+			 */
+			modify_ehdr_for_crashdump(&ehdr);
 		}
 
 		result = elf_exec_load(&ehdr, info);
-- 
2.9.0


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

[PATCH v2 4/7] arm64: kdump: set up other segments

[AKASHI Takahiro]

We make sure that all the other segments, initrd and device-tree blob,
also be loaded into the reserved memory of crash dump kernel.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
 kexec/arch/arm64/kexec-arm64.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 940cddb..b9da85d 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -342,9 +342,15 @@ int arm64_load_other_segments(struct kexec_info *info,
 
 	/* Put the other segments after the image. */
 
-	image_base = arm64_mem.phys_offset + arm64_mem.text_offset;
-	hole_min = image_base + arm64_mem.image_size;
-	hole_max = ULONG_MAX;
+	if (info->kexec_flags & KEXEC_ON_CRASH) {
+		image_base = crash_reserved_mem.start + arm64_mem.text_offset;
+		hole_min = image_base + arm64_mem.image_size;
+		hole_max = crash_reserved_mem.end;
+	} else {
+		image_base = arm64_mem.phys_offset + arm64_mem.text_offset;
+		hole_min = image_base + arm64_mem.image_size;
+		hole_max = ULONG_MAX;
+	}
 
 	if (arm64_opts.initrd) {
 		initrd_buf = slurp_file(arm64_opts.initrd, &initrd_size);
-- 
2.9.0


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

[PATCH v2 5/7] arm64: kdump: add DT properties to crash dump kernel's dtb

[AKASHI Takahiro]

We pass the following properties to crash dump kernel:
linux,elfcorehdr: elf core header segment,
		  same as "elfcorehdr=" as on other archs
linxu,usable-memory-range: usable memory reserved for crash dump kernel

Then, we are ready to support kdump.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
 kexec/arch/arm64/kexec-arm64.c     | 76 +++++++++++++++++++++++++++++++++++---
 kexec/arch/arm64/kexec-elf-arm64.c |  5 ---
 2 files changed, 71 insertions(+), 10 deletions(-)

diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index b9da85d..83ad966 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -126,9 +126,6 @@ int arch_process_options(int argc, char **argv)
 		case OPT_INITRD:
 			arm64_opts.initrd = optarg;
 			break;
-		case OPT_PANIC:
-			die("load-panic (-p) not supported");
-			break;
 		default:
 			break; /* Ignore core and unknown options. */
 		}
@@ -281,8 +278,12 @@ on_success:
  * setup_2nd_dtb - Setup the 2nd stage kernel's dtb.
  */
 
-static int setup_2nd_dtb(struct dtb *dtb, char *command_line)
+static int setup_2nd_dtb(struct dtb *dtb, char *command_line, int on_crash)
 {
+	char *new_buf;
+	int new_size;
+	int nodeoffset;
+	uint64_t range[2];
 	int result;
 
 	result = fdt_check_header(dtb->buf);
@@ -294,8 +295,72 @@ static int setup_2nd_dtb(struct dtb *dtb, char *command_line)
 
 	result = set_bootargs(dtb, command_line);
 
+	/* remove those anyway */
+	nodeoffset = fdt_path_offset(dtb->buf, "/chosen");
+	fdt_delprop(dtb->buf, nodeoffset, "linux,crashkernel-base");
+	fdt_delprop(dtb->buf, nodeoffset, "linux,crashkernel-size");
+
+	if (on_crash) {
+		nodeoffset = fdt_path_offset(dtb->buf, "/chosen");
+		fdt_delprop(dtb->buf, nodeoffset, "linux,elfcorehdr");
+		fdt_delprop(dtb->buf, nodeoffset, "linux,usable-memory-range");
+		new_size = fdt_totalsize(dtb->buf)
+			+ 2 * (sizeof(struct fdt_property)
+					+ FDT_TAGALIGN(sizeof(range)))
+			+ strlen("linux,elfcorehdr") + 1
+			+ strlen("linux,usable-memory-range") + 1;
+
+		new_buf = xmalloc(new_size);
+		result = fdt_open_into(dtb->buf, new_buf, new_size);
+		if (result) {
+			dbgprintf("%s: fdt_open_into failed: %s\n", __func__,
+				fdt_strerror(result));
+			result = -ENOSPC;
+			goto on_error;
+		}
+
+		range[0] = cpu_to_be64(elfcorehdr_mem.start);
+		range[1] = cpu_to_be64(elfcorehdr_mem.end
+				- elfcorehdr_mem.start + 1);
+		nodeoffset = fdt_path_offset(new_buf, "/chosen");
+		result = fdt_setprop(new_buf, nodeoffset, "linux,elfcorehdr",
+				(void *)range, sizeof(range));
+		if (result) {
+			dbgprintf("%s: fdt_setprop failed: %s\n", __func__,
+				fdt_strerror(result));
+			result = -EINVAL;
+			goto on_error;
+		}
+
+		range[0] = cpu_to_be64(crash_reserved_mem.start);
+		range[1] = cpu_to_be64(crash_reserved_mem.end
+				- crash_reserved_mem.start + 1);
+		nodeoffset = fdt_path_offset(new_buf, "/chosen");
+		result = fdt_setprop(new_buf, nodeoffset,
+				"linux,usable-memory-range",
+				(void *)range, sizeof(range));
+		if (result) {
+			dbgprintf("%s: fdt_setprop failed: %s\n", __func__,
+				fdt_strerror(result));
+			result = -EINVAL;
+			goto on_error;
+		}
+
+		fdt_pack(new_buf);
+		dtb->buf = new_buf;
+		dtb->size = fdt_totalsize(new_buf);
+	}
+
 	dump_reservemap(dtb);
 
+
+	return result;
+
+on_error:
+	fprintf(stderr, "kexec: %s failed.\n", __func__);
+	if (new_buf)
+		free(new_buf);
+
 	return result;
 }
 
@@ -335,7 +400,8 @@ int arm64_load_other_segments(struct kexec_info *info,
 		}
 	}
 
-	result = setup_2nd_dtb(&dtb, command_line);
+	result = setup_2nd_dtb(&dtb, command_line,
+			info->kexec_flags & KEXEC_ON_CRASH);
 
 	if (result)
 		return -EFAILED;
diff --git a/kexec/arch/arm64/kexec-elf-arm64.c b/kexec/arch/arm64/kexec-elf-arm64.c
index 63209e8..e20ab3e 100644
--- a/kexec/arch/arm64/kexec-elf-arm64.c
+++ b/kexec/arch/arm64/kexec-elf-arm64.c
@@ -44,11 +44,6 @@ int elf_arm64_load(int argc, char **argv, const char *kernel_buf,
 	int result;
 	int i;
 
-	if (info->kexec_flags & KEXEC_ON_CRASH) {
-		fprintf(stderr, "kexec: kdump not yet supported on arm64\n");
-		return -EFAILED;
-	}
-
 	result = build_elf_exec_info(kernel_buf, kernel_size, &ehdr, 0);
 
 	if (result < 0) {
-- 
2.9.0


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

[PATCH v2 6/7] kexec: generalize and rename get_kernel_stext_sym()

[AKASHI Takahiro]

From: Pratyush Anand <panand@redhat.com>

get_kernel_stext_sym() has been defined for both arm and i386. Other
architecture might need some other kernel symbol address. Therefore rewrite
this function as generic function to get any kernel symbol address.

More over, kallsyms is not arch specific representation, therefore have
common function for all arches.

Signed-off-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
 kexec/arch/arm/crashdump-arm.c  | 40 +---------------------------------------
 kexec/arch/i386/crashdump-x86.c | 32 +-------------------------------
 kexec/crashdump.c               | 37 +++++++++++++++++++++++++++++++++++++
 kexec/crashdump.h               |  1 +
 4 files changed, 40 insertions(+), 70 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 4a89b5e..2bc898b 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -73,48 +73,10 @@ static struct crash_elf_info elf_info = {
 
 extern unsigned long long user_page_offset;
 
-/* Retrieve kernel _stext symbol virtual address from /proc/kallsyms */
-static unsigned long long get_kernel_stext_sym(void)
-{
-	const char *kallsyms = "/proc/kallsyms";
-	const char *stext = "_stext";
-	char sym[128];
-	char line[128];
-	FILE *fp;
-	unsigned long long vaddr = 0;
-	char type;
-
-	fp = fopen(kallsyms, "r");
-	if (!fp) {
-		fprintf(stderr, "Cannot open %s\n", kallsyms);
-		return 0;
-	}
-
-	while(fgets(line, sizeof(line), fp) != NULL) {
-		unsigned long long addr;
-
-		if (sscanf(line, "%Lx %c %s", &addr, &type, sym) != 3)
-			continue;
-
-		if (strcmp(sym, stext) == 0) {
-			dbgprintf("kernel symbol %s vaddr = %#llx\n", stext, addr);
-			vaddr = addr;
-			break;
-		}
-	}
-
-	fclose(fp);
-
-	if (vaddr == 0)
-		fprintf(stderr, "Cannot get kernel %s symbol address\n", stext);
-
-	return vaddr;
-}
-
 static int get_kernel_page_offset(struct kexec_info *info,
 		struct crash_elf_info *elf_info)
 {
-	unsigned long long stext_sym_addr = get_kernel_stext_sym();
+	unsigned long long stext_sym_addr = get_kernel_sym("stext");
 	if (stext_sym_addr == 0) {
 		if (user_page_offset != (-1ULL)) {
 			elf_info->page_offset = user_page_offset;
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index bbc0f35..664eb3b 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -102,36 +102,6 @@ static int get_kernel_paddr(struct kexec_info *UNUSED(info),
 	return -1;
 }
 
-/* Retrieve kernel _stext symbol virtual address from /proc/kallsyms */
-static unsigned long long get_kernel_stext_sym(void)
-{
-	const char *kallsyms = "/proc/kallsyms";
-	const char *stext = "_stext";
-	char sym[128];
-	char line[128];
-	FILE *fp;
-	unsigned long long vaddr;
-	char type;
-
-	fp = fopen(kallsyms, "r");
-	if (!fp) {
-		fprintf(stderr, "Cannot open %s\n", kallsyms);
-		return 0;
-	}
-
-	while(fgets(line, sizeof(line), fp) != NULL) {
-		if (sscanf(line, "%Lx %c %s", &vaddr, &type, sym) != 3)
-			continue;
-		if (strcmp(sym, stext) == 0) {
-			dbgprintf("kernel symbol %s vaddr = %16llx\n", stext, vaddr);
-			return vaddr;
-		}
-	}
-
-	fprintf(stderr, "Cannot get kernel %s symbol address\n", stext);
-	return 0;
-}
-
 /* Retrieve info regarding virtual address kernel has been compiled for and
  * size of the kernel from /proc/kcore. Current /proc/kcore parsing from
  * from kexec-tools fails because of malformed elf notes. A kernel patch has
@@ -182,7 +152,7 @@ static int get_kernel_vaddr_and_size(struct kexec_info *UNUSED(info),
 
 	/* Traverse through the Elf headers and find the region where
 	 * _stext symbol is located in. That's where kernel is mapped */
-	stext_sym = get_kernel_stext_sym();
+	stext_sym = get_kernel_sym("stext");
 	for(phdr = ehdr.e_phdr; stext_sym && phdr != end_phdr; phdr++) {
 		if (phdr->p_type == PT_LOAD) {
 			unsigned long long saddr = phdr->p_vaddr;
diff --git a/kexec/crashdump.c b/kexec/crashdump.c
index 15c1105..3688965 100644
--- a/kexec/crashdump.c
+++ b/kexec/crashdump.c
@@ -157,3 +157,40 @@ int get_kernel_vmcoreinfo(uint64_t *addr, uint64_t *len)
 {
 	return get_vmcoreinfo("/sys/kernel/vmcoreinfo", addr, len);
 }
+
+/* Retrieve kernel symbol virtual address from /proc/kallsyms */
+unsigned long long get_kernel_sym(const char *text)
+{
+	const char *kallsyms = "/proc/kallsyms";
+	char sym[128];
+	char line[128];
+	FILE *fp;
+	unsigned long long vaddr = 0;
+	char type;
+
+	fp = fopen(kallsyms, "r");
+	if (!fp) {
+		fprintf(stderr, "Cannot open %s\n", kallsyms);
+		return 0;
+	}
+
+	while(fgets(line, sizeof(line), fp) != NULL) {
+		unsigned long long addr;
+
+		if (sscanf(line, "%Lx %c %s", &addr, &type, sym) != 3)
+			continue;
+
+		if (strcmp(sym, text) == 0) {
+			dbgprintf("kernel symbol %s vaddr = %#llx\n", text, addr);
+			vaddr = addr;
+			break;
+		}
+	}
+
+	fclose(fp);
+
+	if (vaddr == 0)
+		fprintf(stderr, "Cannot get kernel %s symbol address\n", text);
+
+	return vaddr;
+}
diff --git a/kexec/crashdump.h b/kexec/crashdump.h
index 96219a8..887fdb7 100644
--- a/kexec/crashdump.h
+++ b/kexec/crashdump.h
@@ -5,6 +5,7 @@ int get_crashkernel_region(uint64_t *start, uint64_t *end);
 extern int get_crash_notes_per_cpu(int cpu, uint64_t *addr, uint64_t *len);
 extern int get_kernel_vmcoreinfo(uint64_t *addr, uint64_t *len);
 extern int get_xen_vmcoreinfo(uint64_t *addr, uint64_t *len);
+extern unsigned long long get_kernel_sym(const char *text);
 
 /* Need to find a better way to determine per cpu notes section size. */
 #define MAX_NOTE_BYTES		1024
-- 
2.9.0


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

[PATCH v2 7/7] arm64: kdump: Add support for binary image files

[AKASHI Takahiro]

From: Pratyush Anand <panand@redhat.com>

This patch adds support to use binary image ie arch/arm64/boot/Image with
kdump.

Binary image does not have sufficient knowledge to extract page offset
information, which is needed by kexec tool (specially vmcore-dmesg). Use a
new command parameter --page-offset, so that user can provide page offset
information for linear mapping.

Signed-off-by: Pratyush Anand <panand@redhat.com>
[takahiro.akashi@linaro.org: a bit reworked]
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
 kexec/arch/arm64/include/arch/options.h |  8 +++--
 kexec/arch/arm64/kexec-arm64.c          |  5 +++
 kexec/arch/arm64/kexec-image-arm64.c    | 60 +++++++++++++++++++++++++++++----
 3 files changed, 65 insertions(+), 8 deletions(-)

diff --git a/kexec/arch/arm64/include/arch/options.h b/kexec/arch/arm64/include/arch/options.h
index a17d933..3283985 100644
--- a/kexec/arch/arm64/include/arch/options.h
+++ b/kexec/arch/arm64/include/arch/options.h
@@ -5,7 +5,8 @@
 #define OPT_DTB			((OPT_MAX)+1)
 #define OPT_INITRD		((OPT_MAX)+2)
 #define OPT_REUSE_CMDLINE	((OPT_MAX)+3)
-#define OPT_ARCH_MAX		((OPT_MAX)+4)
+#define OPT_PAGE_OFFSET		((OPT_MAX)+4)
+#define OPT_ARCH_MAX		((OPT_MAX)+5)
 
 #define KEXEC_ARCH_OPTIONS \
 	KEXEC_OPTIONS \
@@ -15,6 +16,7 @@
 	{ "initrd",        1, NULL, OPT_INITRD }, \
 	{ "ramdisk",       1, NULL, OPT_INITRD }, \
 	{ "reuse-cmdline", 0, NULL, OPT_REUSE_CMDLINE }, \
+	{ "page-offset",   1, NULL, OPT_PAGE_OFFSET }, \
 
 #define KEXEC_ARCH_OPT_STR KEXEC_OPT_STR /* Only accept long arch options. */
 #define KEXEC_ALL_OPTIONS KEXEC_ARCH_OPTIONS
@@ -26,12 +28,14 @@ static const char arm64_opts_usage[] __attribute__ ((unused)) =
 "     --dtb=FILE            Use FILE as the device tree blob.\n"
 "     --initrd=FILE         Use FILE as the kernel initial ramdisk.\n"
 "     --ramdisk=FILE        Use FILE as the kernel initial ramdisk.\n"
-"     --reuse-cmdline       Use kernel command line from running system.\n";
+"     --reuse-cmdline       Use kernel command line from running system.\n"
+"     --page-offset=OFFSET  Use OFFSET as current kernel's page_offset value.\n";
 
 struct arm64_opts {
 	const char *command_line;
 	const char *dtb;
 	const char *initrd;
+	uint64_t page_offset;
 };
 
 extern struct arm64_opts arm64_opts;
diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 83ad966..959f4bb 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -126,6 +126,9 @@ int arch_process_options(int argc, char **argv)
 		case OPT_INITRD:
 			arm64_opts.initrd = optarg;
 			break;
+		case OPT_PAGE_OFFSET:
+			arm64_opts.page_offset = strtoull(optarg, NULL, 0);
+			break;
 		default:
 			break; /* Ignore core and unknown options. */
 		}
@@ -138,6 +141,8 @@ int arch_process_options(int argc, char **argv)
 	dbgprintf("%s:%d: initrd: %s\n", __func__, __LINE__,
 		arm64_opts.initrd);
 	dbgprintf("%s:%d: dtb: %s\n", __func__, __LINE__, arm64_opts.dtb);
+	dbgprintf("%s:%d: page_offset: %016lx\n", __func__, __LINE__,
+						arm64_opts.page_offset);
 
 	return 0;
 }
diff --git a/kexec/arch/arm64/kexec-image-arm64.c b/kexec/arch/arm64/kexec-image-arm64.c
index cad7c73..90e8a87 100644
--- a/kexec/arch/arm64/kexec-image-arm64.c
+++ b/kexec/arch/arm64/kexec-image-arm64.c
@@ -4,9 +4,15 @@
 
 #define _GNU_SOURCE
 
-#include <errno.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <arch/options.h>
 
+#include "../../kexec.h"
+#include "../../crashdump.h"
+#include "crashdump-arm64.h"
 #include "kexec-arm64.h"
+#include "kexec-syscall.h"
 
 int image_arm64_probe(const char *kernel_buf, off_t kernel_size)
 {
@@ -27,16 +33,44 @@ int image_arm64_probe(const char *kernel_buf, off_t kernel_size)
 	return 0;
 }
 
+static uint64_t get_kernel_page_offset(void)
+{
+	uint64_t text_page_offset;
+
+	/* 2MB-aligned */
+	text_page_offset = get_kernel_sym("_text") & (UINT64_MAX << 21);
+
+	if (arm64_opts.page_offset) {
+		if (text_page_offset != arm64_opts.page_offset)
+			dbgprintf("%s: User page offset %lx did not match with text page offset %lx\n", __func__,
+				arm64_opts.page_offset, text_page_offset);
+		return arm64_opts.page_offset;
+	} else if (text_page_offset) {
+		dbgprintf("%s: text page offset is %lx\n", __func__,
+						text_page_offset);
+		return text_page_offset;
+	} else {
+		return UINT64_MAX;
+	}
+}
+
 int image_arm64_load(int argc, char **argv, const char *kernel_buf,
 	off_t kernel_size, struct kexec_info *info)
 {
 	const struct arm64_image_header *h;
-	unsigned long image_base;
+	uint64_t image_base;
+	int result;
 
 	h = (const struct arm64_image_header *)(kernel_buf);
 
 	if (arm64_process_image_header(h))
-		return -EINVAL;
+		return -1;
+
+	arm64_mem.page_offset = get_kernel_page_offset();
+	if (arm64_mem.page_offset == UINT64_MAX) {
+		fprintf(stderr, "kexec: page_offset is not specified\n");
+		return -1;
+	}
 
 	dbgprintf("%s: text_offset:   %016lx\n", __func__,
 		arm64_mem.text_offset);
@@ -44,11 +78,24 @@ int image_arm64_load(int argc, char **argv, const char *kernel_buf,
 		arm64_mem.image_size);
 	dbgprintf("%s: phys_offset:   %016lx\n", __func__,
 		arm64_mem.phys_offset);
+	dbgprintf("%s: page_offset:   %016lx\n", __func__,
+		arm64_mem.page_offset);
 	dbgprintf("%s: PE format:     %s\n", __func__,
 		(arm64_header_check_pe_sig(h) ? "yes" : "no"));
 
-	image_base = get_phys_offset() + arm64_mem.text_offset;
-	
+	if (info->kexec_flags & KEXEC_ON_CRASH) {
+		result = load_crashdump_segments(info);
+
+		if (result) {
+			fprintf(stderr,
+				"kexec: load crashdump segments failed.\n");
+			return -1;
+		}
+		image_base = crash_reserved_mem.start + arm64_mem.text_offset;
+	} else {
+		image_base = get_phys_offset() + arm64_mem.text_offset;
+	}
+
 	add_segment_phys_virt(info, kernel_buf, kernel_size, image_base,
 		arm64_mem.image_size, 0);
 
@@ -59,5 +106,6 @@ void image_arm64_usage(void)
 {
 	printf(
 "     An ARM64 binary image, compressed or not, big or little endian.\n"
-"     Typically an Image, Image.gz or Image.lzma file.\n\n");
+"     Typically an Image, Image.gz or Image.lzma file.\n"
+"     --page-offset         Kernel page-offset for binary image load.\n\n");
 }
-- 
2.9.0


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

Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support

[Pratyush Anand]

Hi Geoff and Takahiro,

I am having some issues with kexec+kdump while working with Seattle platform. On
top level, kernel crashes in copy_oldmem_page(), because it gets wrong offset
for log_buf during vmcore-dmesg save.

Here is the detail:

(1) From /proc/iomem, these are the "System RAM" Components:

8000000000-8001e7ffff : System RAM
8001e80000-83ff17ffff : System RAM
        8002080000-8002b3ffff : Kernel code
        8002c40000-800348ffff : Kernel data
        807fe00000-80ffdfffff : Crash kernel
83ff180000-83ff1cffff : System RAM
83ff1d0000-83ff21ffff : System RAM
83ff220000-83ffe4ffff : System RAM
83ffe50000-83ffffffff : System RAM

(2) From kexec-tools debug print I see following:
elf_arm64_load: e_entry:       fffffc0008080000 -> 0000008000080000
elf_arm64_load: p_vaddr:       fffffc0008080000 -> 0000008000080000
elf_arm64_load: header_offset: 0000000000000000
elf_arm64_load: text_offset:   0000000000080000
elf_arm64_load: image_size:    0000000001410000
elf_arm64_load: phys_offset:   0000008000000000
elf_arm64_load: page_offset:   fffffc0008000000

I understand that "Kernel Code start physical address" 0x8002080000 should map
to e_entry vaddr which is 0xfffffc0008080000. However, kexec-tools debug print
shows that e_entry vaddr maps to PA 8000080000 which seems wrong.

(3) further page_offset (or vp_offset in your new code) is calculated
as:arm64_mem.page_offset = ehdr.e_entry - arm64_mem.text_offset;

Current calcualtion of page_offset leads to wrong configuration of VA of alls
PT_LOAD (see below). Ultimately, this is also leading to kernel crash during
vmcore-dmesg and vmcore save operations, because we pass an offset to pread()
system call which maps to wrong physical address.

Elf header: p_type = 1, p_offset = 0x8000000000 p_paddr = 0x8000000000
p_vaddr = 0xfffffc0008000000 p_filesz = 0x1e80000 p_memsz = 0x1e80000
[0xfffffc0008000000 should be mapping to 0x8002000000 and not 0x8000000000]
Elf header: p_type = 1, p_offset = 0x8001e80000 p_paddr = 0x8001e80000
p_vaddr = 0xfffffc0009e80000 p_filesz = 0x7df80000 p_memsz = 0x7df80000
Elf header: p_type = 1, p_offset = 0x80ffe00000 p_paddr = 0x80ffe00000
p_vaddr = 0xfffffc0107e00000 p_filesz = 0x2ff380000 p_memsz = 0x2ff380000
Elf header: p_type = 1, p_offset = 0x83ff180000 p_paddr = 0x83ff180000
p_vaddr = 0xfffffc0407180000 p_filesz = 0x50000 p_memsz = 0x50000
Elf header: p_type = 1, p_offset = 0x83ff1d0000 p_paddr = 0x83ff1d0000
p_vaddr = 0xfffffc04071d0000 p_filesz = 0x50000 p_memsz = 0x50000
Elf header: p_type = 1, p_offset = 0x83ff220000 p_paddr = 0x83ff220000
p_vaddr = 0xfffffc0407220000 p_filesz = 0xc30000 p_memsz = 0xc30000
Elf header: p_type = 1, p_offset = 0x83ffe50000 p_paddr = 0x83ffe50000
p_vaddr = 0xfffffc0407e50000 p_filesz = 0x1b0000 p_memsz = 0x1b0000

May be following should be better.
arm64_mem.page_offset = ehdr.e_entry - "kernel Code Start PA" + phys_offset.

(4) Further more,  vmcore must have first PT_LOAD segment as kernel text area.
In this platform we have first "System RAM" area as 8000000000-8001e7ffff which
is not matching to "Kernel code" area. Therefore, we should provide support of
"kern_size" so that first PT_LOAD is kernel text area.

~Pratyush
On 09/08/2016:11:00:25 AM, AKASHI Takahiro wrote:
> My kernel patches of kdump suport on arm64 are currently under reviews [1].
> 
> This patchset is synced with them (v24) and provides necessary changes for
> kexec-tools. It should be applied on top of Geoff's kexec-tools patches
> v3[2] along with a bugfix[3].
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447597.html
> [2] http://lists.infradead.org/pipermail/kexec/2016-August/016768.html
> [3] http://lists.infradead.org/pipermail/kexec/2016-July/016664.html
> 
> Changes for v2:
>  - Trim a temoprary buffer in setup_2nd_dtb()
>  - Add patch#6("kexec: generalize and rename get_kernel_stext_sym()")
>  - Update patch#7 from Pratyush
>    (re-worked by akashi)
> 
> AKASHI Takahiro (5):
>   arm64: kdump: identify memory regions
>   arm64: kdump: add elf core header segment
>   arm64: kdump: set up kernel image segment
>   arm64: kdump: set up other segments
>   arm64: kdump: add DT properties to crash dump kernel's dtb
> 
> Pratyush Anand (2):
>   kexec: generalize and rename get_kernel_stext_sym()
>   arm64: kdump: Add support for binary image files
> 
>  kexec/arch/arm/crashdump-arm.c          |  40 +------
>  kexec/arch/arm64/Makefile               |   2 +
>  kexec/arch/arm64/crashdump-arm64.c      | 188 +++++++++++++++++++++++++++++++-
>  kexec/arch/arm64/crashdump-arm64.h      |  18 ++-
>  kexec/arch/arm64/include/arch/options.h |   8 +-
>  kexec/arch/arm64/kexec-arm64.c          |  91 ++++++++++++++--
>  kexec/arch/arm64/kexec-elf-arm64.c      |  23 +++-
>  kexec/arch/arm64/kexec-image-arm64.c    |  60 +++++++++-
>  kexec/arch/i386/crashdump-x86.c         |  32 +-----
>  kexec/crashdump.c                       |  37 +++++++
>  kexec/crashdump.h                       |   1 +
>  11 files changed, 407 insertions(+), 93 deletions(-)
> 
> -- 
> 2.9.0

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

Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support

[AKASHI Takahiro]

Pratyush, Geoff

# If I had Seattle, I could debug easily :)

On Wed, Aug 10, 2016 at 11:26:48PM +0530, Pratyush Anand wrote:
> Hi Geoff and Takahiro,
> 
> I am having some issues with kexec+kdump while working with Seattle platform. On
> top level, kernel crashes in copy_oldmem_page(), because it gets wrong offset
> for log_buf during vmcore-dmesg save.
> 
> Here is the detail:
> 
> (1) From /proc/iomem, these are the "System RAM" Components:
> 
> 8000000000-8001e7ffff : System RAM
> 8001e80000-83ff17ffff : System RAM
>         8002080000-8002b3ffff : Kernel code
>         8002c40000-800348ffff : Kernel data
>         807fe00000-80ffdfffff : Crash kernel
> 83ff180000-83ff1cffff : System RAM
> 83ff1d0000-83ff21ffff : System RAM
> 83ff220000-83ffe4ffff : System RAM
> 83ffe50000-83ffffffff : System RAM
> 
> (2) From kexec-tools debug print I see following:
> elf_arm64_load: e_entry:       fffffc0008080000 -> 0000008000080000
> elf_arm64_load: p_vaddr:       fffffc0008080000 -> 0000008000080000
> elf_arm64_load: header_offset: 0000000000000000
> elf_arm64_load: text_offset:   0000000000080000
> elf_arm64_load: image_size:    0000000001410000
> elf_arm64_load: phys_offset:   0000008000000000
> elf_arm64_load: page_offset:   fffffc0008000000
> 
> I understand that "Kernel Code start physical address" 0x8002080000 should map
> to e_entry vaddr which is 0xfffffc0008080000. However, kexec-tools debug print
> shows that e_entry vaddr maps to PA 8000080000 which seems wrong.

Obviously, virt_to_phys() is wrong.
As you know, we have to calculate virt_to_phys() in a different way
depending on whether the vaddr is greater than PAGE_OFFSET (linear mapping)
or not (kernel image mapping).
See the kernel's include/asm/memory.h.

Geoff, please update this function.

> (3) further page_offset (or vp_offset in your new code) is calculated
> as:arm64_mem.page_offset = ehdr.e_entry - arm64_mem.text_offset;
> 
> Current calcualtion of page_offset leads to wrong configuration of VA of alls
> PT_LOAD (see below). Ultimately, this is also leading to kernel crash during
> vmcore-dmesg and vmcore save operations, because we pass an offset to pread()
> system call which maps to wrong physical address.
> 
> Elf header: p_type = 1, p_offset = 0x8000000000 p_paddr = 0x8000000000
> p_vaddr = 0xfffffc0008000000 p_filesz = 0x1e80000 p_memsz = 0x1e80000
> [0xfffffc0008000000 should be mapping to 0x8002000000 and not 0x8000000000]

I think that your comment here is wrong.
This program header indicates the first memory region in the 1st kernel,
that is,
    8000000000-8001e7ffff : System RAM

Is this region really part of "System RAM?"
Can you show me the "Virtual kernel memory layout" in dmesg?

> Elf header: p_type = 1, p_offset = 0x8001e80000 p_paddr = 0x8001e80000
> p_vaddr = 0xfffffc0009e80000 p_filesz = 0x7df80000 p_memsz = 0x7df80000
> Elf header: p_type = 1, p_offset = 0x80ffe00000 p_paddr = 0x80ffe00000
> p_vaddr = 0xfffffc0107e00000 p_filesz = 0x2ff380000 p_memsz = 0x2ff380000
> Elf header: p_type = 1, p_offset = 0x83ff180000 p_paddr = 0x83ff180000
> p_vaddr = 0xfffffc0407180000 p_filesz = 0x50000 p_memsz = 0x50000
> Elf header: p_type = 1, p_offset = 0x83ff1d0000 p_paddr = 0x83ff1d0000
> p_vaddr = 0xfffffc04071d0000 p_filesz = 0x50000 p_memsz = 0x50000
> Elf header: p_type = 1, p_offset = 0x83ff220000 p_paddr = 0x83ff220000
> p_vaddr = 0xfffffc0407220000 p_filesz = 0xc30000 p_memsz = 0xc30000
> Elf header: p_type = 1, p_offset = 0x83ffe50000 p_paddr = 0x83ffe50000
> p_vaddr = 0xfffffc0407e50000 p_filesz = 0x1b0000 p_memsz = 0x1b0000
> 
> May be following should be better.
> arm64_mem.page_offset = ehdr.e_entry - "kernel Code Start PA" + phys_offset.

Probably not.

> (4) Further more,  vmcore must have first PT_LOAD segment as kernel text area.

Which part of the code do you think depends on this assumption?

Thanks,
-Takahiro AKASHI

> In this platform we have first "System RAM" area as 8000000000-8001e7ffff which
> is not matching to "Kernel code" area. Therefore, we should provide support of
> "kern_size" so that first PT_LOAD is kernel text area.
> 
> ~Pratyush
> On 09/08/2016:11:00:25 AM, AKASHI Takahiro wrote:
> > My kernel patches of kdump suport on arm64 are currently under reviews [1].
> > 
> > This patchset is synced with them (v24) and provides necessary changes for
> > kexec-tools. It should be applied on top of Geoff's kexec-tools patches
> > v3[2] along with a bugfix[3].
> > 
> > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447597.html
> > [2] http://lists.infradead.org/pipermail/kexec/2016-August/016768.html
> > [3] http://lists.infradead.org/pipermail/kexec/2016-July/016664.html
> > 
> > Changes for v2:
> >  - Trim a temoprary buffer in setup_2nd_dtb()
> >  - Add patch#6("kexec: generalize and rename get_kernel_stext_sym()")
> >  - Update patch#7 from Pratyush
> >    (re-worked by akashi)
> > 
> > AKASHI Takahiro (5):
> >   arm64: kdump: identify memory regions
> >   arm64: kdump: add elf core header segment
> >   arm64: kdump: set up kernel image segment
> >   arm64: kdump: set up other segments
> >   arm64: kdump: add DT properties to crash dump kernel's dtb
> > 
> > Pratyush Anand (2):
> >   kexec: generalize and rename get_kernel_stext_sym()
> >   arm64: kdump: Add support for binary image files
> > 
> >  kexec/arch/arm/crashdump-arm.c          |  40 +------
> >  kexec/arch/arm64/Makefile               |   2 +
> >  kexec/arch/arm64/crashdump-arm64.c      | 188 +++++++++++++++++++++++++++++++-
> >  kexec/arch/arm64/crashdump-arm64.h      |  18 ++-
> >  kexec/arch/arm64/include/arch/options.h |   8 +-
> >  kexec/arch/arm64/kexec-arm64.c          |  91 ++++++++++++++--
> >  kexec/arch/arm64/kexec-elf-arm64.c      |  23 +++-
> >  kexec/arch/arm64/kexec-image-arm64.c    |  60 +++++++++-
> >  kexec/arch/i386/crashdump-x86.c         |  32 +-----
> >  kexec/crashdump.c                       |  37 +++++++
> >  kexec/crashdump.h                       |   1 +
> >  11 files changed, 407 insertions(+), 93 deletions(-)
> > 
> > -- 
> > 2.9.0

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

Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support

[Pratyush Anand]

On 19/08/2016:04:19:31 PM, AKASHI Takahiro wrote:
> Pratyush, Geoff
> 
> # If I had Seattle, I could debug easily :)
> 
> On Wed, Aug 10, 2016 at 11:26:48PM +0530, Pratyush Anand wrote:
> > Hi Geoff and Takahiro,
> > 
> > I am having some issues with kexec+kdump while working with Seattle platform. On
> > top level, kernel crashes in copy_oldmem_page(), because it gets wrong offset
> > for log_buf during vmcore-dmesg save.
> > 
> > Here is the detail:
> > 
> > (1) From /proc/iomem, these are the "System RAM" Components:
> > 
> > 8000000000-8001e7ffff : System RAM
> > 8001e80000-83ff17ffff : System RAM
> >         8002080000-8002b3ffff : Kernel code
> >         8002c40000-800348ffff : Kernel data
> >         807fe00000-80ffdfffff : Crash kernel
> > 83ff180000-83ff1cffff : System RAM
> > 83ff1d0000-83ff21ffff : System RAM
> > 83ff220000-83ffe4ffff : System RAM
> > 83ffe50000-83ffffffff : System RAM
> > 
> > (2) From kexec-tools debug print I see following:
> > elf_arm64_load: e_entry:       fffffc0008080000 -> 0000008000080000
> > elf_arm64_load: p_vaddr:       fffffc0008080000 -> 0000008000080000
> > elf_arm64_load: header_offset: 0000000000000000
> > elf_arm64_load: text_offset:   0000000000080000
> > elf_arm64_load: image_size:    0000000001410000
> > elf_arm64_load: phys_offset:   0000008000000000
> > elf_arm64_load: page_offset:   fffffc0008000000
> > 
> > I understand that "Kernel Code start physical address" 0x8002080000 should map
> > to e_entry vaddr which is 0xfffffc0008080000. However, kexec-tools debug print
> > shows that e_entry vaddr maps to PA 8000080000 which seems wrong.
> 
> Obviously, virt_to_phys() is wrong.
> As you know, we have to calculate virt_to_phys() in a different way
> depending on whether the vaddr is greater than PAGE_OFFSET (linear mapping)
> or not (kernel image mapping).
> See the kernel's include/asm/memory.h.
> 
> Geoff, please update this function.
> 
> > (3) further page_offset (or vp_offset in your new code) is calculated
> > as:arm64_mem.page_offset = ehdr.e_entry - arm64_mem.text_offset;
> > 
> > Current calcualtion of page_offset leads to wrong configuration of VA of alls
> > PT_LOAD (see below). Ultimately, this is also leading to kernel crash during
> > vmcore-dmesg and vmcore save operations, because we pass an offset to pread()
> > system call which maps to wrong physical address.
> > 
> > Elf header: p_type = 1, p_offset = 0x8000000000 p_paddr = 0x8000000000
> > p_vaddr = 0xfffffc0008000000 p_filesz = 0x1e80000 p_memsz = 0x1e80000
> > [0xfffffc0008000000 should be mapping to 0x8002000000 and not 0x8000000000]
> 
> I think that your comment here is wrong.
> This program header indicates the first memory region in the 1st kernel,
> that is,
>     8000000000-8001e7ffff : System RAM
> 
> Is this region really part of "System RAM?"
> Can you show me the "Virtual kernel memory layout" in dmesg?

[    0.000000] Virtual kernel memory layout:
[    0.000000]     modules : 0xfffffc0000000000 - 0xfffffc0008000000   (   128 MB)
[    0.000000]     vmalloc : 0xfffffc0008000000 - 0xfffffdff5fff0000   (  2045 GB)
[    0.000000]       .text : 0xfffffc0008080000 - 0xfffffc00087d0000   (  7488 KB)
[    0.000000]     .rodata : 0xfffffc00087d0000 - 0xfffffc0008b40000   (  3520 KB)
[    0.000000]       .init : 0xfffffc0008b40000 - 0xfffffc0008c40000   (  1024 KB)
[    0.000000]       .data : 0xfffffc0008c40000 - 0xfffffc0008d93e00   (  1360 KB)
[    0.000000]        .bss : 0xfffffc0008d93e00 - 0xfffffc0009438248   (  6802 KB)
[    0.000000]     fixed   : 0xfffffdff7e7d0000 - 0xfffffdff7ec00000   (  4288 KB)
[    0.000000]     PCI I/O : 0xfffffdff7ee00000 - 0xfffffdff7fe00000   (    16 MB)
[    0.000000]     vmemmap : 0xfffffdff80000000 - 0xfffffe0000000000   (     2 GB maximum)
[    0.000000]               0xfffffdff80000000 - 0xfffffdff81000000   (    16 MB actual)
[    0.000000]     memory  : 0xfffffe0000000000 - 0xfffffe0400000000   ( 16384 MB)

> 
> > Elf header: p_type = 1, p_offset = 0x8001e80000 p_paddr = 0x8001e80000
> > p_vaddr = 0xfffffc0009e80000 p_filesz = 0x7df80000 p_memsz = 0x7df80000
> > Elf header: p_type = 1, p_offset = 0x80ffe00000 p_paddr = 0x80ffe00000
> > p_vaddr = 0xfffffc0107e00000 p_filesz = 0x2ff380000 p_memsz = 0x2ff380000
> > Elf header: p_type = 1, p_offset = 0x83ff180000 p_paddr = 0x83ff180000
> > p_vaddr = 0xfffffc0407180000 p_filesz = 0x50000 p_memsz = 0x50000
> > Elf header: p_type = 1, p_offset = 0x83ff1d0000 p_paddr = 0x83ff1d0000
> > p_vaddr = 0xfffffc04071d0000 p_filesz = 0x50000 p_memsz = 0x50000
> > Elf header: p_type = 1, p_offset = 0x83ff220000 p_paddr = 0x83ff220000
> > p_vaddr = 0xfffffc0407220000 p_filesz = 0xc30000 p_memsz = 0xc30000
> > Elf header: p_type = 1, p_offset = 0x83ffe50000 p_paddr = 0x83ffe50000
> > p_vaddr = 0xfffffc0407e50000 p_filesz = 0x1b0000 p_memsz = 0x1b0000
> > 
> > May be following should be better.
> > arm64_mem.page_offset = ehdr.e_entry - "kernel Code Start PA" + phys_offset.
> 
> Probably not.

page_offset is the virtual address of phys_offset, right?

ehdr.e_entry is the virtual address of "kernel Code Start PA", right?

If yes, then why should n't above be correct for all linear regions.

Other option could be what kernel is doing. But I am not sure, how can
kexec-tools get kimage_voffset.

> 
> > (4) Further more,  vmcore must have first PT_LOAD segment as kernel text area.
> 
> Which part of the code do you think depends on this assumption?

It seems that there was no issue while analyzing with crash utility, even when
first PT_LOAD segment is not for kernel text area.

However, from the comment in kexec/crashdump-elf.c: FUNC(), it seems that kernel
text is expected as first segment.

218                 /* We already prepared the header for kernel text. Map
219                  * rest of the memory segments to kernel linearly mapped
220                  * memory region.
221                  */

~Pratyush

> 
> Thanks,
> -Takahiro AKASHI
> 
> > In this platform we have first "System RAM" area as 8000000000-8001e7ffff which
> > is not matching to "Kernel code" area. Therefore, we should provide support of
> > "kern_size" so that first PT_LOAD is kernel text area.
> > 
> > ~Pratyush
> > On 09/08/2016:11:00:25 AM, AKASHI Takahiro wrote:
> > > My kernel patches of kdump suport on arm64 are currently under reviews [1].
> > > 
> > > This patchset is synced with them (v24) and provides necessary changes for
> > > kexec-tools. It should be applied on top of Geoff's kexec-tools patches
> > > v3[2] along with a bugfix[3].
> > > 
> > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447597.html
> > > [2] http://lists.infradead.org/pipermail/kexec/2016-August/016768.html
> > > [3] http://lists.infradead.org/pipermail/kexec/2016-July/016664.html
> > > 
> > > Changes for v2:
> > >  - Trim a temoprary buffer in setup_2nd_dtb()
> > >  - Add patch#6("kexec: generalize and rename get_kernel_stext_sym()")
> > >  - Update patch#7 from Pratyush
> > >    (re-worked by akashi)
> > > 
> > > AKASHI Takahiro (5):
> > >   arm64: kdump: identify memory regions
> > >   arm64: kdump: add elf core header segment
> > >   arm64: kdump: set up kernel image segment
> > >   arm64: kdump: set up other segments
> > >   arm64: kdump: add DT properties to crash dump kernel's dtb
> > > 
> > > Pratyush Anand (2):
> > >   kexec: generalize and rename get_kernel_stext_sym()
> > >   arm64: kdump: Add support for binary image files
> > > 
> > >  kexec/arch/arm/crashdump-arm.c          |  40 +------
> > >  kexec/arch/arm64/Makefile               |   2 +
> > >  kexec/arch/arm64/crashdump-arm64.c      | 188 +++++++++++++++++++++++++++++++-
> > >  kexec/arch/arm64/crashdump-arm64.h      |  18 ++-
> > >  kexec/arch/arm64/include/arch/options.h |   8 +-
> > >  kexec/arch/arm64/kexec-arm64.c          |  91 ++++++++++++++--
> > >  kexec/arch/arm64/kexec-elf-arm64.c      |  23 +++-
> > >  kexec/arch/arm64/kexec-image-arm64.c    |  60 +++++++++-
> > >  kexec/arch/i386/crashdump-x86.c         |  32 +-----
> > >  kexec/crashdump.c                       |  37 +++++++
> > >  kexec/crashdump.h                       |   1 +
> > >  11 files changed, 407 insertions(+), 93 deletions(-)
> > > 
> > > -- 
> > > 2.9.0

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

Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support

[AKASHI Takahiro]

On Fri, Aug 19, 2016 at 03:44:23PM +0530, Pratyush Anand wrote:
> On 19/08/2016:04:19:31 PM, AKASHI Takahiro wrote:
> > Pratyush, Geoff
> > 
> > # If I had Seattle, I could debug easily :)
> > 
> > On Wed, Aug 10, 2016 at 11:26:48PM +0530, Pratyush Anand wrote:
> > > Hi Geoff and Takahiro,
> > > 
> > > I am having some issues with kexec+kdump while working with Seattle platform. On
> > > top level, kernel crashes in copy_oldmem_page(), because it gets wrong offset
> > > for log_buf during vmcore-dmesg save.
> > > 
> > > Here is the detail:
> > > 
> > > (1) From /proc/iomem, these are the "System RAM" Components:
> > > 
> > > 8000000000-8001e7ffff : System RAM
> > > 8001e80000-83ff17ffff : System RAM
> > >         8002080000-8002b3ffff : Kernel code
> > >         8002c40000-800348ffff : Kernel data
> > >         807fe00000-80ffdfffff : Crash kernel
> > > 83ff180000-83ff1cffff : System RAM
> > > 83ff1d0000-83ff21ffff : System RAM
> > > 83ff220000-83ffe4ffff : System RAM
> > > 83ffe50000-83ffffffff : System RAM
> > > 
> > > (2) From kexec-tools debug print I see following:
> > > elf_arm64_load: e_entry:       fffffc0008080000 -> 0000008000080000
> > > elf_arm64_load: p_vaddr:       fffffc0008080000 -> 0000008000080000
> > > elf_arm64_load: header_offset: 0000000000000000
> > > elf_arm64_load: text_offset:   0000000000080000
> > > elf_arm64_load: image_size:    0000000001410000
> > > elf_arm64_load: phys_offset:   0000008000000000
> > > elf_arm64_load: page_offset:   fffffc0008000000
> > > 
> > > I understand that "Kernel Code start physical address" 0x8002080000 should map
> > > to e_entry vaddr which is 0xfffffc0008080000. However, kexec-tools debug print
> > > shows that e_entry vaddr maps to PA 8000080000 which seems wrong.
> > 
> > Obviously, virt_to_phys() is wrong.
> > As you know, we have to calculate virt_to_phys() in a different way
> > depending on whether the vaddr is greater than PAGE_OFFSET (linear mapping)
> > or not (kernel image mapping).
> > See the kernel's include/asm/memory.h.
> > 
> > Geoff, please update this function.
> > 
> > > (3) further page_offset (or vp_offset in your new code) is calculated
> > > as:arm64_mem.page_offset = ehdr.e_entry - arm64_mem.text_offset;
> > > 
> > > Current calcualtion of page_offset leads to wrong configuration of VA of alls
> > > PT_LOAD (see below). Ultimately, this is also leading to kernel crash during
> > > vmcore-dmesg and vmcore save operations, because we pass an offset to pread()
> > > system call which maps to wrong physical address.
> > > 
> > > Elf header: p_type = 1, p_offset = 0x8000000000 p_paddr = 0x8000000000
> > > p_vaddr = 0xfffffc0008000000 p_filesz = 0x1e80000 p_memsz = 0x1e80000
> > > [0xfffffc0008000000 should be mapping to 0x8002000000 and not 0x8000000000]
> > 
> > I think that your comment here is wrong.
> > This program header indicates the first memory region in the 1st kernel,
> > that is,
> >     8000000000-8001e7ffff : System RAM
> > 
> > Is this region really part of "System RAM?"
> > Can you show me the "Virtual kernel memory layout" in dmesg?
> 
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     modules : 0xfffffc0000000000 - 0xfffffc0008000000   (   128 MB)
> [    0.000000]     vmalloc : 0xfffffc0008000000 - 0xfffffdff5fff0000   (  2045 GB)
> [    0.000000]       .text : 0xfffffc0008080000 - 0xfffffc00087d0000   (  7488 KB)
> [    0.000000]     .rodata : 0xfffffc00087d0000 - 0xfffffc0008b40000   (  3520 KB)
> [    0.000000]       .init : 0xfffffc0008b40000 - 0xfffffc0008c40000   (  1024 KB)
> [    0.000000]       .data : 0xfffffc0008c40000 - 0xfffffc0008d93e00   (  1360 KB)
> [    0.000000]        .bss : 0xfffffc0008d93e00 - 0xfffffc0009438248   (  6802 KB)
> [    0.000000]     fixed   : 0xfffffdff7e7d0000 - 0xfffffdff7ec00000   (  4288 KB)
> [    0.000000]     PCI I/O : 0xfffffdff7ee00000 - 0xfffffdff7fe00000   (    16 MB)
> [    0.000000]     vmemmap : 0xfffffdff80000000 - 0xfffffe0000000000   (     2 GB maximum)
> [    0.000000]               0xfffffdff80000000 - 0xfffffdff81000000   (    16 MB actual)
> [    0.000000]     memory  : 0xfffffe0000000000 - 0xfffffe0400000000   ( 16384 MB)
> 
> > 
> > > Elf header: p_type = 1, p_offset = 0x8001e80000 p_paddr = 0x8001e80000
> > > p_vaddr = 0xfffffc0009e80000 p_filesz = 0x7df80000 p_memsz = 0x7df80000
> > > Elf header: p_type = 1, p_offset = 0x80ffe00000 p_paddr = 0x80ffe00000
> > > p_vaddr = 0xfffffc0107e00000 p_filesz = 0x2ff380000 p_memsz = 0x2ff380000
> > > Elf header: p_type = 1, p_offset = 0x83ff180000 p_paddr = 0x83ff180000
> > > p_vaddr = 0xfffffc0407180000 p_filesz = 0x50000 p_memsz = 0x50000
> > > Elf header: p_type = 1, p_offset = 0x83ff1d0000 p_paddr = 0x83ff1d0000
> > > p_vaddr = 0xfffffc04071d0000 p_filesz = 0x50000 p_memsz = 0x50000
> > > Elf header: p_type = 1, p_offset = 0x83ff220000 p_paddr = 0x83ff220000
> > > p_vaddr = 0xfffffc0407220000 p_filesz = 0xc30000 p_memsz = 0xc30000
> > > Elf header: p_type = 1, p_offset = 0x83ffe50000 p_paddr = 0x83ffe50000
> > > p_vaddr = 0xfffffc0407e50000 p_filesz = 0x1b0000 p_memsz = 0x1b0000
> > > 
> > > May be following should be better.
> > > arm64_mem.page_offset = ehdr.e_entry - "kernel Code Start PA" + phys_offset.
> > 
> > Probably not.
> 
> page_offset is the virtual address of phys_offset, right?
> 
> ehdr.e_entry is the virtual address of "kernel Code Start PA", right?
> 
> If yes, then why should n't above be correct for all linear regions.

What I was thinking of is that we'd better fake arm64_mem.text_offset
instead of calculating a page_offset because text_offset is also used
in arm64_load_other_segments(). Here, if the first segment doesn't not
contain kernel text, image_base will be incorrect.
(It still works, though, now that the kernel can be loaded in any address.)

> Other option could be what kernel is doing. But I am not sure, how can
> kexec-tools get kimage_voffset.
> 
> > 
> > > (4) Further more,  vmcore must have first PT_LOAD segment as kernel text area.
> > 
> > Which part of the code do you think depends on this assumption?
> 
> It seems that there was no issue while analyzing with crash utility, even when
> first PT_LOAD segment is not for kernel text area.
> 
> However, from the comment in kexec/crashdump-elf.c: FUNC(), it seems that kernel
> text is expected as first segment.
> 
> 218                 /* We already prepared the header for kernel text. Map
> 219                  * rest of the memory segments to kernel linearly mapped
> 220                  * memory region.
> 221                  */

Well, I guess, the point is not that the first segment has kernel text,
but that there is one segment, in any order, which contains actual virtual
address range of kernel text/data if the kernel is "relocatable," that is,
KASLR-enabled.

In this case, the vmcore file may refer to randomized addresses of symbols
which don't match ones in vmlinux. So we will not be able to examine the core
with, say, gdb.
Crash utility, on the other hand, is *KASLR-aware*.

I will try to support "kern_size" on kexec-tools for arm64.

Thanks,
-Takahiro AKASHI

> ~Pratyush
> 
> > 
> > Thanks,
> > -Takahiro AKASHI
> > 
> > > In this platform we have first "System RAM" area as 8000000000-8001e7ffff which
> > > is not matching to "Kernel code" area. Therefore, we should provide support of
> > > "kern_size" so that first PT_LOAD is kernel text area.
> > > 
> > > ~Pratyush
> > > On 09/08/2016:11:00:25 AM, AKASHI Takahiro wrote:
> > > > My kernel patches of kdump suport on arm64 are currently under reviews [1].
> > > > 
> > > > This patchset is synced with them (v24) and provides necessary changes for
> > > > kexec-tools. It should be applied on top of Geoff's kexec-tools patches
> > > > v3[2] along with a bugfix[3].
> > > > 
> > > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447597.html
> > > > [2] http://lists.infradead.org/pipermail/kexec/2016-August/016768.html
> > > > [3] http://lists.infradead.org/pipermail/kexec/2016-July/016664.html
> > > > 
> > > > Changes for v2:
> > > >  - Trim a temoprary buffer in setup_2nd_dtb()
> > > >  - Add patch#6("kexec: generalize and rename get_kernel_stext_sym()")
> > > >  - Update patch#7 from Pratyush
> > > >    (re-worked by akashi)
> > > > 
> > > > AKASHI Takahiro (5):
> > > >   arm64: kdump: identify memory regions
> > > >   arm64: kdump: add elf core header segment
> > > >   arm64: kdump: set up kernel image segment
> > > >   arm64: kdump: set up other segments
> > > >   arm64: kdump: add DT properties to crash dump kernel's dtb
> > > > 
> > > > Pratyush Anand (2):
> > > >   kexec: generalize and rename get_kernel_stext_sym()
> > > >   arm64: kdump: Add support for binary image files
> > > > 
> > > >  kexec/arch/arm/crashdump-arm.c          |  40 +------
> > > >  kexec/arch/arm64/Makefile               |   2 +
> > > >  kexec/arch/arm64/crashdump-arm64.c      | 188 +++++++++++++++++++++++++++++++-
> > > >  kexec/arch/arm64/crashdump-arm64.h      |  18 ++-
> > > >  kexec/arch/arm64/include/arch/options.h |   8 +-
> > > >  kexec/arch/arm64/kexec-arm64.c          |  91 ++++++++++++++--
> > > >  kexec/arch/arm64/kexec-elf-arm64.c      |  23 +++-
> > > >  kexec/arch/arm64/kexec-image-arm64.c    |  60 +++++++++-
> > > >  kexec/arch/i386/crashdump-x86.c         |  32 +-----
> > > >  kexec/crashdump.c                       |  37 +++++++
> > > >  kexec/crashdump.h                       |   1 +
> > > >  11 files changed, 407 insertions(+), 93 deletions(-)
> > > > 
> > > > -- 
> > > > 2.9.0

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

Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support

[AKASHI Takahiro]

Pratyush,

On Wed, Aug 10, 2016 at 11:26:48PM +0530, Pratyush Anand wrote:
> Hi Geoff and Takahiro,
> 
> I am having some issues with kexec+kdump while working with Seattle platform. On
> top level, kernel crashes in copy_oldmem_page(), because it gets wrong offset
> for log_buf during vmcore-dmesg save.
> 
> Here is the detail:
> 
> (1) From /proc/iomem, these are the "System RAM" Components:
> 
> 8000000000-8001e7ffff : System RAM
> 8001e80000-83ff17ffff : System RAM
>         8002080000-8002b3ffff : Kernel code
>         8002c40000-800348ffff : Kernel data
>         807fe00000-80ffdfffff : Crash kernel
> 83ff180000-83ff1cffff : System RAM
> 83ff1d0000-83ff21ffff : System RAM
> 83ff220000-83ffe4ffff : System RAM
> 83ffe50000-83ffffffff : System RAM
> 
> (2) From kexec-tools debug print I see following:
> elf_arm64_load: e_entry:       fffffc0008080000 -> 0000008000080000
> elf_arm64_load: p_vaddr:       fffffc0008080000 -> 0000008000080000
> elf_arm64_load: header_offset: 0000000000000000
> elf_arm64_load: text_offset:   0000000000080000
> elf_arm64_load: image_size:    0000000001410000
> elf_arm64_load: phys_offset:   0000008000000000
> elf_arm64_load: page_offset:   fffffc0008000000
>
> I understand that "Kernel Code start physical address" 0x8002080000 should map
> to e_entry vaddr which is 0xfffffc0008080000. However, kexec-tools debug print
> shows that e_entry vaddr maps to PA 8000080000 which seems wrong.

Who specifies the kernel load address, 0x8002080000 and why?

Since image_arm64_load() also use
    get_phys_offset() + arm64_mem.text_offset (== 0x8000080000)
as the load address unconditionally, doesn't kexec fail on Seattle?

-Takahiro AKASHI

> (3) further page_offset (or vp_offset in your new code) is calculated
> as:arm64_mem.page_offset = ehdr.e_entry - arm64_mem.text_offset;
> 
> Current calcualtion of page_offset leads to wrong configuration of VA of alls
> PT_LOAD (see below). Ultimately, this is also leading to kernel crash during
> vmcore-dmesg and vmcore save operations, because we pass an offset to pread()
> system call which maps to wrong physical address.
> 
> Elf header: p_type = 1, p_offset = 0x8000000000 p_paddr = 0x8000000000
> p_vaddr = 0xfffffc0008000000 p_filesz = 0x1e80000 p_memsz = 0x1e80000
> [0xfffffc0008000000 should be mapping to 0x8002000000 and not 0x8000000000]
> Elf header: p_type = 1, p_offset = 0x8001e80000 p_paddr = 0x8001e80000
> p_vaddr = 0xfffffc0009e80000 p_filesz = 0x7df80000 p_memsz = 0x7df80000
> Elf header: p_type = 1, p_offset = 0x80ffe00000 p_paddr = 0x80ffe00000
> p_vaddr = 0xfffffc0107e00000 p_filesz = 0x2ff380000 p_memsz = 0x2ff380000
> Elf header: p_type = 1, p_offset = 0x83ff180000 p_paddr = 0x83ff180000
> p_vaddr = 0xfffffc0407180000 p_filesz = 0x50000 p_memsz = 0x50000
> Elf header: p_type = 1, p_offset = 0x83ff1d0000 p_paddr = 0x83ff1d0000
> p_vaddr = 0xfffffc04071d0000 p_filesz = 0x50000 p_memsz = 0x50000
> Elf header: p_type = 1, p_offset = 0x83ff220000 p_paddr = 0x83ff220000
> p_vaddr = 0xfffffc0407220000 p_filesz = 0xc30000 p_memsz = 0xc30000
> Elf header: p_type = 1, p_offset = 0x83ffe50000 p_paddr = 0x83ffe50000
> p_vaddr = 0xfffffc0407e50000 p_filesz = 0x1b0000 p_memsz = 0x1b0000
> 
> May be following should be better.
> arm64_mem.page_offset = ehdr.e_entry - "kernel Code Start PA" + phys_offset.
> 
> (4) Further more,  vmcore must have first PT_LOAD segment as kernel text area.
> In this platform we have first "System RAM" area as 8000000000-8001e7ffff which
> is not matching to "Kernel code" area. Therefore, we should provide support of
> "kern_size" so that first PT_LOAD is kernel text area.
> 
> ~Pratyush
> On 09/08/2016:11:00:25 AM, AKASHI Takahiro wrote:
> > My kernel patches of kdump suport on arm64 are currently under reviews [1].
> > 
> > This patchset is synced with them (v24) and provides necessary changes for
> > kexec-tools. It should be applied on top of Geoff's kexec-tools patches
> > v3[2] along with a bugfix[3].
> > 
> > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447597.html
> > [2] http://lists.infradead.org/pipermail/kexec/2016-August/016768.html
> > [3] http://lists.infradead.org/pipermail/kexec/2016-July/016664.html
> > 
> > Changes for v2:
> >  - Trim a temoprary buffer in setup_2nd_dtb()
> >  - Add patch#6("kexec: generalize and rename get_kernel_stext_sym()")
> >  - Update patch#7 from Pratyush
> >    (re-worked by akashi)
> > 
> > AKASHI Takahiro (5):
> >   arm64: kdump: identify memory regions
> >   arm64: kdump: add elf core header segment
> >   arm64: kdump: set up kernel image segment
> >   arm64: kdump: set up other segments
> >   arm64: kdump: add DT properties to crash dump kernel's dtb
> > 
> > Pratyush Anand (2):
> >   kexec: generalize and rename get_kernel_stext_sym()
> >   arm64: kdump: Add support for binary image files
> > 
> >  kexec/arch/arm/crashdump-arm.c          |  40 +------
> >  kexec/arch/arm64/Makefile               |   2 +
> >  kexec/arch/arm64/crashdump-arm64.c      | 188 +++++++++++++++++++++++++++++++-
> >  kexec/arch/arm64/crashdump-arm64.h      |  18 ++-
> >  kexec/arch/arm64/include/arch/options.h |   8 +-
> >  kexec/arch/arm64/kexec-arm64.c          |  91 ++++++++++++++--
> >  kexec/arch/arm64/kexec-elf-arm64.c      |  23 +++-
> >  kexec/arch/arm64/kexec-image-arm64.c    |  60 +++++++++-
> >  kexec/arch/i386/crashdump-x86.c         |  32 +-----
> >  kexec/crashdump.c                       |  37 +++++++
> >  kexec/crashdump.h                       |   1 +
> >  11 files changed, 407 insertions(+), 93 deletions(-)
> > 
> > -- 
> > 2.9.0

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

Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support

[Pratyush Anand]

On 23/08/2016:02:29:03 PM, AKASHI Takahiro wrote:
> Pratyush,
> 
> On Wed, Aug 10, 2016 at 11:26:48PM +0530, Pratyush Anand wrote:
> > Hi Geoff and Takahiro,
> > 
> > I am having some issues with kexec+kdump while working with Seattle platform. On
> > top level, kernel crashes in copy_oldmem_page(), because it gets wrong offset
> > for log_buf during vmcore-dmesg save.
> > 
> > Here is the detail:
> > 
> > (1) From /proc/iomem, these are the "System RAM" Components:
> > 
> > 8000000000-8001e7ffff : System RAM
> > 8001e80000-83ff17ffff : System RAM
> >         8002080000-8002b3ffff : Kernel code
> >         8002c40000-800348ffff : Kernel data
> >         807fe00000-80ffdfffff : Crash kernel
> > 83ff180000-83ff1cffff : System RAM
> > 83ff1d0000-83ff21ffff : System RAM
> > 83ff220000-83ffe4ffff : System RAM
> > 83ffe50000-83ffffffff : System RAM
> > 
> > (2) From kexec-tools debug print I see following:
> > elf_arm64_load: e_entry:       fffffc0008080000 -> 0000008000080000
> > elf_arm64_load: p_vaddr:       fffffc0008080000 -> 0000008000080000
> > elf_arm64_load: header_offset: 0000000000000000
> > elf_arm64_load: text_offset:   0000000000080000
> > elf_arm64_load: image_size:    0000000001410000
> > elf_arm64_load: phys_offset:   0000008000000000
> > elf_arm64_load: page_offset:   fffffc0008000000
> >
> > I understand that "Kernel Code start physical address" 0x8002080000 should map
> > to e_entry vaddr which is 0xfffffc0008080000. However, kexec-tools debug print
> > shows that e_entry vaddr maps to PA 8000080000 which seems wrong.
> 
> Who specifies the kernel load address, 0x8002080000 and why?

May be I could not get the question. This load address is coming from the 1st
kernel.

> 
> Since image_arm64_load() also use
>     get_phys_offset() + arm64_mem.text_offset (== 0x8000080000)
> as the load address unconditionally, doesn't kexec fail on Seattle?

Yes, had n't tried kexec with binary image. It fails.
I think image_base should be virt_to_phys(get_kernel_sym("_text")) for
!KEXEC_ON_CRASH.

~Pratyush

> 
> -Takahiro AKASHI
> 
> > (3) further page_offset (or vp_offset in your new code) is calculated
> > as:arm64_mem.page_offset = ehdr.e_entry - arm64_mem.text_offset;
> > 
> > Current calcualtion of page_offset leads to wrong configuration of VA of alls
> > PT_LOAD (see below). Ultimately, this is also leading to kernel crash during
> > vmcore-dmesg and vmcore save operations, because we pass an offset to pread()
> > system call which maps to wrong physical address.
> > 
> > Elf header: p_type = 1, p_offset = 0x8000000000 p_paddr = 0x8000000000
> > p_vaddr = 0xfffffc0008000000 p_filesz = 0x1e80000 p_memsz = 0x1e80000
> > [0xfffffc0008000000 should be mapping to 0x8002000000 and not 0x8000000000]
> > Elf header: p_type = 1, p_offset = 0x8001e80000 p_paddr = 0x8001e80000
> > p_vaddr = 0xfffffc0009e80000 p_filesz = 0x7df80000 p_memsz = 0x7df80000
> > Elf header: p_type = 1, p_offset = 0x80ffe00000 p_paddr = 0x80ffe00000
> > p_vaddr = 0xfffffc0107e00000 p_filesz = 0x2ff380000 p_memsz = 0x2ff380000
> > Elf header: p_type = 1, p_offset = 0x83ff180000 p_paddr = 0x83ff180000
> > p_vaddr = 0xfffffc0407180000 p_filesz = 0x50000 p_memsz = 0x50000
> > Elf header: p_type = 1, p_offset = 0x83ff1d0000 p_paddr = 0x83ff1d0000
> > p_vaddr = 0xfffffc04071d0000 p_filesz = 0x50000 p_memsz = 0x50000
> > Elf header: p_type = 1, p_offset = 0x83ff220000 p_paddr = 0x83ff220000
> > p_vaddr = 0xfffffc0407220000 p_filesz = 0xc30000 p_memsz = 0xc30000
> > Elf header: p_type = 1, p_offset = 0x83ffe50000 p_paddr = 0x83ffe50000
> > p_vaddr = 0xfffffc0407e50000 p_filesz = 0x1b0000 p_memsz = 0x1b0000
> > 
> > May be following should be better.
> > arm64_mem.page_offset = ehdr.e_entry - "kernel Code Start PA" + phys_offset.
> > 
> > (4) Further more,  vmcore must have first PT_LOAD segment as kernel text area.
> > In this platform we have first "System RAM" area as 8000000000-8001e7ffff which
> > is not matching to "Kernel code" area. Therefore, we should provide support of
> > "kern_size" so that first PT_LOAD is kernel text area.
> > 
> > ~Pratyush
> > On 09/08/2016:11:00:25 AM, AKASHI Takahiro wrote:
> > > My kernel patches of kdump suport on arm64 are currently under reviews [1].
> > > 
> > > This patchset is synced with them (v24) and provides necessary changes for
> > > kexec-tools. It should be applied on top of Geoff's kexec-tools patches
> > > v3[2] along with a bugfix[3].
> > > 
> > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447597.html
> > > [2] http://lists.infradead.org/pipermail/kexec/2016-August/016768.html
> > > [3] http://lists.infradead.org/pipermail/kexec/2016-July/016664.html
> > > 
> > > Changes for v2:
> > >  - Trim a temoprary buffer in setup_2nd_dtb()
> > >  - Add patch#6("kexec: generalize and rename get_kernel_stext_sym()")
> > >  - Update patch#7 from Pratyush
> > >    (re-worked by akashi)
> > > 
> > > AKASHI Takahiro (5):
> > >   arm64: kdump: identify memory regions
> > >   arm64: kdump: add elf core header segment
> > >   arm64: kdump: set up kernel image segment
> > >   arm64: kdump: set up other segments
> > >   arm64: kdump: add DT properties to crash dump kernel's dtb
> > > 
> > > Pratyush Anand (2):
> > >   kexec: generalize and rename get_kernel_stext_sym()
> > >   arm64: kdump: Add support for binary image files
> > > 
> > >  kexec/arch/arm/crashdump-arm.c          |  40 +------
> > >  kexec/arch/arm64/Makefile               |   2 +
> > >  kexec/arch/arm64/crashdump-arm64.c      | 188 +++++++++++++++++++++++++++++++-
> > >  kexec/arch/arm64/crashdump-arm64.h      |  18 ++-
> > >  kexec/arch/arm64/include/arch/options.h |   8 +-
> > >  kexec/arch/arm64/kexec-arm64.c          |  91 ++++++++++++++--
> > >  kexec/arch/arm64/kexec-elf-arm64.c      |  23 +++-
> > >  kexec/arch/arm64/kexec-image-arm64.c    |  60 +++++++++-
> > >  kexec/arch/i386/crashdump-x86.c         |  32 +-----
> > >  kexec/crashdump.c                       |  37 +++++++
> > >  kexec/crashdump.h                       |   1 +
> > >  11 files changed, 407 insertions(+), 93 deletions(-)
> > > 
> > > -- 
> > > 2.9.0

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

Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support

[Pratyush Anand]

On 22/08/2016:05:10:17 PM, AKASHI Takahiro wrote:
> On Fri, Aug 19, 2016 at 03:44:23PM +0530, Pratyush Anand wrote:
> > page_offset is the virtual address of phys_offset, right?
> > 
> > ehdr.e_entry is the virtual address of "kernel Code Start PA", right?
> > 
> > If yes, then why should n't above be correct for all linear regions.
> 
> What I was thinking of is that we'd better fake arm64_mem.text_offset
> instead of calculating a page_offset because text_offset is also used
> in arm64_load_other_segments(). Here, if the first segment doesn't not
> contain kernel text, image_base will be incorrect.

IMHO, we should keep all definitions in kexec-tools as close as possible to that
of corresponding definitions in kernel. This will help us to avoid any confusion
in future.

~Pratyush

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

Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support

[AKASHI Takahiro]

On Tue, Aug 23, 2016 at 01:34:21PM +0530, Pratyush Anand wrote:
> On 23/08/2016:02:29:03 PM, AKASHI Takahiro wrote:
> > Pratyush,
> > 
> > On Wed, Aug 10, 2016 at 11:26:48PM +0530, Pratyush Anand wrote:
> > > Hi Geoff and Takahiro,
> > > 
> > > I am having some issues with kexec+kdump while working with Seattle platform. On
> > > top level, kernel crashes in copy_oldmem_page(), because it gets wrong offset
> > > for log_buf during vmcore-dmesg save.
> > > 
> > > Here is the detail:
> > > 
> > > (1) From /proc/iomem, these are the "System RAM" Components:
> > > 
> > > 8000000000-8001e7ffff : System RAM
> > > 8001e80000-83ff17ffff : System RAM
> > >         8002080000-8002b3ffff : Kernel code
> > >         8002c40000-800348ffff : Kernel data
> > >         807fe00000-80ffdfffff : Crash kernel
> > > 83ff180000-83ff1cffff : System RAM
> > > 83ff1d0000-83ff21ffff : System RAM
> > > 83ff220000-83ffe4ffff : System RAM
> > > 83ffe50000-83ffffffff : System RAM
> > > 
> > > (2) From kexec-tools debug print I see following:
> > > elf_arm64_load: e_entry:       fffffc0008080000 -> 0000008000080000
> > > elf_arm64_load: p_vaddr:       fffffc0008080000 -> 0000008000080000
> > > elf_arm64_load: header_offset: 0000000000000000
> > > elf_arm64_load: text_offset:   0000000000080000
> > > elf_arm64_load: image_size:    0000000001410000
> > > elf_arm64_load: phys_offset:   0000008000000000
> > > elf_arm64_load: page_offset:   fffffc0008000000
> > >
> > > I understand that "Kernel Code start physical address" 0x8002080000 should map
> > > to e_entry vaddr which is 0xfffffc0008080000. However, kexec-tools debug print
> > > shows that e_entry vaddr maps to PA 8000080000 which seems wrong.
> > 
> > Who specifies the kernel load address, 0x8002080000 and why?
> 
> May be I could not get the question. This load address is coming from the 1st
> kernel.

My question is why we need to use this value, 0x8002080000,
as the kernel load address.
I guess that, on Seattle platform, 0x8000000000-0x8001e80000 is
used for a specific purpose and the kernel must be loaded above
0x8001e80000.
Since PHYS_OFFSET must be 2MB aligned, the lowest kernel load address
should be:
    0x8002000000 + 0x80000(default TEXT_OFFSET).

> > 
> > Since image_arm64_load() also use
> >     get_phys_offset() + arm64_mem.text_offset (== 0x8000080000)
> > as the load address unconditionally, doesn't kexec fail on Seattle?
> 
> Yes, had n't tried kexec with binary image. It fails.
> I think image_base should be virt_to_phys(get_kernel_sym("_text")) for
> !KEXEC_ON_CRASH.

So all what we expect from kexec-tools as a sort of boot loader,
we should be able to specify the command line like:
    $ kexec --load vmlinux (or Image) --mem-min=0x8001e80000 ...

(We could use get_kernel_sym("_text"), but don't have to.)

I'm going to modify our arm64 port in this way.

Thanks,
-Takahiro AKASHI

> ~Pratyush
> 
> > 
> > -Takahiro AKASHI
> > 
> > > (3) further page_offset (or vp_offset in your new code) is calculated
> > > as:arm64_mem.page_offset = ehdr.e_entry - arm64_mem.text_offset;
> > > 
> > > Current calcualtion of page_offset leads to wrong configuration of VA of alls
> > > PT_LOAD (see below). Ultimately, this is also leading to kernel crash during
> > > vmcore-dmesg and vmcore save operations, because we pass an offset to pread()
> > > system call which maps to wrong physical address.
> > > 
> > > Elf header: p_type = 1, p_offset = 0x8000000000 p_paddr = 0x8000000000
> > > p_vaddr = 0xfffffc0008000000 p_filesz = 0x1e80000 p_memsz = 0x1e80000
> > > [0xfffffc0008000000 should be mapping to 0x8002000000 and not 0x8000000000]
> > > Elf header: p_type = 1, p_offset = 0x8001e80000 p_paddr = 0x8001e80000
> > > p_vaddr = 0xfffffc0009e80000 p_filesz = 0x7df80000 p_memsz = 0x7df80000
> > > Elf header: p_type = 1, p_offset = 0x80ffe00000 p_paddr = 0x80ffe00000
> > > p_vaddr = 0xfffffc0107e00000 p_filesz = 0x2ff380000 p_memsz = 0x2ff380000
> > > Elf header: p_type = 1, p_offset = 0x83ff180000 p_paddr = 0x83ff180000
> > > p_vaddr = 0xfffffc0407180000 p_filesz = 0x50000 p_memsz = 0x50000
> > > Elf header: p_type = 1, p_offset = 0x83ff1d0000 p_paddr = 0x83ff1d0000
> > > p_vaddr = 0xfffffc04071d0000 p_filesz = 0x50000 p_memsz = 0x50000
> > > Elf header: p_type = 1, p_offset = 0x83ff220000 p_paddr = 0x83ff220000
> > > p_vaddr = 0xfffffc0407220000 p_filesz = 0xc30000 p_memsz = 0xc30000
> > > Elf header: p_type = 1, p_offset = 0x83ffe50000 p_paddr = 0x83ffe50000
> > > p_vaddr = 0xfffffc0407e50000 p_filesz = 0x1b0000 p_memsz = 0x1b0000
> > > 
> > > May be following should be better.
> > > arm64_mem.page_offset = ehdr.e_entry - "kernel Code Start PA" + phys_offset.
> > > 
> > > (4) Further more,  vmcore must have first PT_LOAD segment as kernel text area.
> > > In this platform we have first "System RAM" area as 8000000000-8001e7ffff which
> > > is not matching to "Kernel code" area. Therefore, we should provide support of
> > > "kern_size" so that first PT_LOAD is kernel text area.
> > > 
> > > ~Pratyush
> > > On 09/08/2016:11:00:25 AM, AKASHI Takahiro wrote:
> > > > My kernel patches of kdump suport on arm64 are currently under reviews [1].
> > > > 
> > > > This patchset is synced with them (v24) and provides necessary changes for
> > > > kexec-tools. It should be applied on top of Geoff's kexec-tools patches
> > > > v3[2] along with a bugfix[3].
> > > > 
> > > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447597.html
> > > > [2] http://lists.infradead.org/pipermail/kexec/2016-August/016768.html
> > > > [3] http://lists.infradead.org/pipermail/kexec/2016-July/016664.html
> > > > 
> > > > Changes for v2:
> > > >  - Trim a temoprary buffer in setup_2nd_dtb()
> > > >  - Add patch#6("kexec: generalize and rename get_kernel_stext_sym()")
> > > >  - Update patch#7 from Pratyush
> > > >    (re-worked by akashi)
> > > > 
> > > > AKASHI Takahiro (5):
> > > >   arm64: kdump: identify memory regions
> > > >   arm64: kdump: add elf core header segment
> > > >   arm64: kdump: set up kernel image segment
> > > >   arm64: kdump: set up other segments
> > > >   arm64: kdump: add DT properties to crash dump kernel's dtb
> > > > 
> > > > Pratyush Anand (2):
> > > >   kexec: generalize and rename get_kernel_stext_sym()
> > > >   arm64: kdump: Add support for binary image files
> > > > 
> > > >  kexec/arch/arm/crashdump-arm.c          |  40 +------
> > > >  kexec/arch/arm64/Makefile               |   2 +
> > > >  kexec/arch/arm64/crashdump-arm64.c      | 188 +++++++++++++++++++++++++++++++-
> > > >  kexec/arch/arm64/crashdump-arm64.h      |  18 ++-
> > > >  kexec/arch/arm64/include/arch/options.h |   8 +-
> > > >  kexec/arch/arm64/kexec-arm64.c          |  91 ++++++++++++++--
> > > >  kexec/arch/arm64/kexec-elf-arm64.c      |  23 +++-
> > > >  kexec/arch/arm64/kexec-image-arm64.c    |  60 +++++++++-
> > > >  kexec/arch/i386/crashdump-x86.c         |  32 +-----
> > > >  kexec/crashdump.c                       |  37 +++++++
> > > >  kexec/crashdump.h                       |   1 +
> > > >  11 files changed, 407 insertions(+), 93 deletions(-)
> > > > 
> > > > -- 
> > > > 2.9.0

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