* [PATCH v23 1/9] arm64: kdump: reserve memory for crash dump kernel
2016-07-26 7:56 [PATCH v23 0/9] arm64: add kdump support AKASHI Takahiro
@ 2016-07-26 7:56 ` AKASHI Takahiro
2016-07-26 7:56 ` [PATCH v23 2/9] memblock: add memblock_cap_memory_range() AKASHI Takahiro
` (8 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: AKASHI Takahiro @ 2016-07-26 7:56 UTC (permalink / raw)
To: linux-arm-kernel
On the startup of primary kernel, the memory region used by crash dump
kernel must be specified by "crashkernel=" kernel parameter.
reserve_crashkernel() will allocate and reserve the region for later use.
User space tools, like kexec-tools, will be able to find that region as
- "Crash kernel" in /proc/iomem, or
- "linux,crashkernel-base" and "linux,crashkernel-size" under
/sys/firmware/devicetree/base/chosen
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Pratyush Anand <panand@redhat.com>
Reviewed-by: James Morse <james.morse@arm.com>
---
arch/arm64/kernel/setup.c | 7 ++-
arch/arm64/mm/init.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 119 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index c1509e6..cb5eee0 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -31,7 +31,6 @@
#include <linux/screen_info.h>
#include <linux/init.h>
#include <linux/kexec.h>
-#include <linux/crash_dump.h>
#include <linux/root_dev.h>
#include <linux/cpu.h>
#include <linux/interrupt.h>
@@ -222,6 +221,12 @@ static void __init request_standard_resources(void)
kernel_data.end <= res->end)
request_resource(res, &kernel_data);
}
+
+#ifdef CONFIG_KEXEC_CORE
+ /* User space tools will find "Crash kernel" region in /proc/iomem. */
+ if (crashk_res.end)
+ insert_resource(&iomem_resource, &crashk_res);
+#endif
}
u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 2ade7a6..27f756a 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -29,11 +29,13 @@
#include <linux/gfp.h>
#include <linux/memblock.h>
#include <linux/sort.h>
+#include <linux/of.h>
#include <linux/of_fdt.h>
#include <linux/dma-mapping.h>
#include <linux/dma-contiguous.h>
#include <linux/efi.h>
#include <linux/swiotlb.h>
+#include <linux/kexec.h>
#include <asm/boot.h>
#include <asm/fixmap.h>
@@ -76,6 +78,114 @@ static int __init early_initrd(char *p)
early_param("initrd", early_initrd);
#endif
+#ifdef CONFIG_KEXEC_CORE
+static unsigned long long crash_size, crash_base;
+static struct property crash_base_prop = {
+ .name = "linux,crashkernel-base",
+ .length = sizeof(u64),
+ .value = &crash_base
+};
+static struct property crash_size_prop = {
+ .name = "linux,crashkernel-size",
+ .length = sizeof(u64),
+ .value = &crash_size,
+};
+
+static int __init export_crashkernel(void)
+{
+ struct device_node *node;
+ int ret;
+
+ if (!crashk_res.end)
+ return 0;
+
+ crash_base = cpu_to_be64(crashk_res.start);
+ crash_size = cpu_to_be64(crashk_res.end - crashk_res.start + 1);
+
+ /* Add /chosen/linux,crashkernel-* properties */
+ node = of_find_node_by_path("/chosen");
+ if (!node)
+ return -ENOENT;
+
+ /*
+ * There might be existing crash kernel properties, but we can't
+ * be sure what's in them, so remove them.
+ */
+ of_remove_property(node, of_find_property(node,
+ "linux,crashkernel-base", NULL));
+ of_remove_property(node, of_find_property(node,
+ "linux,crashkernel-size", NULL));
+
+ ret = of_add_property(node, &crash_base_prop);
+ if (ret)
+ goto ret_err;
+
+ ret = of_add_property(node, &crash_size_prop);
+ if (ret)
+ goto ret_err;
+
+ return 0;
+
+ret_err:
+ pr_warn("Exporting crashkernel region to device tree failed\n");
+ return ret;
+}
+late_initcall(export_crashkernel);
+
+/*
+ * reserve_crashkernel() - reserves memory for crash kernel
+ *
+ * This function reserves memory area given in "crashkernel=" kernel command
+ * line parameter. The memory reserved is used by dump capture kernel when
+ * primary kernel is crashing.
+ */
+static void __init reserve_crashkernel(void)
+{
+ int ret;
+
+ ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
+ &crash_size, &crash_base);
+ /* no crashkernel= or invalid value specified */
+ if (ret || !crash_size)
+ return;
+
+ if (crash_base == 0) {
+ /* Current arm64 boot protocol requires 2MB alignment */
+ crash_base = memblock_find_in_range(0, ARCH_LOW_ADDRESS_LIMIT,
+ crash_size, SZ_2M);
+ if (crash_base == 0) {
+ pr_warn("Unable to allocate crashkernel (size:%llx)\n",
+ crash_size);
+ return;
+ }
+ } else {
+ /* User specifies base address explicitly. */
+ if (!memblock_is_region_memory(crash_base, crash_size) ||
+ memblock_is_region_reserved(crash_base, crash_size)) {
+ pr_warn("crashkernel has wrong address or size\n");
+ return;
+ }
+
+ if (!IS_ALIGNED(crash_base, SZ_2M)) {
+ pr_warn("crashkernel base address is not 2MB aligned\n");
+ return;
+ }
+ }
+ memblock_reserve(crash_base, crash_size);
+
+ pr_info("Reserving %lldMB of memory at %lldMB for crashkernel\n",
+ crash_size >> 20, crash_base >> 20);
+
+ crashk_res.start = crash_base;
+ crashk_res.end = crash_base + crash_size - 1;
+}
+#else
+static void __init reserve_crashkernel(void)
+{
+ ;
+}
+#endif /* CONFIG_KEXEC_CORE */
+
/*
* Return the maximum physical address for ZONE_DMA (DMA_BIT_MASK(32)). It
* currently assumes that for memory starting above 4G, 32-bit devices will
@@ -296,6 +406,9 @@ void __init arm64_memblock_init(void)
arm64_dma_phys_limit = max_zone_dma_phys();
else
arm64_dma_phys_limit = PHYS_MASK + 1;
+
+ reserve_crashkernel();
+
dma_contiguous_reserve(arm64_dma_phys_limit);
memblock_allow_resize();
--
2.9.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH v23 2/9] memblock: add memblock_cap_memory_range()
2016-07-26 7:56 [PATCH v23 0/9] arm64: add kdump support AKASHI Takahiro
2016-07-26 7:56 ` [PATCH v23 1/9] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
@ 2016-07-26 7:56 ` AKASHI Takahiro
2016-07-26 7:56 ` [PATCH v23 3/9] arm64: limit memory regions based on DT property, usable-memory-range AKASHI Takahiro
` (7 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: AKASHI Takahiro @ 2016-07-26 7:56 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
include/linux/memblock.h | 1 +
mm/memblock.c | 28 ++++++++++++++++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 3106ac1..9ab17a9 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -333,6 +333,7 @@ phys_addr_t memblock_mem_size(unsigned long limit_pfn);
phys_addr_t memblock_start_of_DRAM(void);
phys_addr_t memblock_end_of_DRAM(void);
void memblock_enforce_memory_limit(phys_addr_t memory_limit);
+void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
bool memblock_is_memory(phys_addr_t addr);
int memblock_is_map_memory(phys_addr_t addr);
int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
diff --git a/mm/memblock.c b/mm/memblock.c
index ac12489..30badf1 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1486,6 +1486,34 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
(phys_addr_t)ULLONG_MAX);
}
+void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
+{
+ int start_rgn, end_rgn;
+ int i, ret;
+
+ if (!size)
+ return;
+
+ ret = memblock_isolate_range(&memblock.memory, base, size,
+ &start_rgn, &end_rgn);
+ if (ret)
+ return;
+
+ /* remove all the MAP regions */
+ for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
+ if (!memblock_is_nomap(&memblock.memory.regions[i]))
+ memblock_remove_region(&memblock.memory, i);
+
+ for (i = start_rgn - 1; i >= 0; i--)
+ if (!memblock_is_nomap(&memblock.memory.regions[i]))
+ memblock_remove_region(&memblock.memory, i);
+
+ /* truncate the reserved regions */
+ memblock_remove_range(&memblock.reserved, 0, base);
+ memblock_remove_range(&memblock.reserved,
+ base + size, (phys_addr_t)ULLONG_MAX);
+}
+
static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)
{
unsigned int left = 0, right = type->cnt;
--
2.9.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH v23 3/9] arm64: limit memory regions based on DT property, usable-memory-range
2016-07-26 7:56 [PATCH v23 0/9] arm64: add kdump support AKASHI Takahiro
2016-07-26 7:56 ` [PATCH v23 1/9] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2016-07-26 7:56 ` [PATCH v23 2/9] memblock: add memblock_cap_memory_range() AKASHI Takahiro
@ 2016-07-26 7:56 ` AKASHI Takahiro
2016-07-26 7:56 ` [PATCH v23 4/9] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
` (6 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: AKASHI Takahiro @ 2016-07-26 7:56 UTC (permalink / raw)
To: linux-arm-kernel
Crash dump kernel will be run with a limited range of memory as System
RAM.
On arm64, we will use a device-tree property under /chosen,
linux,usable-memory-range = <BASE SIZE>
in order for primary kernel either on uefi or non-uefi (device tree only)
system to hand over the information about usable memory region to crash
dump kernel. This property will supercede entries in uefi memory map table
and "memory" nodes in a device tree.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Geoff Levand <geoff@infradead.org>
---
arch/arm64/mm/init.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 27f756a..8699a8ea 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -297,10 +297,45 @@ static int __init early_mem(char *p)
}
early_param("mem", early_mem);
+static int __init early_init_dt_scan_usablemem(unsigned long node,
+ const char *uname, int depth, void *data)
+{
+ struct memblock_region *usablemem = (struct memblock_region *)data;
+ const __be32 *reg;
+ int len;
+
+ usablemem->size = 0;
+
+ if (depth != 1 || strcmp(uname, "chosen") != 0)
+ return 0;
+
+ reg = of_get_flat_dt_prop(node, "linux,usable-memory-range", &len);
+ if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
+ return 1;
+
+ usablemem->base = dt_mem_next_cell(dt_root_addr_cells, ®);
+ usablemem->size = dt_mem_next_cell(dt_root_size_cells, ®);
+
+ return 1;
+}
+
+static void __init fdt_enforce_memory_region(void)
+{
+ struct memblock_region reg;
+
+ of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
+
+ if (reg.size)
+ memblock_cap_memory_range(reg.base, reg.size);
+}
+
void __init arm64_memblock_init(void)
{
const s64 linear_region_size = -(s64)PAGE_OFFSET;
+ /* Handle linux,usable-memory-range property */
+ fdt_enforce_memory_region();
+
/*
* Ensure that the linear region takes up exactly half of the kernel
* virtual address space. This way, we can distinguish a linear address
--
2.9.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH v23 4/9] arm64: kdump: implement machine_crash_shutdown()
2016-07-26 7:56 [PATCH v23 0/9] arm64: add kdump support AKASHI Takahiro
` (2 preceding siblings ...)
2016-07-26 7:56 ` [PATCH v23 3/9] arm64: limit memory regions based on DT property, usable-memory-range AKASHI Takahiro
@ 2016-07-26 7:56 ` AKASHI Takahiro
2016-07-26 7:56 ` [PATCH v23 5/9] arm64: kdump: add kdump support AKASHI Takahiro
` (5 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: AKASHI Takahiro @ 2016-07-26 7:56 UTC (permalink / raw)
To: linux-arm-kernel
Primary kernel calls machine_crash_shutdown() to shut down non-boot cpus
and save registers' status in per-cpu ELF notes before starting crash
dump kernel. See kernel_kexec().
Even if not all secondary cpus have shut down, we do kdump anyway.
As we don't have to make non-boot(crashed) cpus offline (to preserve
correct status of cpus at crash dump) before shutting down, this patch
also adds a variant of smp_send_stop().
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
arch/arm64/include/asm/hardirq.h | 2 +-
arch/arm64/include/asm/kexec.h | 41 ++++++++++++++++++++++++-
arch/arm64/include/asm/smp.h | 2 ++
arch/arm64/kernel/machine_kexec.c | 56 ++++++++++++++++++++++++++++++++--
arch/arm64/kernel/smp.c | 63 +++++++++++++++++++++++++++++++++++++++
5 files changed, 159 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/hardirq.h b/arch/arm64/include/asm/hardirq.h
index 8740297..1473fc2 100644
--- a/arch/arm64/include/asm/hardirq.h
+++ b/arch/arm64/include/asm/hardirq.h
@@ -20,7 +20,7 @@
#include <linux/threads.h>
#include <asm/irq.h>
-#define NR_IPI 6
+#define NR_IPI 7
typedef struct {
unsigned int __softirq_pending;
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 04744dc..a908958 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -40,7 +40,46 @@
static inline void crash_setup_regs(struct pt_regs *newregs,
struct pt_regs *oldregs)
{
- /* Empty routine needed to avoid build errors. */
+ if (oldregs) {
+ memcpy(newregs, oldregs, sizeof(*newregs));
+ } else {
+ u64 tmp1, tmp2;
+
+ __asm__ __volatile__ (
+ "stp x0, x1, [%2, #16 * 0]\n"
+ "stp x2, x3, [%2, #16 * 1]\n"
+ "stp x4, x5, [%2, #16 * 2]\n"
+ "stp x6, x7, [%2, #16 * 3]\n"
+ "stp x8, x9, [%2, #16 * 4]\n"
+ "stp x10, x11, [%2, #16 * 5]\n"
+ "stp x12, x13, [%2, #16 * 6]\n"
+ "stp x14, x15, [%2, #16 * 7]\n"
+ "stp x16, x17, [%2, #16 * 8]\n"
+ "stp x18, x19, [%2, #16 * 9]\n"
+ "stp x20, x21, [%2, #16 * 10]\n"
+ "stp x22, x23, [%2, #16 * 11]\n"
+ "stp x24, x25, [%2, #16 * 12]\n"
+ "stp x26, x27, [%2, #16 * 13]\n"
+ "stp x28, x29, [%2, #16 * 14]\n"
+ "mov %0, sp\n"
+ "stp x30, %0, [%2, #16 * 15]\n"
+
+ "/* faked current PSTATE */\n"
+ "mrs %0, CurrentEL\n"
+ "mrs %1, DAIF\n"
+ "orr %0, %0, %1\n"
+ "mrs %1, NZCV\n"
+ "orr %0, %0, %1\n"
+
+ /* pc */
+ "adr %1, 1f\n"
+ "1:\n"
+ "stp %1, %0, [%2, #16 * 16]\n"
+ : "=r" (tmp1), "=r" (tmp2), "+r" (newregs)
+ :
+ : "memory"
+ );
+ }
}
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index 0226447..6b0f2c7 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -136,6 +136,8 @@ static inline void cpu_panic_kernel(void)
*/
bool cpus_are_stuck_in_kernel(void);
+extern void smp_send_crash_stop(void);
+
#endif /* ifndef __ASSEMBLY__ */
#endif /* ifndef __ASM_SMP_H */
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index bc96c8a..8ac9dba8 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -9,6 +9,9 @@
* published by the Free Software Foundation.
*/
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
#include <linux/kexec.h>
#include <linux/smp.h>
@@ -22,6 +25,7 @@
extern const unsigned char arm64_relocate_new_kernel[];
extern const unsigned long arm64_relocate_new_kernel_size;
+bool in_crash_kexec;
static unsigned long kimage_start;
/**
@@ -148,7 +152,8 @@ void machine_kexec(struct kimage *kimage)
/*
* New cpus may have become stuck_in_kernel after we loaded the image.
*/
- BUG_ON(cpus_are_stuck_in_kernel() || (num_online_cpus() > 1));
+ BUG_ON((cpus_are_stuck_in_kernel() || (num_online_cpus() > 1)) &&
+ !WARN_ON(in_crash_kexec));
reboot_code_buffer_phys = page_to_phys(kimage->control_code_page);
reboot_code_buffer = phys_to_virt(reboot_code_buffer_phys);
@@ -200,13 +205,58 @@ void machine_kexec(struct kimage *kimage)
* relocation is complete.
*/
- cpu_soft_restart(1, reboot_code_buffer_phys, kimage->head,
+ cpu_soft_restart(!in_crash_kexec, reboot_code_buffer_phys, kimage->head,
kimage_start, 0);
BUG(); /* Should never get here. */
}
+static void machine_kexec_mask_interrupts(void)
+{
+ unsigned int i;
+ struct irq_desc *desc;
+
+ for_each_irq_desc(i, desc) {
+ struct irq_chip *chip;
+ int ret;
+
+ chip = irq_desc_get_chip(desc);
+ if (!chip)
+ continue;
+
+ /*
+ * First try to remove the active state. If this
+ * fails, try to EOI the interrupt.
+ */
+ ret = irq_set_irqchip_state(i, IRQCHIP_STATE_ACTIVE, false);
+
+ if (ret && irqd_irq_inprogress(&desc->irq_data) &&
+ chip->irq_eoi)
+ chip->irq_eoi(&desc->irq_data);
+
+ if (chip->irq_mask)
+ chip->irq_mask(&desc->irq_data);
+
+ if (chip->irq_disable && !irqd_irq_disabled(&desc->irq_data))
+ chip->irq_disable(&desc->irq_data);
+ }
+}
+
+/**
+ * machine_crash_shutdown - shutdown non-crashing cpus and save registers
+ */
void machine_crash_shutdown(struct pt_regs *regs)
{
- /* Empty routine needed to avoid build errors. */
+ local_irq_disable();
+
+ in_crash_kexec = true;
+
+ /* shutdown non-crashing cpus */
+ smp_send_crash_stop();
+
+ /* for crashing cpu */
+ crash_save_cpu(regs, smp_processor_id());
+ machine_kexec_mask_interrupts();
+
+ pr_info("Starting crashdump kernel...\n");
}
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 490db85..102635c 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -37,6 +37,7 @@
#include <linux/completion.h>
#include <linux/of.h>
#include <linux/irq_work.h>
+#include <linux/kexec.h>
#include <asm/alternative.h>
#include <asm/atomic.h>
@@ -71,6 +72,7 @@ enum ipi_msg_type {
IPI_RESCHEDULE,
IPI_CALL_FUNC,
IPI_CPU_STOP,
+ IPI_CPU_CRASH_STOP,
IPI_TIMER,
IPI_IRQ_WORK,
IPI_WAKEUP
@@ -732,6 +734,7 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = {
S(IPI_RESCHEDULE, "Rescheduling interrupts"),
S(IPI_CALL_FUNC, "Function call interrupts"),
S(IPI_CPU_STOP, "CPU stop interrupts"),
+ S(IPI_CPU_CRASH_STOP, "CPU stop (for crash dump) interrupts"),
S(IPI_TIMER, "Timer broadcast interrupts"),
S(IPI_IRQ_WORK, "IRQ work interrupts"),
S(IPI_WAKEUP, "CPU wake-up interrupts"),
@@ -806,6 +809,29 @@ static void ipi_cpu_stop(unsigned int cpu)
cpu_relax();
}
+#ifdef CONFIG_KEXEC_CORE
+static atomic_t waiting_for_crash_ipi;
+#endif
+
+static void ipi_cpu_crash_stop(unsigned int cpu, struct pt_regs *regs)
+{
+#ifdef CONFIG_KEXEC_CORE
+ crash_save_cpu(regs, cpu);
+
+ atomic_dec(&waiting_for_crash_ipi);
+
+ local_irq_disable();
+
+#ifdef CONFIG_HOTPLUG_CPU
+ if (cpu_ops[cpu]->cpu_die)
+ cpu_ops[cpu]->cpu_die(cpu);
+#endif
+
+ /* just in case */
+ cpu_park_loop();
+#endif
+}
+
/*
* Main handler for inter-processor interrupts
*/
@@ -836,6 +862,15 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
irq_exit();
break;
+ case IPI_CPU_CRASH_STOP:
+ if (IS_ENABLED(CONFIG_KEXEC_CORE)) {
+ irq_enter();
+ ipi_cpu_crash_stop(cpu, regs);
+
+ unreachable();
+ }
+ break;
+
#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
case IPI_TIMER:
irq_enter();
@@ -908,6 +943,34 @@ void smp_send_stop(void)
cpumask_pr_args(cpu_online_mask));
}
+#ifdef CONFIG_KEXEC_CORE
+void smp_send_crash_stop(void)
+{
+ cpumask_t mask;
+ unsigned long timeout;
+
+ if (num_online_cpus() == 1)
+ return;
+
+ cpumask_copy(&mask, cpu_online_mask);
+ cpumask_clear_cpu(smp_processor_id(), &mask);
+
+ atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
+
+ pr_crit("SMP: stopping secondary CPUs\n");
+ smp_cross_call(&mask, IPI_CPU_CRASH_STOP);
+
+ /* Wait up to one second for other CPUs to stop */
+ timeout = USEC_PER_SEC;
+ while ((atomic_read(&waiting_for_crash_ipi) > 0) && timeout--)
+ udelay(1);
+
+ if (atomic_read(&waiting_for_crash_ipi) > 0)
+ pr_warning("SMP: failed to stop secondary CPUs %*pbl\n",
+ cpumask_pr_args(cpu_online_mask));
+}
+#endif
+
/*
* not supported here
*/
--
2.9.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH v23 5/9] arm64: kdump: add kdump support
2016-07-26 7:56 [PATCH v23 0/9] arm64: add kdump support AKASHI Takahiro
` (3 preceding siblings ...)
2016-07-26 7:56 ` [PATCH v23 4/9] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
@ 2016-07-26 7:56 ` AKASHI Takahiro
2016-07-26 7:56 ` [PATCH v23 6/9] arm64: kdump: add VMCOREINFO's for user-space coredump tools AKASHI Takahiro
` (4 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: AKASHI Takahiro @ 2016-07-26 7:56 UTC (permalink / raw)
To: linux-arm-kernel
On crash dump kernel, all the information about primary kernel's system
memory (core image) is available in elf core header.
The primary kernel will set aside this header with reserve_elfcorehdr()
at boot time and inform crash dump kernel of its location via a new
device-tree property, "linux,elfcorehdr".
Please note that all other architectures use traditional "elfcorehdr="
kernel parameter for this purpose.
Then crash dump kernel will access the primary kernel's memory with
copy_oldmem_page(), which reads one page by ioremap'ing it since it does
not reside in linear mapping on crash dump kernel.
We also need our own elfcorehdr_read() here since the header is placed
within crash dump kernel's usable memory.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
arch/arm64/Kconfig | 11 +++++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/crash_dump.c | 71 ++++++++++++++++++++++++++++++++++++++++++
arch/arm64/mm/init.c | 54 ++++++++++++++++++++++++++++++++
4 files changed, 137 insertions(+)
create mode 100644 arch/arm64/kernel/crash_dump.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index ac4746f..0aa521d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -678,6 +678,17 @@ config KEXEC
but it is independent of the system firmware. And like a reboot
you can start any kernel with it, not just Linux.
+config CRASH_DUMP
+ bool "Build kdump crash kernel"
+ help
+ Generate crash dump after being started by kexec. This should
+ be normally only set in special crash dump kernels which are
+ loaded in the main kernel with kexec-tools into a specially
+ reserved region and then later executed after a crash by
+ kdump/kexec.
+
+ For more details see Documentation/kdump/kdump.txt
+
config XEN_DOM0
def_bool y
depends on XEN
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 0b9e49a..9e11910 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -47,6 +47,7 @@ arm64-obj-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
arm64-obj-$(CONFIG_HIBERNATION) += hibernate.o hibernate-asm.o
arm64-obj-$(CONFIG_KEXEC) += machine_kexec.o relocate_kernel.o \
cpu-reset.o
+arm64-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-y += $(arm64-obj-y) vdso/ probes/
obj-m += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/crash_dump.c b/arch/arm64/kernel/crash_dump.c
new file mode 100644
index 0000000..2dc54d1
--- /dev/null
+++ b/arch/arm64/kernel/crash_dump.c
@@ -0,0 +1,71 @@
+/*
+ * Routines for doing kexec-based kdump
+ *
+ * Copyright (C) 2014 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.
+ */
+
+#include <linux/crash_dump.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+#include <linux/memblock.h>
+#include <linux/uaccess.h>
+#include <asm/memory.h>
+
+/**
+ * copy_oldmem_page() - copy one page from old kernel memory
+ * @pfn: page frame number to be copied
+ * @buf: buffer where the copied page is placed
+ * @csize: number of bytes to copy
+ * @offset: offset in bytes into the page
+ * @userbuf: if set, @buf is in a user address space
+ *
+ * This function copies one page from old kernel memory into buffer pointed by
+ * @buf. If @buf is in userspace, set @userbuf to %1. Returns number of bytes
+ * copied or negative error in case of failure.
+ */
+ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
+ size_t csize, unsigned long offset,
+ int userbuf)
+{
+ void *vaddr;
+
+ if (!csize)
+ return 0;
+
+ vaddr = ioremap_cache(__pfn_to_phys(pfn), PAGE_SIZE);
+ if (!vaddr)
+ return -ENOMEM;
+
+ if (userbuf) {
+ if (copy_to_user(buf, vaddr + offset, csize)) {
+ iounmap(vaddr);
+ return -EFAULT;
+ }
+ } else {
+ memcpy(buf, vaddr + offset, csize);
+ }
+
+ iounmap(vaddr);
+
+ return csize;
+}
+
+/**
+ * elfcorehdr_read - read from ELF core header
+ * @buf: buffer where the data is placed
+ * @csize: number of bytes to read
+ * @ppos: address in the memory
+ *
+ * This function reads @count bytes from elf core header which exists
+ * on crash dump kernel's memory.
+ */
+ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos)
+{
+ memcpy(buf, phys_to_virt((phys_addr_t)*ppos), count);
+ return count;
+}
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 8699a8ea..f415104 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -36,6 +36,7 @@
#include <linux/efi.h>
#include <linux/swiotlb.h>
#include <linux/kexec.h>
+#include <linux/crash_dump.h>
#include <asm/boot.h>
#include <asm/fixmap.h>
@@ -186,6 +187,57 @@ static void __init reserve_crashkernel(void)
}
#endif /* CONFIG_KEXEC_CORE */
+#ifdef CONFIG_CRASH_DUMP
+static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
+ const char *uname, int depth, void *data)
+{
+ const __be32 *reg;
+ int len;
+
+ if (depth != 1 || strcmp(uname, "chosen") != 0)
+ return 0;
+
+ reg = of_get_flat_dt_prop(node, "linux,elfcorehdr", &len);
+ if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
+ return 1;
+
+ elfcorehdr_addr = dt_mem_next_cell(dt_root_addr_cells, ®);
+ elfcorehdr_size = dt_mem_next_cell(dt_root_size_cells, ®);
+
+ return 1;
+}
+
+/*
+ * reserve_elfcorehdr() - reserves memory for elf core header
+ *
+ * This function reserves elf core header given in "elfcorehdr=" kernel
+ * command line parameter. This region contains all the information about
+ * primary kernel's core image and is used by a dump capture kernel to
+ * access the system memory on primary kernel.
+ */
+static void __init reserve_elfcorehdr(void)
+{
+ of_scan_flat_dt(early_init_dt_scan_elfcorehdr, NULL);
+
+ if (!elfcorehdr_size)
+ return;
+
+ if (memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)) {
+ pr_warn("elfcorehdr is overlapped\n");
+ return;
+ }
+
+ memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
+
+ pr_info("Reserving %lldKB of memory@0x%llx for elfcorehdr\n",
+ elfcorehdr_size >> 10, elfcorehdr_addr);
+}
+#else
+static void __init reserve_elfcorehdr(void)
+{
+ ;
+}
+#endif /* CONFIG_CRASH_DUMP */
/*
* Return the maximum physical address for ZONE_DMA (DMA_BIT_MASK(32)). It
* currently assumes that for memory starting above 4G, 32-bit devices will
@@ -444,6 +496,8 @@ void __init arm64_memblock_init(void)
reserve_crashkernel();
+ reserve_elfcorehdr();
+
dma_contiguous_reserve(arm64_dma_phys_limit);
memblock_allow_resize();
--
2.9.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH v23 6/9] arm64: kdump: add VMCOREINFO's for user-space coredump tools
2016-07-26 7:56 [PATCH v23 0/9] arm64: add kdump support AKASHI Takahiro
` (4 preceding siblings ...)
2016-07-26 7:56 ` [PATCH v23 5/9] arm64: kdump: add kdump support AKASHI Takahiro
@ 2016-07-26 7:56 ` AKASHI Takahiro
2016-07-26 7:56 ` [PATCH v23 7/9] arm64: kdump: enable kdump in the arm64 defconfig AKASHI Takahiro
` (3 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: AKASHI Takahiro @ 2016-07-26 7:56 UTC (permalink / raw)
To: linux-arm-kernel
For the current crash utility, we need to know, at least,
- kimage_voffset
- PHYS_OFFSET
to handle the contents of core dump file (/proc/vmcore) correctly due to
the introduction of KASLR (CONFIG_RANDOMIZE_BASE) in v4.6.
This patch puts them as VMCOREINFO's into the file.
- VA_BITS
is also added for makedumpfile command.
More VMCOREINFO's may be added later.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
arch/arm64/kernel/machine_kexec.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index 8ac9dba8..38b4411 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -17,6 +17,7 @@
#include <asm/cacheflush.h>
#include <asm/cpu_ops.h>
+#include <asm/memory.h>
#include <asm/mmu_context.h>
#include "cpu-reset.h"
@@ -260,3 +261,13 @@ void machine_crash_shutdown(struct pt_regs *regs)
pr_info("Starting crashdump kernel...\n");
}
+
+void arch_crash_save_vmcoreinfo(void)
+{
+ VMCOREINFO_NUMBER(VA_BITS);
+ /* Please note VMCOREINFO_NUMBER() uses "%d", not "%x" */
+ vmcoreinfo_append_str("NUMBER(kimage_voffset)=0x%llx\n",
+ kimage_voffset);
+ vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n",
+ PHYS_OFFSET);
+}
--
2.9.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH v23 7/9] arm64: kdump: enable kdump in the arm64 defconfig
2016-07-26 7:56 [PATCH v23 0/9] arm64: add kdump support AKASHI Takahiro
` (5 preceding siblings ...)
2016-07-26 7:56 ` [PATCH v23 6/9] arm64: kdump: add VMCOREINFO's for user-space coredump tools AKASHI Takahiro
@ 2016-07-26 7:56 ` AKASHI Takahiro
2016-07-26 7:56 ` [PATCH v23 8/9] arm64: kdump: update a kernel doc AKASHI Takahiro
` (2 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: AKASHI Takahiro @ 2016-07-26 7:56 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 4ed4756..aa3e1dd 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -71,6 +71,7 @@ CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_CMA=y
CONFIG_XEN=y
CONFIG_KEXEC=y
+CONFIG_CRASH_DUMP=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_COMPAT=y
CONFIG_CPU_IDLE=y
--
2.9.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH v23 8/9] arm64: kdump: update a kernel doc
2016-07-26 7:56 [PATCH v23 0/9] arm64: add kdump support AKASHI Takahiro
` (6 preceding siblings ...)
2016-07-26 7:56 ` [PATCH v23 7/9] arm64: kdump: enable kdump in the arm64 defconfig AKASHI Takahiro
@ 2016-07-26 7:56 ` AKASHI Takahiro
2016-07-26 8:02 ` [PATCH v23 9/9] Documentation: dt: chosen properties for arm64 kdump AKASHI Takahiro
2016-07-26 8:09 ` [PATCH v23 0/9] arm64: add kdump support AKASHI Takahiro
9 siblings, 0 replies; 21+ messages in thread
From: AKASHI Takahiro @ 2016-07-26 7:56 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds arch specific descriptions about kdump usage on arm64
to kdump.txt.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
---
Documentation/kdump/kdump.txt | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88ff63d..c090531 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to
a remote system.
Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64,
-s390x and arm architectures.
+s390x, arm and arm64 architectures.
When the system kernel boots, it reserves a small section of memory for
the dump-capture kernel. This ensures that ongoing Direct Memory Access
@@ -249,6 +249,13 @@ Dump-capture kernel config options (Arch Dependent, arm)
AUTO_ZRELADDR=y
+Dump-capture kernel config options (Arch Dependent, arm64)
+----------------------------------------------------------
+
+- Please note that kvm of the dump-capture kernel will not be enabled
+ on non-VHE systems even if it is configured. This is because the CPU
+ cannot be reset to EL2 on panic.
+
Extended crashkernel syntax
===========================
@@ -305,6 +312,8 @@ Boot into System Kernel
kernel will automatically locate the crash kernel image within the
first 512MB of RAM if X is not given.
+ On arm64, use "crashkernel=Y[@X]". Note that the start address of
+ the kernel, X if explicitly specified, must be aligned to 2MiB (0x200000).
Load the Dump-capture Kernel
============================
@@ -327,6 +336,8 @@ For s390x:
- Use image or bzImage
For arm:
- Use zImage
+For arm64:
+ - Use vmlinux or Image
If you are using a uncompressed vmlinux image then use following command
to load dump-capture kernel.
@@ -370,6 +381,9 @@ For s390x:
For arm:
"1 maxcpus=1 reset_devices"
+For arm64:
+ "1 maxcpus=1 reset_devices"
+
Notes on loading the dump-capture kernel:
* By default, the ELF headers are stored in ELF64 format to support
--
2.9.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH v23 9/9] Documentation: dt: chosen properties for arm64 kdump
2016-07-26 7:56 [PATCH v23 0/9] arm64: add kdump support AKASHI Takahiro
` (7 preceding siblings ...)
2016-07-26 7:56 ` [PATCH v23 8/9] arm64: kdump: update a kernel doc AKASHI Takahiro
@ 2016-07-26 8:02 ` AKASHI Takahiro
2016-07-27 15:09 ` Rob Herring
2016-07-26 8:09 ` [PATCH v23 0/9] arm64: add kdump support AKASHI Takahiro
9 siblings, 1 reply; 21+ messages in thread
From: AKASHI Takahiro @ 2016-07-26 8:02 UTC (permalink / raw)
To: linux-arm-kernel
From: James Morse <james.morse@arm.com>
Add documentation for
linux,crashkernel-base and crashkernel-size,
linux,usable-memory-range, and
linux,elfcorehdr
used by arm64 kexec/kdump to decribe the kdump reserved area, and
the elfcorehdr's location within it.
Signed-off-by: James Morse <james.morse@arm.com>
[takahiro.akashi at linaro.org:
renamed "usable-memory" to "usable-memory-range",
added "linux,crashkernel-base" and "-size" ]
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
---
Documentation/devicetree/bindings/chosen.txt | 45 ++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 6ae9d82..d7a3a86 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -52,3 +52,48 @@ This property is set (currently only on PowerPC, and only needed on
book3e) by some versions of kexec-tools to tell the new kernel that it
is being booted by kexec, as the booting environment may differ (e.g.
a different secondary CPU release mechanism)
+
+linux,crashkernel-base
+linux,crashkernel-size
+----------------------
+These properties are set (on PowerPC and arm64) during kdump to tell
+use-space tools, like kexec-tools, the base address of the crash-dump
+kernel's reserved area of memory and the size. e.g.
+
+/ {
+ chosen {
+ linux,crashkernel-base = <0x9 0xf0000000>;
+ linux,crashkernel-size = <0x0 0x10000000>;
+ };
+};
+
+linux,usable-memory-range
+-------------------------
+
+This property is set (currently only on arm64) during kdump to tell
+the crash-dump kernel the base address of its reserved area of memory,
+and the size. e.g.
+
+/ {
+ chosen {
+ linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>;
+ };
+};
+
+Please note that, if this property is present, any memory regions under
+"memory" nodes will be ignored.
+
+linux,elfcorehdr
+----------------
+
+This property is set (currently only on arm64) during kdump to tell
+the crash-dump kernel the address and size of the elfcorehdr that describes
+the old kernel's memory as an elf file. This memory must reside within
+the area described by 'linux,usable-memory-range'. e.g.
+
+/ {
+ chosen {
+ linux,usable-memory = <0x9 0xf0000000 0x0 0x10000000>;
+ linux,elfcorehdr = <0x9 0xfffff000 0x0 0x800>;
+ };
+};
--
2.9.0
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH v23 9/9] Documentation: dt: chosen properties for arm64 kdump
2016-07-26 8:02 ` [PATCH v23 9/9] Documentation: dt: chosen properties for arm64 kdump AKASHI Takahiro
@ 2016-07-27 15:09 ` Rob Herring
[not found] ` <20160728075511.GA7995@linaro.org>
0 siblings, 1 reply; 21+ messages in thread
From: Rob Herring @ 2016-07-27 15:09 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 26, 2016 at 05:02:06PM +0900, AKASHI Takahiro wrote:
> From: James Morse <james.morse@arm.com>
>
> Add documentation for
> linux,crashkernel-base and crashkernel-size,
> linux,usable-memory-range, and
> linux,elfcorehdr
> used by arm64 kexec/kdump to decribe the kdump reserved area, and
> the elfcorehdr's location within it.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> [takahiro.akashi at linaro.org:
> renamed "usable-memory" to "usable-memory-range",
> added "linux,crashkernel-base" and "-size" ]
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> ---
> Documentation/devicetree/bindings/chosen.txt | 45 ++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
> index 6ae9d82..d7a3a86 100644
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -52,3 +52,48 @@ This property is set (currently only on PowerPC, and only needed on
> book3e) by some versions of kexec-tools to tell the new kernel that it
> is being booted by kexec, as the booting environment may differ (e.g.
> a different secondary CPU release mechanism)
> +
> +linux,crashkernel-base
> +linux,crashkernel-size
> +----------------------
> +These properties are set (on PowerPC and arm64) during kdump to tell
> +use-space tools, like kexec-tools, the base address of the crash-dump
s/use/user/
Ideally, userspace should not care whether this comes from DT, kernel
command-line or somewhere else and should be exposed in some source
independent way. However, that's not really the problem for the binding.
> +kernel's reserved area of memory and the size. e.g.
> +
> +/ {
> + chosen {
> + linux,crashkernel-base = <0x9 0xf0000000>;
> + linux,crashkernel-size = <0x0 0x10000000>;
> + };
> +};
> +
> +linux,usable-memory-range
> +-------------------------
> +
> +This property is set (currently only on arm64) during kdump to tell
> +the crash-dump kernel the base address of its reserved area of memory,
> +and the size. e.g.
> +
> +/ {
> + chosen {
> + linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>;
This is the same range as linux,crashkernel-*, but used by the 2nd
kernel? Why not just update the memory node or use command line mem=
parameter?
Why has PPC not need this and ARM does?
> + };
> +};
> +
> +Please note that, if this property is present, any memory regions under
> +"memory" nodes will be ignored.
> +
> +linux,elfcorehdr
> +----------------
> +
> +This property is set (currently only on arm64) during kdump to tell
> +the crash-dump kernel the address and size of the elfcorehdr that describes
> +the old kernel's memory as an elf file. This memory must reside within
> +the area described by 'linux,usable-memory-range'. e.g.
> +
> +/ {
> + chosen {
> + linux,usable-memory = <0x9 0xf0000000 0x0 0x10000000>;
> + linux,elfcorehdr = <0x9 0xfffff000 0x0 0x800>;
> + };
> +};
> --
> 2.9.0
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v23 0/9] arm64: add kdump support
2016-07-26 7:56 [PATCH v23 0/9] arm64: add kdump support AKASHI Takahiro
` (8 preceding siblings ...)
2016-07-26 8:02 ` [PATCH v23 9/9] Documentation: dt: chosen properties for arm64 kdump AKASHI Takahiro
@ 2016-07-26 8:09 ` AKASHI Takahiro
2016-07-29 16:26 ` Ruslan Bilovol
9 siblings, 1 reply; 21+ messages in thread
From: AKASHI Takahiro @ 2016-07-26 8:09 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 26, 2016 at 04:56:51PM +0900, AKASHI Takahiro wrote:
> This patch series adds kdump support on arm64.
>
> To load a crash-dump kernel to the systems, a series of patches to
> kexec-tools, which have not yet been merged upstream, are needed.
> Please pick Geoff's kexec patches [1] and my kdump patches [2].
>
> To examine vmcore (/proc/vmcore) on a crash-dump kernel, you can use
> - crash utility (coming v7.1.6 or later) [3]
> (Necessary patches have already been queued in the master.)
>
> [1] http://lists.infradead.org/pipermail/kexec/2016-July/016532.html
> [2] TBD
See my kexec-tools patches in:
http://lists.infradead.org/pipermail/kexec/2016-July/016642.html
Thanks,
-Takahiro AKASHI
> [3] https://github.com/crash-utility/crash.git
>
> Changes for v23 (July 26, 2016):
>
> o Move memblock_reserve() to a single place in reserve_crashkernel()
> o Use cpu_park_loop() in ipi_cpu_crash_stop()
> o Always enforce ARCH_LOW_ADDRESS_LIMIT to the memory range of crash kernel
> o Re-implement fdt_enforce_memory_region() to remove non-reserve regions
> (for ACPI) from usable memory at crash kernel
>
> Changes for v22 (July 12, 2016):
>
> o Export "crashkernel-base" and "crashkernel-size" via device-tree,
> and add some descriptions about them in chosen.txt
> o Rename "usable-memory" to "usable-memory-range" to avoid inconsistency
> with powerpc's "usable-memory"
> o Make cosmetic changes regarding "ifdef" usage
> o Correct some wordings in kdump.txt
>
> Changes for v21 (July 6, 2016):
>
> o Remove kexec patches.
> o Rebase to arm64's for-next/core (Linux-4.7-rc4 based).
> o Clarify the description about kvm in kdump.txt.
>
> See the following link [3] for older changes:
> [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/438780.html
>
> AKASHI Takahiro (8):
> arm64: kdump: reserve memory for crash dump kernel
> memblock: add memblock_cap_memory_range()
> arm64: limit memory regions based on DT property, usable-memory-range
> arm64: kdump: implement machine_crash_shutdown()
> arm64: kdump: add kdump support
> arm64: kdump: add VMCOREINFO's for user-space coredump tools
> arm64: kdump: enable kdump in the arm64 defconfig
> arm64: kdump: update a kernel doc
>
> James Morse (1):
> Documentation: dt: chosen properties for arm64 kdump
>
> Documentation/devicetree/bindings/chosen.txt | 45 ++++++
> Documentation/kdump/kdump.txt | 16 ++-
> arch/arm64/Kconfig | 11 ++
> arch/arm64/configs/defconfig | 1 +
> arch/arm64/include/asm/hardirq.h | 2 +-
> arch/arm64/include/asm/kexec.h | 41 +++++-
> arch/arm64/include/asm/smp.h | 2 +
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/crash_dump.c | 71 ++++++++++
> arch/arm64/kernel/machine_kexec.c | 67 ++++++++-
> arch/arm64/kernel/setup.c | 7 +-
> arch/arm64/kernel/smp.c | 63 +++++++++
> arch/arm64/mm/init.c | 202 +++++++++++++++++++++++++++
> include/linux/memblock.h | 1 +
> mm/memblock.c | 28 ++++
> 15 files changed, 551 insertions(+), 7 deletions(-)
> create mode 100644 arch/arm64/kernel/crash_dump.c
>
> --
> 2.9.0
>
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH v23 0/9] arm64: add kdump support
2016-07-26 8:09 ` [PATCH v23 0/9] arm64: add kdump support AKASHI Takahiro
@ 2016-07-29 16:26 ` Ruslan Bilovol
2016-07-29 17:08 ` Geoff Levand
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Ruslan Bilovol @ 2016-07-29 16:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Tue, Jul 26, 2016 at 11:09 AM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> On Tue, Jul 26, 2016 at 04:56:51PM +0900, AKASHI Takahiro wrote:
>> This patch series adds kdump support on arm64.
>>
>> To load a crash-dump kernel to the systems, a series of patches to
>> kexec-tools, which have not yet been merged upstream, are needed.
>> Please pick Geoff's kexec patches [1] and my kdump patches [2].
>>
>> To examine vmcore (/proc/vmcore) on a crash-dump kernel, you can use
>> - crash utility (coming v7.1.6 or later) [3]
>> (Necessary patches have already been queued in the master.)
>>
>> [1] http://lists.infradead.org/pipermail/kexec/2016-July/016532.html
>> [2] TBD
>
> See my kexec-tools patches in:
> http://lists.infradead.org/pipermail/kexec/2016-July/016642.html
I tired this patch series with mentioned Geoff's kexec patches and
your kdump patches, but unfortunately it doesn't work for me.
While I can successfully load and kexec the kernel ('kexec --load' +
'kexec -e'), same combination of kernel+ramdisk+dtb doesn't boot
if I do kdump combination ('kexec -p' + sysrq crash), there is no
any output after sysrq crash trace.
Unfortunately I don't have any debugger here for deep investigation
of this issue.
Also for some reason in case of 'load and kexec the kernel' it
takes 1-2 minutes to start booting after I do kexec -e, need to
investigate it further.
Which hardware do you use for validating your patches?
Also, could you please share exact commands you use for
kdump validation?
Best regaerds,
Ruslan
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH v23 0/9] arm64: add kdump support
2016-07-29 16:26 ` Ruslan Bilovol
@ 2016-07-29 17:08 ` Geoff Levand
2016-07-29 17:17 ` Pratyush Anand
2016-07-29 17:13 ` Pratyush Anand
2016-08-04 5:20 ` AKASHI Takahiro
2 siblings, 1 reply; 21+ messages in thread
From: Geoff Levand @ 2016-07-29 17:08 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Fri, 2016-07-29 at 19:26 +0300, Ruslan Bilovol wrote:
> Also for some reason in case of 'load and kexec the kernel' it
> takes 1-2 minutes to start booting after I do kexec -e, need to
> investigate it further.
You could try my patch ("purgatory: Change default sha256
optimization to -O2") in my master branch:
https://git.kernel.org/cgit/linux/kernel/git/geoff/kexec-tools.git/log/
Other have said it helped.
-Geoff
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH v23 0/9] arm64: add kdump support
2016-07-29 16:26 ` Ruslan Bilovol
2016-07-29 17:08 ` Geoff Levand
@ 2016-07-29 17:13 ` Pratyush Anand
2016-08-01 4:37 ` AKASHI Takahiro
2016-08-04 5:20 ` AKASHI Takahiro
2 siblings, 1 reply; 21+ messages in thread
From: Pratyush Anand @ 2016-07-29 17:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ruslan,
On 29/07/2016:07:26:03 PM, Ruslan Bilovol wrote:
> Hi,
>
> On Tue, Jul 26, 2016 at 11:09 AM, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> > On Tue, Jul 26, 2016 at 04:56:51PM +0900, AKASHI Takahiro wrote:
> >> This patch series adds kdump support on arm64.
> >>
> >> To load a crash-dump kernel to the systems, a series of patches to
> >> kexec-tools, which have not yet been merged upstream, are needed.
> >> Please pick Geoff's kexec patches [1] and my kdump patches [2].
> >>
> >> To examine vmcore (/proc/vmcore) on a crash-dump kernel, you can use
> >> - crash utility (coming v7.1.6 or later) [3]
> >> (Necessary patches have already been queued in the master.)
> >>
> >> [1] http://lists.infradead.org/pipermail/kexec/2016-July/016532.html
> >> [2] TBD
> >
> > See my kexec-tools patches in:
> > http://lists.infradead.org/pipermail/kexec/2016-July/016642.html
>
> I tired this patch series with mentioned Geoff's kexec patches and
> your kdump patches, but unfortunately it doesn't work for me.
>
> While I can successfully load and kexec the kernel ('kexec --load' +
> 'kexec -e'), same combination of kernel+ramdisk+dtb doesn't boot
> if I do kdump combination ('kexec -p' + sysrq crash), there is no
> any output after sysrq crash trace.
> Unfortunately I don't have any debugger here for deep investigation
> of this issue.
Which type of image do you have? I did face issue with binary image which I
fixed in my branch, while elf would work fine for kdump as well.
>
> Also for some reason in case of 'load and kexec the kernel' it
> takes 1-2 minutes to start booting after I do kexec -e, need to
> investigate it further.
Because, D-cache is disabled.
>
> Which hardware do you use for validating your patches?
>
> Also, could you please share exact commands you use for
> kdump validation?
Well, I have some patches for D-cache enabling, which will be sent for review
after these set of kexec and kdump patches are merged.
Meanwhile, you can use them and give your feedback. They are here:
https://github.com/pratyushanand/kexec-tools.git : upstream_arm64_devel
I use following command with my test branch. You can ignore --port and
--port-lsr in your setup. You may use --enable-dcache and let me know if it
works for you and improves execution speed. You may need to change vmlinux and
inird name as per your setup.
for kexec test:
kexec -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`.img
--reuse-cmdline --enable-dcache --port=0x1c020000
--port-lsr=0x1c020014,0x60;kexec -e
for kdump test:
kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`kdump.img
--reuse-cmdline --enable-dcache --port=0x1c020000 --port-lsr=0x1c020014,0x60
--append="irqpoll maxcpus=1 reset_devices"; echo c > /proc/sysrq-trigger
~Pratyush
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH v23 0/9] arm64: add kdump support
2016-07-29 17:13 ` Pratyush Anand
@ 2016-08-01 4:37 ` AKASHI Takahiro
2016-08-01 6:21 ` Pratyush Anand
0 siblings, 1 reply; 21+ messages in thread
From: AKASHI Takahiro @ 2016-08-01 4:37 UTC (permalink / raw)
To: linux-arm-kernel
Pratyush,
On Fri, Jul 29, 2016 at 10:43:00PM +0530, Pratyush Anand wrote:
> Hi Ruslan,
>
> On 29/07/2016:07:26:03 PM, Ruslan Bilovol wrote:
> > Hi,
> >
> > On Tue, Jul 26, 2016 at 11:09 AM, AKASHI Takahiro
> > <takahiro.akashi@linaro.org> wrote:
> > > On Tue, Jul 26, 2016 at 04:56:51PM +0900, AKASHI Takahiro wrote:
> > >> This patch series adds kdump support on arm64.
> > >>
> > >> To load a crash-dump kernel to the systems, a series of patches to
> > >> kexec-tools, which have not yet been merged upstream, are needed.
> > >> Please pick Geoff's kexec patches [1] and my kdump patches [2].
> > >>
> > >> To examine vmcore (/proc/vmcore) on a crash-dump kernel, you can use
> > >> - crash utility (coming v7.1.6 or later) [3]
> > >> (Necessary patches have already been queued in the master.)
> > >>
> > >> [1] http://lists.infradead.org/pipermail/kexec/2016-July/016532.html
> > >> [2] TBD
> > >
> > > See my kexec-tools patches in:
> > > http://lists.infradead.org/pipermail/kexec/2016-July/016642.html
> >
> > I tired this patch series with mentioned Geoff's kexec patches and
> > your kdump patches, but unfortunately it doesn't work for me.
> >
> > While I can successfully load and kexec the kernel ('kexec --load' +
> > 'kexec -e'), same combination of kernel+ramdisk+dtb doesn't boot
> > if I do kdump combination ('kexec -p' + sysrq crash), there is no
> > any output after sysrq crash trace.
> > Unfortunately I don't have any debugger here for deep investigation
> > of this issue.
>
> Which type of image do you have? I did face issue with binary image which I
> fixed in my branch, while elf would work fine for kdump as well.
Can you describe in more details, please?
I don't see any problems with either vmlinux or image
in my environment.
Thanks,
-Takahiro AKASHI
> >
> > Also for some reason in case of 'load and kexec the kernel' it
> > takes 1-2 minutes to start booting after I do kexec -e, need to
> > investigate it further.
>
> Because, D-cache is disabled.
>
> >
> > Which hardware do you use for validating your patches?
> >
> > Also, could you please share exact commands you use for
> > kdump validation?
>
> Well, I have some patches for D-cache enabling, which will be sent for review
> after these set of kexec and kdump patches are merged.
>
> Meanwhile, you can use them and give your feedback. They are here:
> https://github.com/pratyushanand/kexec-tools.git : upstream_arm64_devel
>
> I use following command with my test branch. You can ignore --port and
> --port-lsr in your setup. You may use --enable-dcache and let me know if it
> works for you and improves execution speed. You may need to change vmlinux and
> inird name as per your setup.
>
> for kexec test:
> kexec -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`.img
> --reuse-cmdline --enable-dcache --port=0x1c020000
> --port-lsr=0x1c020014,0x60;kexec -e
>
> for kdump test:
> kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`kdump.img
> --reuse-cmdline --enable-dcache --port=0x1c020000 --port-lsr=0x1c020014,0x60
> --append="irqpoll maxcpus=1 reset_devices"; echo c > /proc/sysrq-trigger
>
> ~Pratyush
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH v23 0/9] arm64: add kdump support
2016-08-01 4:37 ` AKASHI Takahiro
@ 2016-08-01 6:21 ` Pratyush Anand
2016-08-01 6:46 ` AKASHI Takahiro
0 siblings, 1 reply; 21+ messages in thread
From: Pratyush Anand @ 2016-08-01 6:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Takahiro,
On 01/08/2016:01:37:26 PM, AKASHI Takahiro wrote:
> Pratyush,
>
> On Fri, Jul 29, 2016 at 10:43:00PM +0530, Pratyush Anand wrote:
> > Hi Ruslan,
> >
> > On 29/07/2016:07:26:03 PM, Ruslan Bilovol wrote:
> > > Hi,
> > >
> > > On Tue, Jul 26, 2016 at 11:09 AM, AKASHI Takahiro
> > > <takahiro.akashi@linaro.org> wrote:
> > > > On Tue, Jul 26, 2016 at 04:56:51PM +0900, AKASHI Takahiro wrote:
> > > >> This patch series adds kdump support on arm64.
> > > >>
> > > >> To load a crash-dump kernel to the systems, a series of patches to
> > > >> kexec-tools, which have not yet been merged upstream, are needed.
> > > >> Please pick Geoff's kexec patches [1] and my kdump patches [2].
> > > >>
> > > >> To examine vmcore (/proc/vmcore) on a crash-dump kernel, you can use
> > > >> - crash utility (coming v7.1.6 or later) [3]
> > > >> (Necessary patches have already been queued in the master.)
> > > >>
> > > >> [1] http://lists.infradead.org/pipermail/kexec/2016-July/016532.html
> > > >> [2] TBD
> > > >
> > > > See my kexec-tools patches in:
> > > > http://lists.infradead.org/pipermail/kexec/2016-July/016642.html
> > >
> > > I tired this patch series with mentioned Geoff's kexec patches and
> > > your kdump patches, but unfortunately it doesn't work for me.
> > >
> > > While I can successfully load and kexec the kernel ('kexec --load' +
> > > 'kexec -e'), same combination of kernel+ramdisk+dtb doesn't boot
> > > if I do kdump combination ('kexec -p' + sysrq crash), there is no
> > > any output after sysrq crash trace.
> > > Unfortunately I don't have any debugger here for deep investigation
> > > of this issue.
> >
> > Which type of image do you have? I did face issue with binary image which I
> > fixed in my branch, while elf would work fine for kdump as well.
>
> Can you describe in more details, please?
> I don't see any problems with either vmlinux or image
> in my environment.
See kexec/crashdump-elf.c:FUNC()
We have:
223 phdr->p_vaddr = phys_to_virt(elf_info, mstart);
Now, if we do not have page_offset then we will not have correct p_vaddr, and
then vmcore-dmesg/vmcore-dmesg.c:vaddr_to_offset() fails with
No program header covering vaddr 0xfffffc0008c312f0found kexec bug?
Fedora/RHEL kexec-tools saves vmcore only when dmesg save is OK.
I have updated [1] with the modification where --page-offset addition has been
moved to kdump binary image support patch.
[1] https://github.com/pratyushanand/kexec-tools.git : upstream_arm64_devel
~Pratyush
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH v23 0/9] arm64: add kdump support
2016-08-01 6:21 ` Pratyush Anand
@ 2016-08-01 6:46 ` AKASHI Takahiro
0 siblings, 0 replies; 21+ messages in thread
From: AKASHI Takahiro @ 2016-08-01 6:46 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Aug 01, 2016 at 11:51:12AM +0530, Pratyush Anand wrote:
> Hi Takahiro,
>
> On 01/08/2016:01:37:26 PM, AKASHI Takahiro wrote:
> > Pratyush,
> >
> > On Fri, Jul 29, 2016 at 10:43:00PM +0530, Pratyush Anand wrote:
> > > Hi Ruslan,
> > >
> > > On 29/07/2016:07:26:03 PM, Ruslan Bilovol wrote:
> > > > Hi,
> > > >
> > > > On Tue, Jul 26, 2016 at 11:09 AM, AKASHI Takahiro
> > > > <takahiro.akashi@linaro.org> wrote:
> > > > > On Tue, Jul 26, 2016 at 04:56:51PM +0900, AKASHI Takahiro wrote:
> > > > >> This patch series adds kdump support on arm64.
> > > > >>
> > > > >> To load a crash-dump kernel to the systems, a series of patches to
> > > > >> kexec-tools, which have not yet been merged upstream, are needed.
> > > > >> Please pick Geoff's kexec patches [1] and my kdump patches [2].
> > > > >>
> > > > >> To examine vmcore (/proc/vmcore) on a crash-dump kernel, you can use
> > > > >> - crash utility (coming v7.1.6 or later) [3]
> > > > >> (Necessary patches have already been queued in the master.)
> > > > >>
> > > > >> [1] http://lists.infradead.org/pipermail/kexec/2016-July/016532.html
> > > > >> [2] TBD
> > > > >
> > > > > See my kexec-tools patches in:
> > > > > http://lists.infradead.org/pipermail/kexec/2016-July/016642.html
> > > >
> > > > I tired this patch series with mentioned Geoff's kexec patches and
> > > > your kdump patches, but unfortunately it doesn't work for me.
> > > >
> > > > While I can successfully load and kexec the kernel ('kexec --load' +
> > > > 'kexec -e'), same combination of kernel+ramdisk+dtb doesn't boot
> > > > if I do kdump combination ('kexec -p' + sysrq crash), there is no
> > > > any output after sysrq crash trace.
> > > > Unfortunately I don't have any debugger here for deep investigation
> > > > of this issue.
> > >
> > > Which type of image do you have? I did face issue with binary image which I
> > > fixed in my branch, while elf would work fine for kdump as well.
> >
> > Can you describe in more details, please?
> > I don't see any problems with either vmlinux or image
> > in my environment.
>
> See kexec/crashdump-elf.c:FUNC()
> We have:
> 223 phdr->p_vaddr = phys_to_virt(elf_info, mstart);
> Now, if we do not have page_offset then we will not have correct p_vaddr, and
> then vmcore-dmesg/vmcore-dmesg.c:vaddr_to_offset() fails with
I don't see how this issue relates to Ruslan's case.
-Takahiro AKASHI
> No program header covering vaddr 0xfffffc0008c312f0found kexec bug?
>
> Fedora/RHEL kexec-tools saves vmcore only when dmesg save is OK.
>
> I have updated [1] with the modification where --page-offset addition has been
> moved to kdump binary image support patch.
>
> [1] https://github.com/pratyushanand/kexec-tools.git : upstream_arm64_devel
>
> ~Pratyush
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v23 0/9] arm64: add kdump support
2016-07-29 16:26 ` Ruslan Bilovol
2016-07-29 17:08 ` Geoff Levand
2016-07-29 17:13 ` Pratyush Anand
@ 2016-08-04 5:20 ` AKASHI Takahiro
2 siblings, 0 replies; 21+ messages in thread
From: AKASHI Takahiro @ 2016-08-04 5:20 UTC (permalink / raw)
To: linux-arm-kernel
Ruslan,
On Fri, Jul 29, 2016 at 07:26:03PM +0300, Ruslan Bilovol wrote:
> Hi,
>
> On Tue, Jul 26, 2016 at 11:09 AM, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> > On Tue, Jul 26, 2016 at 04:56:51PM +0900, AKASHI Takahiro wrote:
> >> This patch series adds kdump support on arm64.
> >>
> >> To load a crash-dump kernel to the systems, a series of patches to
> >> kexec-tools, which have not yet been merged upstream, are needed.
> >> Please pick Geoff's kexec patches [1] and my kdump patches [2].
> >>
> >> To examine vmcore (/proc/vmcore) on a crash-dump kernel, you can use
> >> - crash utility (coming v7.1.6 or later) [3]
> >> (Necessary patches have already been queued in the master.)
> >>
> >> [1] http://lists.infradead.org/pipermail/kexec/2016-July/016532.html
> >> [2] TBD
> >
> > See my kexec-tools patches in:
> > http://lists.infradead.org/pipermail/kexec/2016-July/016642.html
>
> I tired this patch series with mentioned Geoff's kexec patches and
> your kdump patches, but unfortunately it doesn't work for me.
>
> While I can successfully load and kexec the kernel ('kexec --load' +
> 'kexec -e'), same combination of kernel+ramdisk+dtb doesn't boot
> if I do kdump combination ('kexec -p' + sysrq crash), there is no
> any output after sysrq crash trace.
> Unfortunately I don't have any debugger here for deep investigation
> of this issue.
- Can you try to do kdump without ramdisk?
- Show me
- kernel boot log, particularly, "Virtual kernel memory layout:"
- cat /proc/iomem
- log from kexec command
> Also for some reason in case of 'load and kexec the kernel' it
> takes 1-2 minutes to start booting after I do kexec -e, need to
> investigate it further.
>
> Which hardware do you use for validating your patches?
I always test my patches on ARM fast model.
Thanks,
-Takahiro AKASHI
> Also, could you please share exact commands you use for
> kdump validation?
>
> Best regaerds,
> Ruslan
^ permalink raw reply [flat|nested] 21+ messages in thread