This series adds the core support for kexec re-boot and kdump on ARM64. This
version of the series combines Takahiro's kdump patches with my kexec patches.
Please consider all patches for inclusion.
I just tested all the endian combinations of kexec LE->LE, LE->BE, BE->BE,
BE->LE, and both LE an BE kdump, and all work as expected.
To load a second stage kernel and execute a kexec re-boot or to work with kdump
on ARM64 systems a series of patches to kexec-tools [2], which have not yet been
merged upstream, are needed.
To examine vmcore (/proc/vmcore), you should use
- gdb v7.7 or later
- crash v7.1.1 or later
[1] https://git.kernel.org/cgit/linux/kernel/git/geoff/linux-kexec.git
[2] https://git.kernel.org/cgit/linux/kernel/git/geoff/kexec-tools.git
Changes for v13 (Jan 15, 2016, 20m):
o Rebase to Linux-4.4.
o Remove align directive from cpu_reset.c.
o Use inline C wrapper for cpu_soft_restart.
o Revert the new image d-cache flush changes of v10.
o Add SCTLR cleanup patch.
o Change pr_devel to pr_debug.
o Call flush_icache_range() for reboot_code_buffer.
o Add .ltorg directive to arm64_relocate_new_kernel.
o Make new asm macro copy_page.
o Change cache maintenence from inner-shareable to non-shareable.
o Rename KEXEC_ARCH_ARM64 to KEXEC_ARCH_AARCH64.
o arm64: kvm: allows kvm cpu hotplug
- remove some garbage code from kvm_host.h
o arm64: kdump: reserve memory for crash dump kernel
- change CONFIG_KEXEC to CONFIG_KEXEC_CORE
- don't panic on crash kernel alloc failure
(thanks to Mark Salter, RH)
o arm64: kdump: implement machine_crash_shutdown()
- change "boot/non-boot cpu" to "crashing/non-crashing cpu"
- introduce is_in_crash_kexec() for readability
- re-introduce machine_kexec_mask_interrupts(), as arch/arm has,
to discard unexpected interrupts
- call crash_save_cpu() before making cpus offline to avoid a possible race
(thanks to Pratyush Anand/Mark Salter, RH)
o arm64: kdump: update a kernel doc
- clarify that we support "Image" format as well as vmlinux in kdump.txt
o arm64: kdump: relax BUG_ON() if more than one cpus are still active
- change a warning message at the failure of shooting down non-crahsing cpus
Changes for v12 (Nov 24, 2015, 18m):
o No changes, rebase to Linux-4.4-rc2.
Changes for v11 (Nov 6, 2015, 18m):
o Rebase to Linux-4.3.
o Move the new image d-cache flush from arm64_relocate_new_kernel to machine_kexec.
o Pass values to arm64_relocate_new_kernel in registers, not in global variables.
o Fixups to setting the sctlr_el1 and sctlr_el2 flags.
Changes for v10 (Oct 18, 2015, 17m):
o Rebase to Linux-4.3-rc6.
o Move tcr_set_idmap_t0sz to assembler.h.
o Add back simplified cpu_reset routines.
o Combine kexec + kdump patches.
Changes for v9 (Apr 7, 2015, 11m):
o Use new upstream flag IND_FLAGS.
Changes for v8 (Mar 19, 2015, 10m):
o Rebase to Linux-4.0-rc4.
o Re-boot using purgatory only.
Changes for v7 (Jan 16, 2015, 8m):
o Rebase to Linux-3.19-rc4.
o Change from ESR_EL2_ to ESR_ELx_.
o Remove work-arounds for EFI systems.
Changes for v6 (Dec 2, 2014, 7m):
o Rebase to Linux-3.18-rc2
Changes for v5 (Nov 16, 2014, 6m):
Changes for v4 (Oct 3, 2014, 5m):
Changes for v3 (Sept 23, 2014, 4m):
Changes for v2 (Sep 9, 2014, 4m):
o Rebase to Linux-3.17-rc4.
o Move macros from proc-macros.S to assembler.h.
o Convert hcalls to use ISS field.
o Add new hcall HVC_CALL_FUNC.
o Add EL2 switch to soft_restart.
First submission v1 (May 13, 2014):
o Based on Linux-3.15-rc4.
-Geoff
The following changes since commit afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc:
Linux 4.4 (2016-01-10 15:01:32 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geoff/linux-kexec.git kexec-v13
for you to fetch changes up to e52b39c76d2a967bdecc376daee07d6edd47b01a:
arm64: kdump: relax BUG_ON() if more than one cpus are still active (2016-01-15 10:22:45 -0800)
----------------------------------------------------------------
AKASHI Takahiro (7):
arm64: kvm: allows kvm cpu hotplug
arm64: kdump: reserve memory for crash dump kernel
arm64: kdump: implement machine_crash_shutdown()
arm64: kdump: add kdump support
arm64: kdump: enable kdump in the arm64 defconfig
arm64: kdump: update a kernel doc
arm64: kdump: relax BUG_ON() if more than one cpus are still active
Geoff Levand (11):
arm64: Fold proc-macros.S into assembler.h
arm64: Add new asm macro copy_page
arm64: Cleanup SCTLR flags
arm64: Convert hcalls to use HVC immediate value
arm64: Add new hcall HVC_CALL_FUNC
arm64: Add back cpu_reset routines
Revert "arm64: mm: remove unused cpu_set_idmap_tcr_t0sz function"
Revert "arm64: remove dead code"
arm64/kexec: Add core kexec support
arm64/kexec: Enable kexec in the arm64 defconfig
arm64/kexec: Add pr_debug output
James Morse (1):
arm64: kernel: Include _AC definition in page.h
Documentation/kdump/kdump.txt | 23 ++-
arch/arm/include/asm/kvm_host.h | 10 +-
arch/arm/include/asm/kvm_mmu.h | 1 +
arch/arm/kvm/arm.c | 93 +++++++-----
arch/arm/kvm/mmu.c | 5 +
arch/arm64/Kconfig | 21 +++
arch/arm64/configs/defconfig | 2 +
arch/arm64/include/asm/assembler.h | 67 +++++++-
arch/arm64/include/asm/kexec.h | 93 ++++++++++++
arch/arm64/include/asm/kvm_arm.h | 11 --
arch/arm64/include/asm/kvm_host.h | 11 +-
arch/arm64/include/asm/kvm_mmu.h | 1 +
arch/arm64/include/asm/mmu.h | 1 +
arch/arm64/include/asm/mmu_context.h | 35 +++--
arch/arm64/include/asm/page.h | 2 +
arch/arm64/include/asm/sysreg.h | 19 ++-
arch/arm64/include/asm/virt.h | 49 ++++++
arch/arm64/kernel/Makefile | 3 +
arch/arm64/kernel/cpu-reset.S | 57 +++++++
arch/arm64/kernel/cpu-reset.h | 29 ++++
arch/arm64/kernel/crash_dump.c | 71 +++++++++
arch/arm64/kernel/hyp-stub.S | 43 ++++--
arch/arm64/kernel/machine_kexec.c | 285 +++++++++++++++++++++++++++++++++++
arch/arm64/kernel/relocate_kernel.S | 131 ++++++++++++++++
arch/arm64/kernel/setup.c | 7 +-
arch/arm64/kernel/smp.c | 18 ++-
arch/arm64/kvm/hyp-init.S | 39 ++++-
arch/arm64/kvm/hyp.S | 44 ++++--
arch/arm64/mm/cache.S | 2 -
arch/arm64/mm/init.c | 89 +++++++++++
arch/arm64/mm/mmu.c | 11 ++
arch/arm64/mm/proc-macros.S | 64 --------
arch/arm64/mm/proc.S | 3 -
include/uapi/linux/kexec.h | 1 +
34 files changed, 1175 insertions(+), 166 deletions(-)
create mode 100644 arch/arm64/include/asm/kexec.h
create mode 100644 arch/arm64/kernel/cpu-reset.S
create mode 100644 arch/arm64/kernel/cpu-reset.h
create mode 100644 arch/arm64/kernel/crash_dump.c
create mode 100644 arch/arm64/kernel/machine_kexec.c
create mode 100644 arch/arm64/kernel/relocate_kernel.S
delete mode 100644 arch/arm64/mm/proc-macros.S
--
2.5.0
Commit 68234df4ea7939f98431aa81113fbdce10c4a84b (arm64: kill flush_cache_all())
removed the global arm64 routines cpu_reset() and cpu_soft_restart() needed by
the arm64 kexec and kdump support. Add simplified versions of those two
routines back with some changes needed for kexec in the new files cpu_reset.S,
and cpu_reset.h.
When a CPU is reset it needs to be put into the exception level it had
when it entered the kernel. Update cpu_reset() to accept an argument
which signals if the reset address needs to be entered at EL1 or EL2.
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
arch/arm64/kernel/cpu-reset.S | 57 +++++++++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/cpu-reset.h | 29 ++++++++++++++++++++++
2 files changed, 86 insertions(+)
create mode 100644 arch/arm64/kernel/cpu-reset.S
create mode 100644 arch/arm64/kernel/cpu-reset.h
This reverts commit c51e97d89e526368eb697f87cd4d391b9e19f369.
Add back the cpu_set_idmap_tcr_t0sz function needed by setup_mmu_for_reboot.
---
arch/arm64/include/asm/mmu_context.h | 35 +++++++++++++++++++++++------------
1 file changed, 23 insertions(+), 12 deletions(-)
@@ -240,6 +241,24 @@ lr .req x30 // link register.endm/*+*copy_page-copysrctodestusingtempregisterst1-t8+*/+.macrocopy_pagedest:reqsrc:reqt1:reqt2:reqt3:reqt4:reqt5:reqt6:reqt7:reqt8:req+1:ldp\t1,\t2,[\src]+ldp\t3,\t4,[\src,#16]+ldp\t5,\t6,[\src,#32]+ldp\t7,\t8,[\src,#48]+add\src,\src,#64+stnp\t1,\t2,[\dest]+stnp\t3,\t4,[\dest,#16]+stnp\t5,\t6,[\dest,#32]+stnp\t7,\t8,[\dest,#48]+add\dest,\dest,#64+tst\src,#(PAGE_SIZE-1)+b.ne1b+.endm++/**Annotateafunctionaspositionindependent,i.e.,safetobecalledbefore*thekernelvirtualmappingisactivated.*/
Add the new hcall HVC_CALL_FUNC that allows execution of a function at EL2.
During CPU reset the CPU must be brought to the exception level it had on
entry to the kernel. The HVC_CALL_FUNC hcall will provide the mechanism
needed for this exception level switch.
To allow the HVC_CALL_FUNC exception vector to work without a stack, which is
needed to support an hcall at CPU reset, this implementation uses register x18
to store the link register across the caller provided function. This dictates
that the caller provided function must preserve the contents of register x18.
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
arch/arm64/include/asm/virt.h | 13 +++++++++++++
arch/arm64/kernel/hyp-stub.S | 13 ++++++++++++-
2 files changed, 25 insertions(+), 1 deletion(-)
We currently have macros defining flags for the arm64 sctlr registers in both
kvm_arm.h and sysreg.h. To clean things up and simplify move the definitions
of the SCTLR_EL2 flags from kvm_arm.h to sysreg.h, rename any SCTLR_EL1 or
SCTLR_EL2 flags that are common to both registers to be SCTLR_ELx, with 'x'
indicating a common flag, and fixup all files to include the proper header or
to use the new macro names.
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
arch/arm64/include/asm/kvm_arm.h | 11 -----------
arch/arm64/include/asm/sysreg.h | 19 +++++++++++++++----
arch/arm64/kvm/hyp-init.S | 6 +++---
3 files changed, 18 insertions(+), 18 deletions(-)
From: James Morse <james.morse@arm.com>
From: James Morse <james.morse@arm.com>
page.h uses '_AC' in the definition of PAGE_SIZE, but doesn't include
linux/const.h where this is defined. This produces build warnings when only
asm/page.h is included by asm code.
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Pavel Machek <redacted>
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
arch/arm64/include/asm/page.h | 2 ++
1 file changed, 2 insertions(+)
@@ -19,6 +19,8 @@#ifndef __ASM_PAGE_H#define __ASM_PAGE_H+#include<linux/const.h>+/* PAGE_SHIFT determines the page size *//* CONT_SHIFT determines the number of pages which can be tracked together */#ifdef CONFIG_ARM64_64K_PAGES
The existing arm64 hcall implementations are limited in that they only allow
for two distinct hcalls; with the x0 register either zero or not zero. Also,
the API of the hyp-stub exception vector routines and the KVM exception vector
routines differ; hyp-stub uses a non-zero value in x0 to implement
__hyp_set_vectors, whereas KVM uses it to implement kvm_call_hyp.
To allow for additional hcalls to be defined and to make the arm64 hcall API
more consistent across exception vector routines, change the hcall
implementations to use the 16 bit immediate value of the HVC instruction to
specify the hcall type.
Define three new preprocessor macros HVC_CALL_HYP, HVC_GET_VECTORS, and
HVC_SET_VECTORS to be used as hcall type specifiers and convert the
existing __hyp_get_vectors(), __hyp_set_vectors() and kvm_call_hyp() routines
to use these new macros when executing an HVC call. Also, change the
corresponding hyp-stub and KVM el1_sync exception vector routines to use these
new macros.
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
arch/arm64/include/asm/virt.h | 27 +++++++++++++++++++++++++++
arch/arm64/kernel/hyp-stub.S | 32 +++++++++++++++++++++-----------
arch/arm64/kvm/hyp.S | 16 +++++++++-------
3 files changed, 57 insertions(+), 18 deletions(-)
To allow the assembler macros defined in arch/arm64/mm/proc-macros.S to be used
outside the mm code move the contents of proc-macros.S to asm/assembler.h. Also,
delete proc-macros.S, and fix up all references to proc-macros.S.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Acked-by: Pavel Machek <redacted>
---
arch/arm64/include/asm/assembler.h | 48 +++++++++++++++++++++++++++-
arch/arm64/mm/cache.S | 2 --
arch/arm64/mm/proc-macros.S | 64 --------------------------------------
arch/arm64/mm/proc.S | 3 --
4 files changed, 47 insertions(+), 70 deletions(-)
delete mode 100644 arch/arm64/mm/proc-macros.S
@@ -194,6 +196,50 @@ lr .req x30 // link register.endm/*+*vma_vm_mm-getmmpointerfromvmapointer(vma->vm_mm)+*/+.macrovma_vm_mm,rd,rn+ldr\rd,[\rn,#VMA_VM_MM]+.endm++/*+*mmid-getcontextidfrommmpointer(mm->context.id)+*/+.macrommid,rd,rn+ldr\rd,[\rn,#MM_CONTEXT_ID]+.endm++/*+*dcache_line_size-gettheminimumD-cachelinesizefromtheCTRregister.+*/+.macrodcache_line_size,reg,tmp+mrs\tmp,ctr_el0// read CTR+ubfm\tmp,\tmp,#16,#19// cache line size encoding+mov\reg,#4// bytes per word+lsl\reg,\reg,\tmp// actual cache line size+.endm++/*+*icache_line_size-gettheminimumI-cachelinesizefromtheCTRregister.+*/+.macroicache_line_size,reg,tmp+mrs\tmp,ctr_el0// read CTR+and\tmp,\tmp,#0xf// cache line size encoding+mov\reg,#4// bytes per word+lsl\reg,\reg,\tmp// actual cache line size+.endm++/*+*tcr_set_idmap_t0sz-updateTCR.T0SZsothatwecanloadtheIDmap+*/+.macrotcr_set_idmap_t0sz,valreg,tmpreg+#ifndef CONFIG_ARM64_VA_BITS_48+ldr_l\tmpreg,idmap_t0sz+bfi\valreg,\tmpreg,#TCR_T0SZ_OFFSET,#TCR_TxSZ_WIDTH+#endif+.endm++/**Annotateafunctionaspositionindependent,i.e.,safetobecalledbefore*thekernelvirtualmappingisactivated.*/
@@ -1,64 +0,0 @@-/*- * Based on arch/arm/mm/proc-macros.S- *- * Copyright (C) 2012 ARM Ltd.- *- * 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.- *- * This program is distributed in the hope that it will be useful,- * but WITHOUT ANY WARRANTY; without even the implied warranty of- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the- * GNU General Public License for more details.- *- * You should have received a copy of the GNU General Public License- * along with this program. If not, see <http://www.gnu.org/licenses/>.- */--#include <asm/asm-offsets.h>-#include <asm/thread_info.h>--/*- * vma_vm_mm - get mm pointer from vma pointer (vma->vm_mm)- */- .macro vma_vm_mm, rd, rn- ldr \rd, [\rn, #VMA_VM_MM]- .endm--/*- * mmid - get context id from mm pointer (mm->context.id)- */- .macro mmid, rd, rn- ldr \rd, [\rn, #MM_CONTEXT_ID]- .endm--/*- * dcache_line_size - get the minimum D-cache line size from the CTR register.- */- .macro dcache_line_size, reg, tmp- mrs \tmp, ctr_el0 // read CTR- ubfm \tmp, \tmp, #16, #19 // cache line size encoding- mov \reg, #4 // bytes per word- lsl \reg, \reg, \tmp // actual cache line size- .endm--/*- * icache_line_size - get the minimum I-cache line size from the CTR register.- */- .macro icache_line_size, reg, tmp- mrs \tmp, ctr_el0 // read CTR- and \tmp, \tmp, #0xf // cache line size encoding- mov \reg, #4 // bytes per word- lsl \reg, \reg, \tmp // actual cache line size- .endm--/*- * tcr_set_idmap_t0sz - update TCR.T0SZ so that we can load the ID map- */- .macro tcr_set_idmap_t0sz, valreg, tmpreg-#ifndef CONFIG_ARM64_VA_BITS_48- ldr_l \tmpreg, idmap_t0sz- bfi \valreg, \tmpreg, #TCR_T0SZ_OFFSET, #TCR_TxSZ_WIDTH-#endif- .endm
From: AKASHI Takahiro <redacted>
On crash dump kernel, all the information about primary kernel's core
image is available in elf core header specified by "elfcorehdr=" boot
parameter. reserve_elfcorehdr() will set aside the region to avoid any
corruption by crash dump kernel.
Crash dump kernel will access the system memory of primary kernel via
copy_oldmem_page(), which reads one page by ioremap'ing it since it does
not reside in linear mapping on crash dump kernel.
Please note that we should add "mem=X[MG]" boot parameter to limit the
memory size and avoid the following assertion at ioremap():
if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
return NULL;
when accessing any pages beyond the usable memories of crash dump kernel.
We also need our own elfcorehdr_read() here since the weak definition of
elfcorehdr_read() utilizes copy_oldmem_page() and will hit the assertion
above on arm64.
Signed-off-by: AKASHI Takahiro <redacted>
---
arch/arm64/Kconfig | 11 +++++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/crash_dump.c | 71 ++++++++++++++++++++++++++++++++++++++++++
arch/arm64/mm/init.c | 32 +++++++++++++++++++
4 files changed, 115 insertions(+)
create mode 100644 arch/arm64/kernel/crash_dump.c
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.++2) Currently, kvm will not be enabled on the dump-capture kernel even+ if it is configured.+ Extended crashkernel syntax ===========================
@@ -312,6 +326,8 @@ Boot into System Kernel any space below the alignment point may be overwritten by the dump-capture kernel, which means it is possible that the vmcore is not that precise as expected.+ 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 ============================
@@ -334,6 +350,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.
@@ -377,6 +395,9 @@ For s390x: For arm: "1 maxcpus=1 reset_devices"+For arm64:+ "1 mem=X[MG] maxcpus=1 reset_devices"+ Notes on loading the dump-capture kernel: * By default, the ELF headers are stored in ELF64 format to support
From: AKASHI Takahiro <redacted>
On primary kernel, the memory region used by crash dump kernel must be
specified by "crashkernel=" boot parameter. reserve_crashkernel()
will allocate and reserve the region for later use.
User space tools will be able to find the region marked as "Crash kernel"
in /proc/iomem.
Signed-off-by: AKASHI Takahiro <redacted>
Signed-off-by: Mark Salter <redacted>
Signed-off-by: Pratyush Anand <redacted>
---
arch/arm64/kernel/setup.c | 7 +++++-
arch/arm64/mm/init.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 63 insertions(+), 1 deletion(-)
@@ -221,6 +220,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}#ifdef CONFIG_BLK_DEV_INITRD
@@ -66,6 +67,58 @@ static int __init early_initrd(char *p)early_param("initrd",early_initrd);#endif+#ifdef CONFIG_KEXEC_CORE+/*+*reserve_crashkernel()-reservesmemoryforcrashkernel+*+*Thisfunctionreservesmemoryareagivenin"crashkernel="kernelcommand+*lineparameter.Thememoryreservedisusedbydumpcapturekernelwhen+*primarykerneliscrashing.+*/+staticvoid__initreserve_crashkernel(void)+{+unsignedlonglongcrash_size=0,crash_base=0;+intret;++ret=parse_crashkernel(boot_command_line,memblock_phys_mem_size(),+&crash_size,&crash_base);+if(ret)+return;++if(crash_base==0){+crash_base=memblock_find_in_range(0,+MEMBLOCK_ALLOC_ACCESSIBLE,crash_size,1<<21);+if(crash_base==0){+pr_warn("Unable to allocate crashkernel (size:%llx)\n",+crash_size);+return;+}+memblock_reserve(crash_base,crash_size);++}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(crash_base&((1<<21)-1)){+pr_warn("crashkernel base address is not 2MB aligned\n");+return;+}++memblock_reserve(crash_base,crash_size);+}++pr_info("Reserving %lldMB of memory@%lldMB for crashkernel\n",+crash_size>>20,crash_base>>20);++crashk_res.start=crash_base;+crashk_res.end=crash_base+crash_size-1;+}+#endif /* CONFIG_KEXEC_CORE */+/**ReturnthemaximumphysicaladdressforZONE_DMA(DMA_BIT_MASK(32)).It*currentlyassumesthatformemorystartingabove4G,32-bitdeviceswill
@@ -171,6 +224,10 @@ void __init arm64_memblock_init(void)memblock_reserve(__virt_to_phys(initrd_start),initrd_end-initrd_start);#endif+#ifdef CONFIG_KEXEC_CORE+reserve_crashkernel();+#endif+early_init_fdt_scan_reserved_mem();/* 4GB maximum for 32-bit only capable devices */
@@ -59,6 +59,7 @@ CONFIG_KSM=y CONFIG_TRANSPARENT_HUGEPAGE=y CONFIG_CMA=y CONFIG_KEXEC=y+CONFIG_CRASH_DUMP=y CONFIG_CMDLINE="console=ttyAMA0" # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set CONFIG_COMPAT=y
@@ -0,0 +1,48 @@+/*+*kexecforarm64+*+*Copyright(C)Linaro.+*Copyright(C)HuaweiFutureweiTechnologies.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsoftheGNUGeneralPublicLicenseversion2as+*publishedbytheFreeSoftwareFoundation.+*/++#ifndef _ARM64_KEXEC_H+#define _ARM64_KEXEC_H++/* Maximum physical address we can use pages from */++#define KEXEC_SOURCE_MEMORY_LIMIT (-1UL)++/* Maximum address we can reach in physical address mode */++#define KEXEC_DESTINATION_MEMORY_LIMIT (-1UL)++/* Maximum address we can use for the control code buffer */++#define KEXEC_CONTROL_MEMORY_LIMIT (-1UL)++#define KEXEC_CONTROL_PAGE_SIZE 4096++#define KEXEC_ARCH KEXEC_ARCH_AARCH64++#ifndef __ASSEMBLY__++/**+*crash_setup_regs()-saveregistersforthepanickernel+*+*@newregs:registersaresavedhere+*@oldregs:registerstobesaved(maybe%NULL)+*/++staticinlinevoidcrash_setup_regs(structpt_regs*newregs,+structpt_regs*oldregs)+{+/* Empty routine needed to avoid build errors. */+}++#endif /* __ASSEMBLY__ */++#endif
@@ -0,0 +1,158 @@+/*+*kexecforarm64+*+*Copyright(C)Linaro.+*Copyright(C)HuaweiFutureweiTechnologies.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsoftheGNUGeneralPublicLicenseversion2as+*publishedbytheFreeSoftwareFoundation.+*/++#include<linux/highmem.h>+#include<linux/kexec.h>+#include<linux/of_fdt.h>+#include<linux/slab.h>+#include<linux/uaccess.h>++#include<asm/cacheflush.h>+#include<asm/system_misc.h>++#include"cpu-reset.h"++/* Global variables for the arm64_relocate_new_kernel routine. */+externconstunsignedchararm64_relocate_new_kernel[];+externconstunsignedlongarm64_relocate_new_kernel_size;++staticunsignedlongkimage_start;++voidmachine_kexec_cleanup(structkimage*kimage)+{+/* Empty routine needed to avoid build errors. */+}++/**+*machine_kexec_prepare-Prepareforakexecreboot.+*+*Calledfromthecorekexeccodewhenakernelimageisloaded.+*/+intmachine_kexec_prepare(structkimage*kimage)+{+kimage_start=kimage->start;+return0;+}++/**+*kexec_list_flush-HelpertoflushthekimagelisttoPoC.+*/+staticvoidkexec_list_flush(structkimage*kimage)+{+kimage_entry_t*entry;+unsignedintflag;++for(entry=&kimage->head,flag=0;flag!=IND_DONE;entry++){+void*addr=kmap(phys_to_page(*entry&PAGE_MASK));++flag=*entry&IND_FLAGS;++switch(flag){+caseIND_INDIRECTION:+entry=(kimage_entry_t*)addr-1;+__flush_dcache_area(addr,PAGE_SIZE);+break;+caseIND_DESTINATION:+break;+caseIND_SOURCE:+__flush_dcache_area(addr,PAGE_SIZE);+break;+caseIND_DONE:+break;+default:+BUG();+}+kunmap(addr);+}+}++/**+*kexec_segment_flush-HelpertoflushthekimagesegmentstoPoC.+*/+staticvoidkexec_segment_flush(conststructkimage*kimage)+{+unsignedlongi;++pr_devel("%s:\n",__func__);++for(i=0;i<kimage->nr_segments;i++){+pr_devel(" segment[%lu]: %016lx - %016lx, %lx bytes, %lu pages\n",+i,+kimage->segment[i].mem,+kimage->segment[i].mem+kimage->segment[i].memsz,+kimage->segment[i].memsz,+kimage->segment[i].memsz/PAGE_SIZE);++__flush_dcache_area(phys_to_virt(kimage->segment[i].mem),+kimage->segment[i].memsz);+}+}++/**+*machine_kexec-Dothekexecreboot.+*+*Calledfromthecorekexeccodeforasys_rebootwithLINUX_REBOOT_CMD_KEXEC.+*/+voidmachine_kexec(structkimage*kimage)+{+phys_addr_treboot_code_buffer_phys;+void*reboot_code_buffer;++BUG_ON(num_online_cpus()>1);++reboot_code_buffer_phys=page_to_phys(kimage->control_code_page);+reboot_code_buffer=kmap(kimage->control_code_page);++/*+*Copyarm64_relocate_new_kerneltothereboot_code_bufferforuse+*afterthekernelisshutdown.+*/+memcpy(reboot_code_buffer,arm64_relocate_new_kernel,+arm64_relocate_new_kernel_size);++/* Flush the reboot_code_buffer in preparation for its execution. */+__flush_dcache_area(reboot_code_buffer,arm64_relocate_new_kernel_size);+flush_icache_range((uintptr_t)reboot_code_buffer,+arm64_relocate_new_kernel_size);++/* Flush the kimage list. */+kexec_list_flush(kimage);++/* Flush the new image if already in place. */+if(kimage->head&IND_DONE)+kexec_segment_flush(kimage);++pr_info("Bye!\n");++/* Disable all DAIF exceptions. */+asmvolatile("msr daifset, #0xf":::"memory");++setup_mm_for_reboot();++/*+*cpu_soft_restartwillshutdowntheMMU,disabledatacaches,then+*transfercontroltothereboot_code_bufferwhichcontainsacopyof+*thearm64_relocate_new_kernelroutine.arm64_relocate_new_kernel+*usesphysicaladdressingtorelocatethenewimagetoitsfinal+*positionandtransferscontroltotheimageentrypointwhenthe+*relocationiscomplete.+*/++cpu_soft_restart(is_hyp_mode_available(),+reboot_code_buffer_phys,kimage->head,kimage_start,0);++BUG();/* Should never get here. */+}++voidmachine_crash_shutdown(structpt_regs*regs)+{+/* Empty routine needed to avoid build errors. */+}
@@ -39,6 +39,7 @@#define KEXEC_ARCH_SH (42 << 16)#define KEXEC_ARCH_MIPS_LE (10 << 16)#define KEXEC_ARCH_MIPS ( 8 << 16)+#define KEXEC_ARCH_AARCH64 (183 << 16)/* The artificial cap on the number of segments passed to kexec_load. */#define KEXEC_SEGMENT_MAX 16
@@ -58,6 +58,7 @@ CONFIG_PREEMPT=y CONFIG_KSM=y CONFIG_TRANSPARENT_HUGEPAGE=y CONFIG_CMA=y+CONFIG_KEXEC=y CONFIG_CMDLINE="console=ttyAMA0" # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set CONFIG_COMPAT=y
To aid in debugging kexec problems or when adding new functionality to kexec add
a new routine kexec_image_info() and several inline pr_debug statements.
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
arch/arm64/kernel/machine_kexec.c | 70 +++++++++++++++++++++++++++++++++++++--
1 file changed, 68 insertions(+), 2 deletions(-)
From: AKASHI Takahiro <redacted>
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents, especially, kexec from rebooting the system on a boot
core in EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need arm64-specific cpu hotplug hook any more.
Since this patch modifies common part of code between arm and arm64, one
stub definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compiling errors.
Signed-off-by: AKASHI Takahiro <redacted>
---
arch/arm/include/asm/kvm_host.h | 10 ++++-
arch/arm/include/asm/kvm_mmu.h | 1 +
arch/arm/kvm/arm.c | 93 +++++++++++++++++++++++----------------
arch/arm/kvm/mmu.c | 5 +++
arch/arm64/include/asm/kvm_host.h | 11 ++++-
arch/arm64/include/asm/kvm_mmu.h | 1 +
arch/arm64/include/asm/virt.h | 9 ++++
arch/arm64/kvm/hyp-init.S | 33 ++++++++++++++
arch/arm64/kvm/hyp.S | 32 ++++++++++++--
9 files changed, 151 insertions(+), 44 deletions(-)
@@ -577,7 +573,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)/**Re-checkatomicconditions*/-if(signal_pending(current)){+if(unlikely(!__this_cpu_read(kvm_arm_hardware_enabled))){+/* cpu has been torn down */+ret=0;+run->exit_reason=KVM_EXIT_FAIL_ENTRY;+run->fail_entry.hardware_entry_failure_reason+=(u64)-ENOEXEC;+}elseif(signal_pending(current)){ret=-EINTR;run->exit_reason=KVM_EXIT_INTR;}
@@ -954,7 +956,7 @@ long kvm_arch_vm_ioctl(struct file *filp,}}-staticvoidcpu_init_hyp_mode(void*dummy)+staticvoidcpu_init_hyp_mode(void){phys_addr_tboot_pgd_ptr;phys_addr_tpgd_ptr;
@@ -140,6 +140,39 @@ merged:eretENDPROC(__kvm_hyp_init)+/*+*x0:HYPbootpgd+*x1:HYPphys_idmap_start+*/+ENTRY(__kvm_hyp_reset)+/*We're in trampoline code in VA, switch back to boot page tables */+msrttbr0_el2,x0+isb++/*InvalidatetheoldTLBs*/+tlbialle2+dsbsy++/*BranchintoPAspace*/+adrx0,1f+bfix1,x0,#0, #PAGE_SHIFT+brx1++/*We're now in idmap, disable MMU */+1:mrsx0,sctlr_el2+ldrx1,=SCTLR_ELx_FLAGS+bicx0,x0,x1//ClearSCTL_Mandetc+msrsctlr_el2,x0+isb++/*Installstubvectors*/+adrpx0,__hyp_stub_vectors+addx0,x0,#:lo12:__hyp_stub_vectors+msrvbar_el2,x0++eret+ENDPROC(__kvm_hyp_reset)+.ltorg.popsection
From: AKASHI Takahiro <redacted>
We should try best in case of kdump.
So even if not all secondary cpus have shut down, we do kdump anyway.
Signed-off-by: AKASHI Takahiro <redacted>
---
arch/arm64/kernel/machine_kexec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: AKASHI Takahiro <redacted>
kdump calls machine_crash_shutdown() to shut down non-boot cpus and
save registers' status in per-cpu ELF notes before starting the crash
dump kernel. See kernel_kexec().
ipi_cpu_stop() is a bit modified and used to support this behavior.
Signed-off-by: AKASHI Takahiro <redacted>
---
arch/arm64/include/asm/kexec.h | 47 +++++++++++++++++++++++++++-
arch/arm64/kernel/machine_kexec.c | 65 +++++++++++++++++++++++++++++++++++++--
arch/arm64/kernel/smp.c | 18 ++++++++---
3 files changed, 123 insertions(+), 7 deletions(-)
[Adding Marc as this touches KVM code]
On Fri, Jan 15, 2016 at 07:18:37PM +0000, Geoff Levand wrote:
We currently have macros defining flags for the arm64 sctlr registers in both
kvm_arm.h and sysreg.h. To clean things up and simplify move the definitions
of the SCTLR_EL2 flags from kvm_arm.h to sysreg.h, rename any SCTLR_EL1 or
SCTLR_EL2 flags that are common to both registers to be SCTLR_ELx, with 'x'
indicating a common flag, and fixup all files to include the proper header or
to use the new macro names.
I am certainly in favour of having consistently named and located macros
for register fields.
SCTLR_EL2_FLAGS is a KVM-specific value (i.e. the SCTLR_EL2 flags which
KVM wants to set), even if it consists solely of common fields.
I believe it should stay here (with an include for <asm/sysreg.h>),
perhaps with a KVM_ prefix to imply it's not as generic as one might
assume it is.
@@ -105,8 +105,8 @@ __do_hyp_init:dsbsymrsx4,sctlr_el2-andx4,x4,#SCTLR_EL2_EE // preserve endianness of EL2-ldrx5,=SCTLR_EL2_FLAGS+andx4,x4,#SCTLR_ELx_EE // preserve endianness of EL2+ldrx5,=SCTLR_ELx_FLAGS
Marc, Christoffer, I note that in SCTLR_EL2_FLAGS we don't set the RES1
bits of SCTLR_EL2 (not in head.S el2_setup). Should we perhaps be doing
so so as to avoid any future surprises?
Thanks,
Mark.
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
Thanks,
Mark.
quoted hunk
++2) Currently, kvm will not be enabled on the dump-capture kernel even+ if it is configured.+ Extended crashkernel syntax ===========================
@@ -312,6 +326,8 @@ Boot into System Kernel any space below the alignment point may be overwritten by the dump-capture kernel, which means it is possible that the vmcore is not that precise as expected.+ 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 ============================
@@ -334,6 +350,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.
@@ -377,6 +395,9 @@ For s390x: For arm: "1 maxcpus=1 reset_devices"+For arm64:+ "1 mem=X[MG] maxcpus=1 reset_devices"+ Notes on loading the dump-capture kernel: * By default, the ELF headers are stored in ELF64 format to support
On Fri, Jan 15, 2016 at 07:18:37PM +0000, Geoff Levand wrote:
From: James Morse <james.morse@arm.com>
From: James Morse <james.morse@arm.com>
Not sure why this appears multiple times.
page.h uses '_AC' in the definition of PAGE_SIZE, but doesn't include
linux/const.h where this is defined. This produces build warnings when only
asm/page.h is included by asm code.
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Pavel Machek <redacted>
Signed-off-by: Geoff Levand <geoff@infradead.org>
This is sensible even in isolation, so FWIW:
Acked-by: Mark Rutland <mark.rutland@arm.com>
I note that for the !__ASSEMBLY__ portion we use current,
READ_IMPLIES_EXEC, and some VM_* flags, without including the headers
those are defined in. It might be worth fixing those up also.
Mark.
@@ -19,6 +19,8 @@#ifndef __ASM_PAGE_H#define __ASM_PAGE_H+#include<linux/const.h>+/* PAGE_SHIFT determines the page size *//* CONT_SHIFT determines the number of pages which can be tracked together */#ifdef CONFIG_ARM64_64K_PAGES
From: Marc Zyngier <hidden> Date: 2016-01-18 10:12:18
On 15/01/16 20:07, Mark Rutland wrote:
[Adding Marc as this touches KVM code]
On Fri, Jan 15, 2016 at 07:18:37PM +0000, Geoff Levand wrote:
quoted
We currently have macros defining flags for the arm64 sctlr registers in both
kvm_arm.h and sysreg.h. To clean things up and simplify move the definitions
of the SCTLR_EL2 flags from kvm_arm.h to sysreg.h, rename any SCTLR_EL1 or
SCTLR_EL2 flags that are common to both registers to be SCTLR_ELx, with 'x'
indicating a common flag, and fixup all files to include the proper header or
to use the new macro names.
I am certainly in favour of having consistently named and located macros
for register fields.
SCTLR_EL2_FLAGS is a KVM-specific value (i.e. the SCTLR_EL2 flags which
KVM wants to set), even if it consists solely of common fields.
I believe it should stay here (with an include for <asm/sysreg.h>),
perhaps with a KVM_ prefix to imply it's not as generic as one might
assume it is.
@@ -105,8 +105,8 @@ __do_hyp_init:dsbsymrsx4,sctlr_el2-andx4,x4,#SCTLR_EL2_EE // preserve endianness of EL2-ldrx5,=SCTLR_EL2_FLAGS+andx4,x4,#SCTLR_ELx_EE // preserve endianness of EL2+ldrx5,=SCTLR_ELx_FLAGS
Marc, Christoffer, I note that in SCTLR_EL2_FLAGS we don't set the RES1
bits of SCTLR_EL2 (not in head.S el2_setup). Should we perhaps be doing
so so as to avoid any future surprises?
Yes, that's one of the numerous instances of the same problem - I think
Dave Martin also has some fixes in that area.
I'll definitely take patches!
M.
--
Jazz is not dead. It just smells funny...
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
(I thought that this approach was not smart as we have three different
ways to specify memory regions, dtb, efi and this kernel parameter.)
Do you have any other ideas?
Thanks,
-Takahiro AKASHI
Thanks,
Mark.
quoted
++2) Currently, kvm will not be enabled on the dump-capture kernel even+ if it is configured.+ Extended crashkernel syntax ===========================
@@ -312,6 +326,8 @@ Boot into System Kernel any space below the alignment point may be overwritten by the dump-capture kernel, which means it is possible that the vmcore is not that precise as expected.+ 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 ============================
@@ -334,6 +350,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.
@@ -377,6 +395,9 @@ For s390x: For arm: "1 maxcpus=1 reset_devices"+For arm64:+ "1 mem=X[MG] maxcpus=1 reset_devices"+ Notes on loading the dump-capture kernel: * By default, the ELF headers are stored in ELF64 format to support--
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
quoted
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
I'm not opposed to the idea of a DT property, though I think that should
live under /chosen.
I see that "linux,usable-memory" exists already, though I'm confused as
to exactly what it is for as there is no documentation (neither in the
kernel nor in ePAPR). It's also painful to alter multiple memory nodes
to use that, and I can see that going wrong.
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
I'm not too keen on this, as I think it's fragile, and logically
somewhat distinct from what mem= is for (a best effort testing tool).
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
A property under /chosen would work for EFI too.
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
(I thought that this approach was not smart as we have three different
ways to specify memory regions, dtb, efi and this kernel parameter.)
I'm not sure that's a big problem. We may be able to make this generic,
also.
We don't necessarily need a weak add memory function if we can guarantee
nothing gets memblock_alloc'd before we carve it out.
Something like the nomap stuff Ard put together might be useful here.
Thanks,
Mark.
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
quoted
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
I think it is X86 specific. Personally I think device tree property is
better.
Thanks
Dave
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
quoted
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
One reason about the changing is kernel cmdline space is limited. We need
to pass not only usable memory ranges, also reserved and other different
memory ranges, cmdline array size is not enough sometimes.
I think it is X86 specific. Personally I think device tree property is
better.
Thanks
Dave
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
quoted
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
I'm not opposed to the idea of a DT property, though I think that should
live under /chosen.
In fact, powerpc uses another property, "linux,crashkernel-base(& size)",
under /chosen in order for the *1st kernel* to export info about a memory
region for the 2nd(crash dump) kernel to user apps (kexec-tools).
I see that "linux,usable-memory" exists already, though I'm confused as
to exactly what it is for as there is no documentation (neither in the
kernel nor in ePAPR).
For example,
memory at 0x80000000 {
reg = <0x0 0x80000000 0x0 0x80000000>;
linux,usable-memory = <0x0 0x8c000000 0x0 0x4000000>;
}
There exists 2GB memory available on the system, but the last 64MB can be
used as a system ram. See early_init_dt_scan_memory() in fdt.c.
It's also painful to alter multiple memory nodes
to use that, and I can see that going wrong.
Yeah, I implemented this feature in my old versions experimentally,
but didn't like it as we had to touch all the memory nodes.
quoted
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
I'm not too keen on this, as I think it's fragile, and logically
somewhat distinct from what mem= is for (a best effort testing tool).
I'm not sure whether it is fragile, and contrary to x86, as Dave
described, I think we will only need a single memmap= on arm64 as
efi's mem map table is accessible even on the crash kernel.
quoted
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
A property under /chosen would work for EFI too.
quoted
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
(I thought that this approach was not smart as we have three different
ways to specify memory regions, dtb, efi and this kernel parameter.)
I'm not sure that's a big problem. We may be able to make this generic,
also.
We don't necessarily need a weak add memory function if we can guarantee
nothing gets memblock_alloc'd before we carve it out.
Something like the nomap stuff Ard put together might be useful here.
I'm afraid it doesn't work.
It doesn't matter whether it is linearly mapped or not. We should prevent
any part of memory regions used by the 1st kernel from being reclaimed
by memblock_alloc() and others.
Or do you mean we can introduce another memblock flag?
-Takahiro AKASHI
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
quoted
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
I think it is X86 specific. Personally I think device tree property is
better.
On Mon, Jan 18, 2016 at 10:12:18AM +0000, Marc Zyngier wrote:
On 15/01/16 20:07, Mark Rutland wrote:
[...]
quoted
Marc, Christoffer, I note that in SCTLR_EL2_FLAGS we don't set the RES1
bits of SCTLR_EL2 (not in head.S el2_setup). Should we perhaps be doing
so so as to avoid any future surprises?
Yes, that's one of the numerous instances of the same problem - I think
Dave Martin also has some fixes in that area.
I'll definitely take patches!
Yep, we have a similar problem with CPTR_EL2, patch to follow at some
point. There are likely other instances...
Cheers
---Dave
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
quoted
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
I'm not opposed to the idea of a DT property, though I think that should
live under /chosen.
In fact, powerpc uses another property, "linux,crashkernel-base(& size)",
under /chosen in order for the *1st kernel* to export info about a memory
region for the 2nd(crash dump) kernel to user apps (kexec-tools).
Do you mean that said property is provided _to_ the 1st kernel, or
provided _by_ the first kernel?
quoted
I see that "linux,usable-memory" exists already, though I'm confused as
to exactly what it is for as there is no documentation (neither in the
kernel nor in ePAPR).
For example,
memory at 0x80000000 {
reg = <0x0 0x80000000 0x0 0x80000000>;
linux,usable-memory = <0x0 0x8c000000 0x0 0x4000000>;
}
There exists 2GB memory available on the system, but the last 64MB can be
used as a system ram. See early_init_dt_scan_memory() in fdt.c.
Sure, except that's the implementation rather than the intended
semantics (which are not defined).
quoted
It's also painful to alter multiple memory nodes
to use that, and I can see that going wrong.
Yeah, I implemented this feature in my old versions experimentally,
but didn't like it as we had to touch all the memory nodes.
quoted
quoted
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
I'm not too keen on this, as I think it's fragile, and logically
somewhat distinct from what mem= is for (a best effort testing tool).
I'm not sure whether it is fragile, and contrary to x86, as Dave
described, I think we will only need a single memmap= on arm64 as
efi's mem map table is accessible even on the crash kernel.
I just realised I misread this as "mem=", apologies.
It looks like memmap= to force a specific region of memory to be used
may work.
I'd still err on the side of preferring an explicit property in the DT.
quoted
quoted
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
A property under /chosen would work for EFI too.
quoted
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
(I thought that this approach was not smart as we have three different
ways to specify memory regions, dtb, efi and this kernel parameter.)
I'm not sure that's a big problem. We may be able to make this generic,
also.
We don't necessarily need a weak add memory function if we can guarantee
nothing gets memblock_alloc'd before we carve it out.
Something like the nomap stuff Ard put together might be useful here.
I'm afraid it doesn't work.
It doesn't matter whether it is linearly mapped or not. We should prevent
any part of memory regions used by the 1st kernel from being reclaimed
by memblock_alloc() and others.
Are you certain that nomap memory can be allocated? That sounds like a
major bug.
Nomap memory should act like reserved memory with the additional
property that the kernel must not map it implicitly.
Or do you mean we can introduce another memblock flag?
That wasn't what I meant, but that would be a potential solution.
Thanks,
Mark.
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
quoted
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
This would imply modifying the EFI memory map or the memory nodes, which
I'm not keen on.
I would prefer that they are left _pristine_, and we describe the
restriction on the kdump kernel with additional properties under
/chosen.
That leaves us with more useful information about the environment of the
first kernel, is simpler for userspace (it's resilient to updates to the
UEFI memory map spec, for example), and is simple for the crash kernel.
I think it is X86 specific. Personally I think device tree property is
better.
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
quoted
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
quoted
I think it is X86 specific. Personally I think device tree property is
better.
Do you think so?
I'm not sure it is the best way. For X86 we run into problem with
memmap= design, one example is pci domain X (X>1) need the pci memory
ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem
to 2nd kernel we find that cmdline[] array is not big enough.
Do you think for arm64 only usable memory is necessary to let kdump kernel
know? I'm curious about how arm64 kernel get all memory layout from boot loader,
via UEFI memmap?
Thanks
Dave
From: Dave Young <hidden> Date: 2016-01-19 12:32:30
On 01/15/16 at 07:18pm, Geoff Levand wrote:
This series adds the core support for kexec re-boot and kdump on ARM64. This
version of the series combines Takahiro's kdump patches with my kexec patches.
Please consider all patches for inclusion.
I just tested all the endian combinations of kexec LE->LE, LE->BE, BE->BE,
BE->LE, and both LE an BE kdump, and all work as expected.
To load a second stage kernel and execute a kexec re-boot or to work with kdump
on ARM64 systems a series of patches to kexec-tools [2], which have not yet been
merged upstream, are needed.
To examine vmcore (/proc/vmcore), you should use
- gdb v7.7 or later
- crash v7.1.1 or later
[1] https://git.kernel.org/cgit/linux/kernel/git/geoff/linux-kexec.git
[2] https://git.kernel.org/cgit/linux/kernel/git/geoff/kexec-tools.git
Geoff, another question about kexec-tools part is, can the kexec-tools code
been written in kernel? We have the infrastructure for kexec_file_load.
In the future if we have to support loading a signed kernel then we still
need to do that, but we may have to support both the kexec-tools and the
in kernel loader for compatibility purpose. It will be hard to maintain.
Thanks
Dave
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
quoted
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
quoted
I think it is X86 specific. Personally I think device tree property is
better.
Do you think so?
I'm not sure it is the best way. For X86 we run into problem with
memmap= design, one example is pci domain X (X>1) need the pci memory
ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem
to 2nd kernel we find that cmdline[] array is not big enough.
I'm not sure how PCI ranges relate to the memory map used for normal
memory (i.e. RAM), though I'm probably missing some caveat with the way
ACPI and UEFI describe PCI. Why does memmap= affect PCI memory?
If the kernel got the rest of its system topology from DT, the PCI
regions would be described there.
Do you think for arm64 only usable memory is necessary to let kdump kernel
know? I'm curious about how arm64 kernel get all memory layout from boot loader,
via UEFI memmap?
When booted via EFI, we use the EFI memory map. The EFI stub handles
acquring the relevant information and passing that to the first kernel
in the DTB (see Documentation/arm/uefi.txt).
A kexec'd kernel should simply inherit that. So long as the DTB and/or
UEFI tables in memory are the same, it would be the same as a cold boot.
In the !EFI case, we use the memory nodes in the DTB. Only in this case
could usable-memory properties in memory nodes make sense. I'd prefer a
uniform property under /chosen for both cases.
Thanks,
Mark.
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
quoted
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
quoted
I think it is X86 specific. Personally I think device tree property is
better.
Do you think so?
I'm not sure it is the best way. For X86 we run into problem with
memmap= design, one example is pci domain X (X>1) need the pci memory
ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem
to 2nd kernel we find that cmdline[] array is not big enough.
I'm not sure how PCI ranges relate to the memory map used for normal
memory (i.e. RAM), though I'm probably missing some caveat with the way
ACPI and UEFI describe PCI. Why does memmap= affect PCI memory?
If the kernel got the rest of its system topology from DT, the PCI
regions would be described there.
Yes, if kdump kernel use same DT as 1st kernel.
quoted
Do you think for arm64 only usable memory is necessary to let kdump kernel
know? I'm curious about how arm64 kernel get all memory layout from boot loader,
via UEFI memmap?
When booted via EFI, we use the EFI memory map. The EFI stub handles
acquring the relevant information and passing that to the first kernel
in the DTB (see Documentation/arm/uefi.txt).
Ok, thanks for the pointer. So in dt we are just have uefi memmap infomation
instead of memory nodes details..
A kexec'd kernel should simply inherit that. So long as the DTB and/or
UEFI tables in memory are the same, it would be the same as a cold boot.
For kexec all memory ranges are same, for kdump we need use original reserved
range with crashkernel= as usable memory and all other orignal usable ranges
are not usable anymore.
Is it possible to modify uefi memmap for kdump case?
In the !EFI case, we use the memory nodes in the DTB. Only in this case
could usable-memory properties in memory nodes make sense. I'd prefer a
uniform property under /chosen for both cases.
We stil use same DTB, need to modify the DT and update the usable and unusable
nodes for kdump?
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
quoted
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
This would imply modifying the EFI memory map or the memory nodes, which
I'm not keen on.
I would prefer that they are left _pristine_, and we describe the
restriction on the kdump kernel with additional properties under
/chosen.
That leaves us with more useful information about the environment of the
first kernel, is simpler for userspace (it's resilient to updates to the
UEFI memory map spec, for example), and is simple for the crash kernel.
In theory kexec as boot loader should prepare correct efi memmap and pass
to kernel, but as you said yes it will increase complexity. We need banlance
them.
Thanks
Dave
On Tue, Jan 19, 2016 at 09:45:53PM +0800, Dave Young wrote:
On 01/19/16 at 12:51pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 02:35pm, AKASHI Takahiro wrote:
quoted
On 01/19/2016 10:43 AM, Dave Young wrote:
quoted
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
quoted
I think it is X86 specific. Personally I think device tree property is
better.
Do you think so?
I'm not sure it is the best way. For X86 we run into problem with
memmap= design, one example is pci domain X (X>1) need the pci memory
ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem
to 2nd kernel we find that cmdline[] array is not big enough.
I'm not sure how PCI ranges relate to the memory map used for normal
memory (i.e. RAM), though I'm probably missing some caveat with the way
ACPI and UEFI describe PCI. Why does memmap= affect PCI memory?
If the kernel got the rest of its system topology from DT, the PCI
regions would be described there.
Yes, if kdump kernel use same DT as 1st kernel.
Other than for testing purposes, I don't see why you'd pass the kdump
kernel a DTB inconsistent with that the 1st kernel was passsed (other
than some proerties under /chosen).
We added /sys/firmware/fdt specifically to allow the kexec tools to get
the exact DTB the first kernel used. There's no reason for tools to have
to make something up.
quoted
quoted
Do you think for arm64 only usable memory is necessary to let kdump kernel
know? I'm curious about how arm64 kernel get all memory layout from boot loader,
via UEFI memmap?
When booted via EFI, we use the EFI memory map. The EFI stub handles
acquring the relevant information and passing that to the first kernel
in the DTB (see Documentation/arm/uefi.txt).
Ok, thanks for the pointer. So in dt we are just have uefi memmap infomation
instead of memory nodes details..
When booted via EFI, yes.
For NUMA topology in !ACPI kernels, we might need to also retain and
parse memory nodes, but only for toplogy information. The kernel would
still only use memory as described by the EFI memory map.
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
quoted
A kexec'd kernel should simply inherit that. So long as the DTB and/or
UEFI tables in memory are the same, it would be the same as a cold boot.
For kexec all memory ranges are same, for kdump we need use original reserved
range with crashkernel= as usable memory and all other orignal usable ranges
are not usable anymore.
Sure. This is what I believe we should expose with an additional
property under /chosen, while keeping everything else pristine.
The crash kernel can then limit itself to that region, while it would
have the information of the full memory map (which it could log and/or
use to drive other dumping).
Is it possible to modify uefi memmap for kdump case?
Technically it would be possible, however I don't think it's necessary,
and I think it would be disadvantageous to do so.
Describing the range(s) the crash kernel can use in separate properties
under /chosen has a number of advantages.
quoted
In the !EFI case, we use the memory nodes in the DTB. Only in this case
could usable-memory properties in memory nodes make sense. I'd prefer a
uniform property under /chosen for both cases.
We stil use same DTB, need to modify the DT and update the usable and unusable
nodes for kdump?
We'd have a (slightly) modified DTB that contained additional properties
describing the range(s) reserved for use by the crash kernel.
Other than those properties under /chosen (e.g. the command line, initrd
pointers if any), it would be the original DTB.
Thanks,
Mark.
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
quoted
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
This would imply modifying the EFI memory map or the memory nodes, which
I'm not keen on.
I would prefer that they are left _pristine_, and we describe the
restriction on the kdump kernel with additional properties under
/chosen.
That leaves us with more useful information about the environment of the
first kernel, is simpler for userspace (it's resilient to updates to the
UEFI memory map spec, for example), and is simple for the crash kernel.
In theory kexec as boot loader should prepare correct efi memmap and pass
to kernel, but as you said yes it will increase complexity. We need banlance
them.
I'd argue that the "correct efi memmap" is what we were given by the
firmware initially -- none of that information is any less true.
For kdump all we need to ensure is that the kdump kernel only uses the
memory that was specially reserved for it by the first kernel. The
simplest way of doing that is to tell the kdump kernel which specific
region(s) of memory were reserved for it, leaving the EFI memory map
alone.
Thanks,
Mark.
From: Dave Young <hidden> Date: 2016-01-20 02:49:46
On 01/19/16 at 02:01pm, Mark Rutland wrote:
On Tue, Jan 19, 2016 at 09:45:53PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 12:51pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 02:35pm, AKASHI Takahiro wrote:
quoted
On 01/19/2016 10:43 AM, Dave Young wrote:
quoted
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
quoted
I think it is X86 specific. Personally I think device tree property is
better.
Do you think so?
I'm not sure it is the best way. For X86 we run into problem with
memmap= design, one example is pci domain X (X>1) need the pci memory
ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem
to 2nd kernel we find that cmdline[] array is not big enough.
I'm not sure how PCI ranges relate to the memory map used for normal
memory (i.e. RAM), though I'm probably missing some caveat with the way
ACPI and UEFI describe PCI. Why does memmap= affect PCI memory?
If the kernel got the rest of its system topology from DT, the PCI
regions would be described there.
Yes, if kdump kernel use same DT as 1st kernel.
Other than for testing purposes, I don't see why you'd pass the kdump
kernel a DTB inconsistent with that the 1st kernel was passsed (other
than some proerties under /chosen).
We added /sys/firmware/fdt specifically to allow the kexec tools to get
the exact DTB the first kernel used. There's no reason for tools to have
to make something up.
Agreed, but kexec-tools has an option to pass in any dtb files. Who knows
how one will use it unless dropping the option and use /sys/firmware/fdt
unconditionally.
If we choose to implement kexec_file_load only in kernel, the interfaces
provided are kernel, initrd and cmdline. We can always use same dtb.
quoted
quoted
quoted
Do you think for arm64 only usable memory is necessary to let kdump kernel
know? I'm curious about how arm64 kernel get all memory layout from boot loader,
via UEFI memmap?
When booted via EFI, we use the EFI memory map. The EFI stub handles
acquring the relevant information and passing that to the first kernel
in the DTB (see Documentation/arm/uefi.txt).
Ok, thanks for the pointer. So in dt we are just have uefi memmap infomation
instead of memory nodes details..
When booted via EFI, yes.
For NUMA topology in !ACPI kernels, we might need to also retain and
parse memory nodes, but only for toplogy information. The kernel would
still only use memory as described by the EFI memory map.
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
Firmware do not know kernel endianniess, kernel should respect firmware
maps and adapt to it, it sounds like a generic issue not specfic to kexec.
quoted
quoted
A kexec'd kernel should simply inherit that. So long as the DTB and/or
UEFI tables in memory are the same, it would be the same as a cold boot.
For kexec all memory ranges are same, for kdump we need use original reserved
range with crashkernel= as usable memory and all other orignal usable ranges
are not usable anymore.
Sure. This is what I believe we should expose with an additional
property under /chosen, while keeping everything else pristine.
The crash kernel can then limit itself to that region, while it would
have the information of the full memory map (which it could log and/or
use to drive other dumping).
In this way kernel should be aware it is a kdump booting, it is doable though
I feel it is better for kdump kernel in a black box with infomations it
can use just like the 1st kernel. Things here is where we choose to cook
the memory infomation in boot loader or in kernel itself.
quoted
Is it possible to modify uefi memmap for kdump case?
Technically it would be possible, however I don't think it's necessary,
and I think it would be disadvantageous to do so.
Describing the range(s) the crash kernel can use in separate properties
under /chosen has a number of advantages.
Ok, I got the points. We have a is_kdump_kernel() by checking if there is
elfcorehdr_addr kernel cmdline. This is mainly for some drivers which
do not work well in kdump kernel some uncertain reasons. But ideally I
think kernel should handle things just like in 1st kernel and avoid to use
it.
quoted
quoted
In the !EFI case, we use the memory nodes in the DTB. Only in this case
could usable-memory properties in memory nodes make sense. I'd prefer a
uniform property under /chosen for both cases.
We stil use same DTB, need to modify the DT and update the usable and unusable
nodes for kdump?
We'd have a (slightly) modified DTB that contained additional properties
describing the range(s) reserved for use by the crash kernel.
Other than those properties under /chosen (e.g. the command line, initrd
pointers if any), it would be the original DTB.
Thanks,
Mark.
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
quoted
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
This would imply modifying the EFI memory map or the memory nodes, which
I'm not keen on.
I would prefer that they are left _pristine_, and we describe the
restriction on the kdump kernel with additional properties under
/chosen.
That leaves us with more useful information about the environment of the
first kernel, is simpler for userspace (it's resilient to updates to the
UEFI memory map spec, for example), and is simple for the crash kernel.
In theory kexec as boot loader should prepare correct efi memmap and pass
to kernel, but as you said yes it will increase complexity. We need banlance
them.
I'd argue that the "correct efi memmap" is what we were given by the
firmware initially -- none of that information is any less true.
In X86 boot loader will cook a E820 map for kernel use, there's no such needs
in arm so maybe it is acceptable to use same memmap to avoid modifying it only
for kdump.
I think I will not insist though I like more about doing something in
bootloader instead of in kernel.
For kdump all we need to ensure is that the kdump kernel only uses the
memory that was specially reserved for it by the first kernel. The
simplest way of doing that is to tell the kdump kernel which specific
region(s) of memory were reserved for it, leaving the EFI memory map
alone.
@@ -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,20 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y+Dump-capture kernel config options (Arch Dependent, arm64)+----------------------------------------------------------++1) The maximum memory size on the dump-capture kernel must be limited by+ specifying:++ mem=X[MG]++ where X should be less than or equal to the size in "crashkernel="+ boot parameter. Kexec-tools will automatically add this.
This is extremely fragile, and will trivially fail when the kernel can
be loaded anywhere (see [1]).
As I said before, this restriction also exists on arm, but I understand
that recent Ard's patches break it.
quoted
We must explicitly describe the set of regions the crash kernel may use
(i.e. we need base and size). NAK in the absence of that.
There seem to exist several approaches:
(a) use a device-tree property, "linux,usable-memory", in addition to "reg"
I'm not opposed to the idea of a DT property, though I think that should
live under /chosen.
In fact, powerpc uses another property, "linux,crashkernel-base(& size)",
under /chosen in order for the *1st kernel* to export info about a memory
region for the 2nd(crash dump) kernel to user apps (kexec-tools).
Do you mean that said property is provided _to_ the 1st kernel, or
provided _by_ the first kernel?
_by_ the 1st kernel.
Based on a kernel parameter, "crashkernel=", the 1st kernel reserve some
memory region at boot time and export its information through this property.
Most architectures other than powerpc, however, use an iomem resource entry,
"Crash kernel", in /proc/iomem instead for this purpose.
quoted
quoted
I see that "linux,usable-memory" exists already, though I'm confused as
to exactly what it is for as there is no documentation (neither in the
kernel nor in ePAPR).
For example,
memory at 0x80000000 {
reg = <0x0 0x80000000 0x0 0x80000000>;
linux,usable-memory = <0x0 0x8c000000 0x0 0x4000000>;
}
There exists 2GB memory available on the system, but the last 64MB can be
used as a system ram. See early_init_dt_scan_memory() in fdt.c.
Sure, except that's the implementation rather than the intended
semantics (which are not defined).
Yeah, but the code itself was ack'ed (actually committed) by Grant:)
quoted
quoted
It's also painful to alter multiple memory nodes
to use that, and I can see that going wrong.
Yeah, I implemented this feature in my old versions experimentally,
but didn't like it as we had to touch all the memory nodes.
quoted
quoted
under "memory" node
(b) use a kernel's early parameter, "memmap=nn[@#$]ss"
I'm not too keen on this, as I think it's fragile, and logically
somewhat distinct from what mem= is for (a best effort testing tool).
I'm not sure whether it is fragile, and contrary to x86, as Dave
described, I think we will only need a single memmap= on arm64 as
efi's mem map table is accessible even on the crash kernel.
I just realised I misread this as "mem=", apologies.
It looks like memmap= to force a specific region of memory to be used
may work.
I'd still err on the side of preferring an explicit property in the DT.
Let's discuss in succeeding replies.
quoted
quoted
quoted
Power PC takes (a), while this does not work on efi-started kernel
because dtb has no "memory" nodes under efi.
A property under /chosen would work for EFI too.
quoted
X86 takes (b). If we take this, we will need to overwrite a weak
early_init_dt_add_memory().
(I thought that this approach was not smart as we have three different
ways to specify memory regions, dtb, efi and this kernel parameter.)
I'm not sure that's a big problem. We may be able to make this generic,
also.
We don't necessarily need a weak add memory function if we can guarantee
nothing gets memblock_alloc'd before we carve it out.
Something like the nomap stuff Ard put together might be useful here.
I'm afraid it doesn't work.
It doesn't matter whether it is linearly mapped or not. We should prevent
any part of memory regions used by the 1st kernel from being reclaimed
by memblock_alloc() and others.
Are you certain that nomap memory can be allocated? That sounds like a
major bug.
I misunderstood. __next_mem_range() called by mem_alloc stuff has some check.
-Takahiro AKASHI
Nomap memory should act like reserved memory with the additional
property that the kernel must not map it implicitly.
quoted
Or do you mean we can introduce another memblock flag?
That wasn't what I meant, but that would be a potential solution.
Thanks,
Mark.
On Tue, Jan 19, 2016 at 09:45:53PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 12:51pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 02:35pm, AKASHI Takahiro wrote:
quoted
On 01/19/2016 10:43 AM, Dave Young wrote:
quoted
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
quoted
I think it is X86 specific. Personally I think device tree property is
better.
Do you think so?
I'm not sure it is the best way. For X86 we run into problem with
memmap= design, one example is pci domain X (X>1) need the pci memory
ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem
to 2nd kernel we find that cmdline[] array is not big enough.
I'm not sure how PCI ranges relate to the memory map used for normal
memory (i.e. RAM), though I'm probably missing some caveat with the way
ACPI and UEFI describe PCI. Why does memmap= affect PCI memory?
If the kernel got the rest of its system topology from DT, the PCI
regions would be described there.
Yes, if kdump kernel use same DT as 1st kernel.
Other than for testing purposes, I don't see why you'd pass the kdump
kernel a DTB inconsistent with that the 1st kernel was passsed (other
than some proerties under /chosen).
We added /sys/firmware/fdt specifically to allow the kexec tools to get
the exact DTB the first kernel used. There's no reason for tools to have
to make something up.
Currently, arm64 kexec-tools modifies only a cmdline property in dtb
to pass a "elfcorehdr=" parameter as well as other restrictions (like maxcpus=1).
quoted
quoted
quoted
Do you think for arm64 only usable memory is necessary to let kdump kernel
know? I'm curious about how arm64 kernel get all memory layout from boot loader,
via UEFI memmap?
When booted via EFI, we use the EFI memory map. The EFI stub handles
acquring the relevant information and passing that to the first kernel
in the DTB (see Documentation/arm/uefi.txt).
Ok, thanks for the pointer. So in dt we are just have uefi memmap infomation
instead of memory nodes details..
When booted via EFI, yes.
For NUMA topology in !ACPI kernels, we might need to also retain and
parse memory nodes, but only for toplogy information. The kernel would
still only use memory as described by the EFI memory map.
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
BE kernel doesn't support UEFI yet and cannot access UEFI memmap table. So,
for LE -> BE, we don't use a dtb generated from /sys/firmware/fdt (or /proc/device-tree)
(as in the case of LE -> LE) and require users to provide a dtb file explicitly.
For BE -> LE, BE kernel doesn't know wther UEFI memmap table is available or not
and so use the same (explicitly-provided) dtb (as LE -> LE in !UEFI)
quoted
quoted
A kexec'd kernel should simply inherit that. So long as the DTB and/or
UEFI tables in memory are the same, it would be the same as a cold boot.
For kexec all memory ranges are same, for kdump we need use original reserved
range with crashkernel= as usable memory and all other orignal usable ranges
are not usable anymore.
Sure. This is what I believe we should expose with an additional
property under /chosen, while keeping everything else pristine.
The crash kernel can then limit itself to that region, while it would
have the information of the full memory map (which it could log and/or
use to drive other dumping).
FYI,
all the original usable memory regions used by the 1st kernel are also
described in an ELF core header specified by "elfcorehdr=" parameter to
the crash dump kernel.
-Takahiro AKASHI
quoted
Is it possible to modify uefi memmap for kdump case?
Technically it would be possible, however I don't think it's necessary,
and I think it would be disadvantageous to do so.
Describing the range(s) the crash kernel can use in separate properties
under /chosen has a number of advantages.
quoted
quoted
In the !EFI case, we use the memory nodes in the DTB. Only in this case
could usable-memory properties in memory nodes make sense. I'd prefer a
uniform property under /chosen for both cases.
We stil use same DTB, need to modify the DT and update the usable and unusable
nodes for kdump?
We'd have a (slightly) modified DTB that contained additional properties
describing the range(s) reserved for use by the crash kernel.
Other than those properties under /chosen (e.g. the command line, initrd
pointers if any), it would be the original DTB.
Thanks,
Mark.
On Tue, Jan 19, 2016 at 09:45:53PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 12:51pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 02:35pm, AKASHI Takahiro wrote:
quoted
On 01/19/2016 10:43 AM, Dave Young wrote:
quoted
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
quoted
I think it is X86 specific. Personally I think device tree property is
better.
Do you think so?
I'm not sure it is the best way. For X86 we run into problem with
memmap= design, one example is pci domain X (X>1) need the pci memory
ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem
to 2nd kernel we find that cmdline[] array is not big enough.
I'm not sure how PCI ranges relate to the memory map used for normal
memory (i.e. RAM), though I'm probably missing some caveat with the way
ACPI and UEFI describe PCI. Why does memmap= affect PCI memory?
If the kernel got the rest of its system topology from DT, the PCI
regions would be described there.
Yes, if kdump kernel use same DT as 1st kernel.
Other than for testing purposes, I don't see why you'd pass the kdump
kernel a DTB inconsistent with that the 1st kernel was passsed (other
than some proerties under /chosen).
We added /sys/firmware/fdt specifically to allow the kexec tools to get
the exact DTB the first kernel used. There's no reason for tools to have
to make something up.
Agreed, but kexec-tools has an option to pass in any dtb files. Who knows
how one will use it unless dropping the option and use /sys/firmware/fdt
unconditionally.
As a matter of fact, specifying proper command line parameters as well as
dtb is partly users' responsibility for kdump to work correctly.
(especially for BE kernel)
If we choose to implement kexec_file_load only in kernel, the interfaces
provided are kernel, initrd and cmdline. We can always use same dtb.
I would say that we can always use the same dtb even with kexec_load
from user's perspective. Right?
(The difference is whether changes are made by kernel itself or kexec-tools.)
quoted
quoted
quoted
quoted
Do you think for arm64 only usable memory is necessary to let kdump kernel
know? I'm curious about how arm64 kernel get all memory layout from boot loader,
via UEFI memmap?
When booted via EFI, we use the EFI memory map. The EFI stub handles
acquring the relevant information and passing that to the first kernel
in the DTB (see Documentation/arm/uefi.txt).
Ok, thanks for the pointer. So in dt we are just have uefi memmap infomation
instead of memory nodes details..
When booted via EFI, yes.
For NUMA topology in !ACPI kernels, we might need to also retain and
parse memory nodes, but only for toplogy information. The kernel would
still only use memory as described by the EFI memory map.
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
Firmware do not know kernel endianniess, kernel should respect firmware
maps and adapt to it, it sounds like a generic issue not specfic to kexec.
On arm64, a kernel image header has a bit field to specify the image's endianness.
Anyway, our current implementation replies on a user-supplied dtb to start BE kernel.
quoted
quoted
quoted
A kexec'd kernel should simply inherit that. So long as the DTB and/or
UEFI tables in memory are the same, it would be the same as a cold boot.
For kexec all memory ranges are same, for kdump we need use original reserved
range with crashkernel= as usable memory and all other orignal usable ranges
are not usable anymore.
Sure. This is what I believe we should expose with an additional
property under /chosen, while keeping everything else pristine.
The crash kernel can then limit itself to that region, while it would
have the information of the full memory map (which it could log and/or
use to drive other dumping).
In this way kernel should be aware it is a kdump booting, it is doable though
I feel it is better for kdump kernel in a black box with infomations it
can use just like the 1st kernel. Things here is where we choose to cook
the memory infomation in boot loader or in kernel itself.
quoted
quoted
Is it possible to modify uefi memmap for kdump case?
Technically it would be possible, however I don't think it's necessary,
and I think it would be disadvantageous to do so.
Describing the range(s) the crash kernel can use in separate properties
under /chosen has a number of advantages.
Ok, I got the points. We have a is_kdump_kernel() by checking if there is
elfcorehdr_addr kernel cmdline. This is mainly for some drivers which
do not work well in kdump kernel some uncertain reasons. But ideally I
think kernel should handle things just like in 1st kernel and avoid to use
it.
So I'm not still sure about what are advantages of a property under /chosen
over "memmap=" kernel parameter.
Both are simple and can have the same effect with minimizing changes to dtb.
(But if, in the latter case, we have to provide *all* the memory-related information
through "memmap=" parameters, it would be much complicated.)
-Takahiro AKASHI
quoted
quoted
quoted
In the !EFI case, we use the memory nodes in the DTB. Only in this case
could usable-memory properties in memory nodes make sense. I'd prefer a
uniform property under /chosen for both cases.
We stil use same DTB, need to modify the DT and update the usable and unusable
nodes for kdump?
We'd have a (slightly) modified DTB that contained additional properties
describing the range(s) reserved for use by the crash kernel.
Other than those properties under /chosen (e.g. the command line, initrd
pointers if any), it would be the original DTB.
Thanks,
Mark.
From: Dave Young <hidden> Date: 2016-01-20 06:38:56
On 01/20/16 at 03:07pm, AKASHI Takahiro wrote:
On 01/20/2016 11:49 AM, Dave Young wrote:
quoted
On 01/19/16 at 02:01pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 09:45:53PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 12:51pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 02:35pm, AKASHI Takahiro wrote:
quoted
On 01/19/2016 10:43 AM, Dave Young wrote:
quoted
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
quoted
I think it is X86 specific. Personally I think device tree property is
better.
Do you think so?
I'm not sure it is the best way. For X86 we run into problem with
memmap= design, one example is pci domain X (X>1) need the pci memory
ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem
to 2nd kernel we find that cmdline[] array is not big enough.
I'm not sure how PCI ranges relate to the memory map used for normal
memory (i.e. RAM), though I'm probably missing some caveat with the way
ACPI and UEFI describe PCI. Why does memmap= affect PCI memory?
If the kernel got the rest of its system topology from DT, the PCI
regions would be described there.
Yes, if kdump kernel use same DT as 1st kernel.
Other than for testing purposes, I don't see why you'd pass the kdump
kernel a DTB inconsistent with that the 1st kernel was passsed (other
than some proerties under /chosen).
We added /sys/firmware/fdt specifically to allow the kexec tools to get
the exact DTB the first kernel used. There's no reason for tools to have
to make something up.
Agreed, but kexec-tools has an option to pass in any dtb files. Who knows
how one will use it unless dropping the option and use /sys/firmware/fdt
unconditionally.
As a matter of fact, specifying proper command line parameters as well as
dtb is partly users' responsibility for kdump to work correctly.
(especially for BE kernel)
Right.
quoted
If we choose to implement kexec_file_load only in kernel, the interfaces
provided are kernel, initrd and cmdline. We can always use same dtb.
I would say that we can always use the same dtb even with kexec_load
from user's perspective. Right?
(The difference is whether changes are made by kernel itself or kexec-tools.)
Right.
quoted
quoted
quoted
quoted
quoted
Do you think for arm64 only usable memory is necessary to let kdump kernel
know? I'm curious about how arm64 kernel get all memory layout from boot loader,
via UEFI memmap?
When booted via EFI, we use the EFI memory map. The EFI stub handles
acquring the relevant information and passing that to the first kernel
in the DTB (see Documentation/arm/uefi.txt).
Ok, thanks for the pointer. So in dt we are just have uefi memmap infomation
instead of memory nodes details..
When booted via EFI, yes.
For NUMA topology in !ACPI kernels, we might need to also retain and
parse memory nodes, but only for toplogy information. The kernel would
still only use memory as described by the EFI memory map.
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
Firmware do not know kernel endianniess, kernel should respect firmware
maps and adapt to it, it sounds like a generic issue not specfic to kexec.
On arm64, a kernel image header has a bit field to specify the image's endianness.
Anyway, our current implementation replies on a user-supplied dtb to start BE kernel.
Ok, I means uefi memmap are same, not specific to LE or BE.
quoted
quoted
quoted
quoted
A kexec'd kernel should simply inherit that. So long as the DTB and/or
UEFI tables in memory are the same, it would be the same as a cold boot.
For kexec all memory ranges are same, for kdump we need use original reserved
range with crashkernel= as usable memory and all other orignal usable ranges
are not usable anymore.
Sure. This is what I believe we should expose with an additional
property under /chosen, while keeping everything else pristine.
The crash kernel can then limit itself to that region, while it would
have the information of the full memory map (which it could log and/or
use to drive other dumping).
In this way kernel should be aware it is a kdump booting, it is doable though
I feel it is better for kdump kernel in a black box with infomations it
can use just like the 1st kernel. Things here is where we choose to cook
the memory infomation in boot loader or in kernel itself.
quoted
quoted
Is it possible to modify uefi memmap for kdump case?
Technically it would be possible, however I don't think it's necessary,
and I think it would be disadvantageous to do so.
Describing the range(s) the crash kernel can use in separate properties
under /chosen has a number of advantages.
Ok, I got the points. We have a is_kdump_kernel() by checking if there is
elfcorehdr_addr kernel cmdline. This is mainly for some drivers which
do not work well in kdump kernel some uncertain reasons. But ideally I
think kernel should handle things just like in 1st kernel and avoid to use
it.
So I'm not still sure about what are advantages of a property under /chosen
over "memmap=" kernel parameter.
Both are simple and can have the same effect with minimizing changes to dtb.
(But if, in the latter case, we have to provide *all* the memory-related information
through "memmap=" parameters, it would be much complicated.)
Maybe I did not say it clearly, I prefer kexec syscall/tool to modifiy dtb
or uefi-memmap so that we do not need any extra kernel cmdline.
For x86 we would like to drop the memmap= usage in kexec-tools but we can not
do that for a compatibility problem about calgary iommu. So that currently
kexec-tools supports both recreating E820 maps and passing memmap=.
We should think it carefully because it will be hard to remove once we support it.
IMO handling it in code is better than using an external interface.
-Takahiro AKASHI
quoted
quoted
quoted
quoted
In the !EFI case, we use the memory nodes in the DTB. Only in this case
could usable-memory properties in memory nodes make sense. I'd prefer a
uniform property under /chosen for both cases.
We stil use same DTB, need to modify the DT and update the usable and unusable
nodes for kdump?
We'd have a (slightly) modified DTB that contained additional properties
describing the range(s) reserved for use by the crash kernel.
Other than those properties under /chosen (e.g. the command line, initrd
pointers if any), it would be the original DTB.
Thanks,
Mark.
From: Dave Young <hidden> Date: 2016-01-20 07:00:44
quoted
So I'm not still sure about what are advantages of a property under /chosen
over "memmap=" kernel parameter.
Both are simple and can have the same effect with minimizing changes to dtb.
(But if, in the latter case, we have to provide *all* the memory-related information
through "memmap=" parameters, it would be much complicated.)
Maybe I did not say it clearly, I prefer kexec syscall/tool to modifiy dtb
or uefi-memmap so that we do not need any extra kernel cmdline.
For x86 we would like to drop the memmap= usage in kexec-tools but we can not
do that for a compatibility problem about calgary iommu. So that currently
kexec-tools supports both recreating E820 maps and passing memmap=.
We should think it carefully because it will be hard to remove once we support it.
IMO handling it in code is better than using an external interface.
Also seems semantic of memmap=exactmap is different than current use in the implementation
exactmap means we need pass each range seperately including reserved, acpi and other types
We can not reuse ranges in uefi memmap for other than usable memory.
It will also have the cmdline array size issue.
Thanks
Dave
So I'm not still sure about what are advantages of a property under /chosen
over "memmap=" kernel parameter.
Both are simple and can have the same effect with minimizing changes to dtb.
(But if, in the latter case, we have to provide *all* the memory-related information
through "memmap=" parameters, it would be much complicated.)
Maybe I did not say it clearly, I prefer kexec syscall/tool to modifiy dtb
or uefi-memmap so that we do not need any extra kernel cmdline.
Yes, I understand.
But on arm64, kexec-tools can generate a "memmap=" parameter for crash kernel's
memory region without any user's interaction.
(please note that this parameter eventually goes into dtb's cmdline property in
/chosen.)
In this sense, it is no different from an extra property under /chosen
as kexec-tools can also add it to dtb passed to the crash dump kernel.
(See what I mean?)
quoted
For x86 we would like to drop the memmap= usage in kexec-tools
I didn't know that :)
quoted
but we can not
do that for a compatibility problem about calgary iommu. So that currently
kexec-tools supports both recreating E820 maps and passing memmap=.
We should think it carefully because it will be hard to remove once we support it.
Absolutely.
quoted
IMO handling it in code is better than using an external interface.
Also seems semantic of memmap=exactmap is different than current use in the implementation
exactmap means we need pass each range seperately including reserved, acpi and other types
We can not reuse ranges in uefi memmap for other than usable memory.
If necessary, we may use a different name, say, "usablememmap=" for arm64
or just extend "mem=" semantics (allowing XX at YY format) to avoid any confusion.
Thanks,
-Takahiro AKASHI
From: Dave Young <hidden> Date: 2016-01-20 08:26:17
On 01/20/16 at 05:01pm, AKASHI Takahiro wrote:
On 01/20/2016 04:00 PM, Dave Young wrote:
quoted
quoted
quoted
So I'm not still sure about what are advantages of a property under /chosen
over "memmap=" kernel parameter.
Both are simple and can have the same effect with minimizing changes to dtb.
(But if, in the latter case, we have to provide *all* the memory-related information
through "memmap=" parameters, it would be much complicated.)
Maybe I did not say it clearly, I prefer kexec syscall/tool to modifiy dtb
or uefi-memmap so that we do not need any extra kernel cmdline.
Yes, I understand.
But on arm64, kexec-tools can generate a "memmap=" parameter for crash kernel's
memory region without any user's interaction.
(please note that this parameter eventually goes into dtb's cmdline property in
/chosen.)
In this sense, it is no different from an extra property under /chosen
as kexec-tools can also add it to dtb passed to the crash dump kernel.
(See what I mean?)
I think I understand your points, what I would prefer is not an extra property
but modifying uefi memmap or recreating memory nodes for !EFI to be used in kdump kernel.
quoted
quoted
For x86 we would like to drop the memmap= usage in kexec-tools
I didn't know that :)
quoted
quoted
but we can not
do that for a compatibility problem about calgary iommu. So that currently
kexec-tools supports both recreating E820 maps and passing memmap=.
We should think it carefully because it will be hard to remove once we support it.
Absolutely.
quoted
quoted
IMO handling it in code is better than using an external interface.
Also seems semantic of memmap=exactmap is different than current use in the implementation
exactmap means we need pass each range seperately including reserved, acpi and other types
We can not reuse ranges in uefi memmap for other than usable memory.
If necessary, we may use a different name, say, "usablememmap=" for arm64
or just extend "mem=" semantics (allowing XX at YY format) to avoid any confusion.
For either of above what is the 1st kernel behavior with these params?
Thanks,
-Takahiro AKASHI
quoted
It will also have the cmdline array size issue.k
Thanks
Dave
On Wed, Jan 20, 2016 at 10:49:46AM +0800, Dave Young wrote:
On 01/19/16 at 02:01pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 09:45:53PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 12:51pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 02:35pm, AKASHI Takahiro wrote:
quoted
On 01/19/2016 10:43 AM, Dave Young wrote:
quoted
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
quoted
I think it is X86 specific. Personally I think device tree property is
better.
Do you think so?
I'm not sure it is the best way. For X86 we run into problem with
memmap= design, one example is pci domain X (X>1) need the pci memory
ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem
to 2nd kernel we find that cmdline[] array is not big enough.
I'm not sure how PCI ranges relate to the memory map used for normal
memory (i.e. RAM), though I'm probably missing some caveat with the way
ACPI and UEFI describe PCI. Why does memmap= affect PCI memory?
If the kernel got the rest of its system topology from DT, the PCI
regions would be described there.
Yes, if kdump kernel use same DT as 1st kernel.
Other than for testing purposes, I don't see why you'd pass the kdump
kernel a DTB inconsistent with that the 1st kernel was passsed (other
than some proerties under /chosen).
We added /sys/firmware/fdt specifically to allow the kexec tools to get
the exact DTB the first kernel used. There's no reason for tools to have
to make something up.
Agreed, but kexec-tools has an option to pass in any dtb files. Who knows
how one will use it unless dropping the option and use /sys/firmware/fdt
unconditionally.
I think this is a tangential discussion. I think it's fine to say that
for kdump we do not expect this -- a user would be shooting themselves
in the foot if they did. Regardless, I was under the impression that
kdump was usually set up by distribution-provided init code.
or kdump, which typically is set up automatically by the OS,
If we choose to implement kexec_file_load only in kernel, the interfaces
provided are kernel, initrd and cmdline. We can always use same dtb.
There are use-cases where being in complete control of the purgatory
code is necessary. For example, the next OS might not be Linux (and
might not accept a DTB, or have different requirements on the initial
register state).
Regardless of the need for something like kexec_file_load for kdump in
Secure Boot environments, there is also a need for kexec_load with the
user having complete control.
quoted
quoted
quoted
quoted
Do you think for arm64 only usable memory is necessary to let kdump kernel
know? I'm curious about how arm64 kernel get all memory layout from boot loader,
via UEFI memmap?
When booted via EFI, we use the EFI memory map. The EFI stub handles
acquring the relevant information and passing that to the first kernel
in the DTB (see Documentation/arm/uefi.txt).
Ok, thanks for the pointer. So in dt we are just have uefi memmap infomation
instead of memory nodes details..
When booted via EFI, yes.
For NUMA topology in !ACPI kernels, we might need to also retain and
parse memory nodes, but only for toplogy information. The kernel would
still only use memory as described by the EFI memory map.
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
Firmware do not know kernel endianniess, kernel should respect firmware
maps and adapt to it, it sounds like a generic issue not specfic to kexec.
I agree that this isn't kexec's fault as such, but in the absence of
kexec, the above issue does not exist, so one can't consider it in
isolation.
quoted
quoted
quoted
A kexec'd kernel should simply inherit that. So long as the DTB and/or
UEFI tables in memory are the same, it would be the same as a cold boot.
For kexec all memory ranges are same, for kdump we need use original reserved
range with crashkernel= as usable memory and all other orignal usable ranges
are not usable anymore.
Sure. This is what I believe we should expose with an additional
property under /chosen, while keeping everything else pristine.
The crash kernel can then limit itself to that region, while it would
have the information of the full memory map (which it could log and/or
use to drive other dumping).
In this way kernel should be aware it is a kdump booting, it is doable though
I feel it is better for kdump kernel in a black box with infomations it
can use just like the 1st kernel. Things here is where we choose to cook
the memory infomation in boot loader or in kernel itself.
Sorry, I can't follow what you are trying to say here. Could you
elaborate?
quoted
quoted
Is it possible to modify uefi memmap for kdump case?
Technically it would be possible, however I don't think it's necessary,
and I think it would be disadvantageous to do so.
Describing the range(s) the crash kernel can use in separate properties
under /chosen has a number of advantages.
Ok, I got the points. We have a is_kdump_kernel() by checking if there is
elfcorehdr_addr kernel cmdline. This is mainly for some drivers which
do not work well in kdump kernel some uncertain reasons. But ideally I
think kernel should handle things just like in 1st kernel and avoid to use
it.
I agree that we should not have kexec/kdump knowledge spread throughout
the kernel, and that the boot protocol should be uniform with a cold
boot as far as possible.
However, requiring userspace or the first kernel to modify
firmware-provided information has a number of risks and reduces the
amount of information available to the kdump kernel. To that end I am
opposed to modifying the memory nodes in the DTB, or to modifying the
EFI memory map.
Having a property in the DTB describing the range(s) of memory reserved
for use by the kdump kernel is vastly simpler, and avoids those risks:
* It requires a tiny amount of self-contained code in the kdump kernel
to parse the property and apply the constraints imposed (i.e. carve up
memblock).
This is easy to contain in a single function (or at least within a
single file), and need not affect drivers or other code.
* It is uniform regardless of whether the EFI memory map, DT memory
nodes, or some other mechanism is used to discover memory in the
systems.
This makes it easy to impose the restrictions consistently, and is
somewhat future-proof.
* Userspace or the first kernel to not need to parse and modify an
arbitrary amount of data (which might be in an extended format it
doesn't fully understand). There is less risk for this to go wrong.
It is far easier to add a property than it is to correctly modify the
EFI memory map, memory nodes, or some other data structure. There is
less risk, and it is somewhat future-proof.
* The original memory map information is preserved, even though unused.
This may be useful for debugging, and it may turn out that the kdump
kernel needs to know about certain portions of the original memory
map, even if we are not currently aware of why we would need this.
Thanks,
Mark.
On Wed, Jan 20, 2016 at 03:07:53PM +0900, AKASHI Takahiro wrote:
On 01/20/2016 11:49 AM, Dave Young wrote:
quoted
On 01/19/16 at 02:01pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 09:45:53PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 12:51pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 02:35pm, AKASHI Takahiro wrote:
quoted
On 01/19/2016 10:43 AM, Dave Young wrote:
quoted
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
quoted
I think it is X86 specific. Personally I think device tree property is
better.
Do you think so?
I'm not sure it is the best way. For X86 we run into problem with
memmap= design, one example is pci domain X (X>1) need the pci memory
ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem
to 2nd kernel we find that cmdline[] array is not big enough.
I'm not sure how PCI ranges relate to the memory map used for normal
memory (i.e. RAM), though I'm probably missing some caveat with the way
ACPI and UEFI describe PCI. Why does memmap= affect PCI memory?
If the kernel got the rest of its system topology from DT, the PCI
regions would be described there.
Yes, if kdump kernel use same DT as 1st kernel.
Other than for testing purposes, I don't see why you'd pass the kdump
kernel a DTB inconsistent with that the 1st kernel was passsed (other
than some proerties under /chosen).
We added /sys/firmware/fdt specifically to allow the kexec tools to get
the exact DTB the first kernel used. There's no reason for tools to have
to make something up.
Agreed, but kexec-tools has an option to pass in any dtb files. Who knows
how one will use it unless dropping the option and use /sys/firmware/fdt
unconditionally.
As a matter of fact, specifying proper command line parameters as well as
dtb is partly users' responsibility for kdump to work correctly.
(especially for BE kernel)
quoted
If we choose to implement kexec_file_load only in kernel, the interfaces
provided are kernel, initrd and cmdline. We can always use same dtb.
I would say that we can always use the same dtb even with kexec_load
from user's perspective. Right?
No.
This breaks using kexec for boot-loader purposes, and imposes a policy.
For better or worse kexec_file_load has always imposed a constrained
Linux-only policy, so that's a different story.
quoted
quoted
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
Firmware do not know kernel endianniess, kernel should respect firmware
maps and adapt to it, it sounds like a generic issue not specfic to kexec.
On arm64, a kernel image header has a bit field to specify the image's endianness.
Anyway, our current implementation replies on a user-supplied dtb to start BE kernel.
The firmware should _never_ care about the kernel's endianness. The
bootlaoder or first kernel shouldn't care about the next kernel's
endianness apart from in exceptional circumstances. The DTB for a LE
kernel should look identical to that passed to a BE kernel.
In my mind, the only valid reason to look at that bit is so that
bootloaders can provide a warning if the CPU does not implement that
endianness.
The issue I mention above should be solved by changes to the BE kernel.
quoted
quoted
quoted
Is it possible to modify uefi memmap for kdump case?
Technically it would be possible, however I don't think it's necessary,
and I think it would be disadvantageous to do so.
Describing the range(s) the crash kernel can use in separate properties
under /chosen has a number of advantages.
Ok, I got the points. We have a is_kdump_kernel() by checking if there is
elfcorehdr_addr kernel cmdline. This is mainly for some drivers which
do not work well in kdump kernel some uncertain reasons. But ideally I
think kernel should handle things just like in 1st kernel and avoid to use
it.
So I'm not still sure about what are advantages of a property under /chosen
over "memmap=" kernel parameter.
Both are simple and can have the same effect with minimizing changes to dtb.
(But if, in the latter case, we have to provide *all* the memory-related information
through "memmap=" parameters, it would be much complicated.)
The reason I prefer a property over command line additions include:
* It keeps the command line simple (as you mention the opposite is
"complicated").
* It is logically separate from options the user may pass to the kernel
in that the restricted region(s) of memory avaialble are effectively
properties of the system (in that the crashed OS is part of the system
state).
* The semantics of the command line parsing can change subtly over time
(for example, see 51e158c12aca3c9a, which terminates command line
parseing at "--"). Maknig sure that a command line option will
actually be parsed by the next kernel is not trivial.
Keeping this information isolated from the command line is more
robust.
* Addition of a property is a self-contained operation, that doesn't
require any knowledge about the command line.
Thanks,
Mark.
On Wed, Jan 20, 2016 at 02:38:56PM +0800, Dave Young wrote:
Maybe I did not say it clearly, I prefer kexec syscall/tool to modifiy dtb
or uefi-memmap so that we do not need any extra kernel cmdline.
I am strongly opposed to modifying the FW-provided memroy map
information, for the reasons I expressed in other replies.
What are your concerns with a property under /chosen?
For x86 we would like to drop the memmap= usage in kexec-tools but we can not
do that for a compatibility problem about calgary iommu. So that currently
kexec-tools supports both recreating E820 maps and passing memmap=.
We should think it carefully because it will be hard to remove once we support it.
I agree that we don't want a plethora of solutions that we have to
support forever.
IMO handling it in code is better than using an external interface.
I'm not sure what you mean by this. What is the "external interface",
and which code do you beleive it is better to handle this in?
Thanks,
Mark.
On Wed, Jan 20, 2016 at 02:25:07PM +0900, AKASHI Takahiro wrote:
On 01/19/2016 11:01 PM, Mark Rutland wrote:
quoted
For NUMA topology in !ACPI kernels, we might need to also retain and
parse memory nodes, but only for toplogy information. The kernel would
still only use memory as described by the EFI memory map.
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
BE kernel doesn't support UEFI yet and cannot access UEFI memmap table. So,
for LE -> BE, we don't use a dtb generated from /sys/firmware/fdt (or /proc/device-tree)
(as in the case of LE -> LE) and require users to provide a dtb file explicitly.
As I mentioned above, the problem exists when memory nodes also exist
(for describing NUMA topology). In that case the BE kernel would try to
use the information from the memory nodes.
For BE -> LE, BE kernel doesn't know wther UEFI memmap table is available or not
and so use the same (explicitly-provided) dtb (as LE -> LE in !UEFI)
See above. The problem I imagine is:
LE kernel - uses EFI mmap, takes NUMA information from DT memory nodes
v kexec
BE kernel - uses DT memory nodes
- clobbers EFI runtime regions as it sees them as available
v kexec
LE kernel - uses EFI mmap, takes NUMA information from DT memory nodes
- tries to call EFI runtime services, and explodes.
quoted
quoted
quoted
A kexec'd kernel should simply inherit that. So long as the DTB and/or
UEFI tables in memory are the same, it would be the same as a cold boot.
For kexec all memory ranges are same, for kdump we need use original reserved
range with crashkernel= as usable memory and all other orignal usable ranges
are not usable anymore.
Sure. This is what I believe we should expose with an additional
property under /chosen, while keeping everything else pristine.
The crash kernel can then limit itself to that region, while it would
have the information of the full memory map (which it could log and/or
use to drive other dumping).
FYI,
all the original usable memory regions used by the 1st kernel are also
described in an ELF core header specified by "elfcorehdr=" parameter to
the crash dump kernel.
That only describes what the first kernel parsed and thus believed, not
exactly what the firmware described.
Thanks,
Mark.
Ard, Ganapatrao, the below is something we need to consider for the
combination of the NUMA & kexec approaches. It only becomes a problem
if/when we preserve DT memory nodes in the presence of EFI, though it
would be nice to not box ourselves into a corner.
On Wed, Jan 20, 2016 at 12:02:58PM +0000, Mark Rutland wrote:
On Wed, Jan 20, 2016 at 02:25:07PM +0900, AKASHI Takahiro wrote:
quoted
On 01/19/2016 11:01 PM, Mark Rutland wrote:
quoted
For NUMA topology in !ACPI kernels, we might need to also retain and
parse memory nodes, but only for toplogy information. The kernel would
still only use memory as described by the EFI memory map.
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
BE kernel doesn't support UEFI yet and cannot access UEFI memmap table. So,
for LE -> BE, we don't use a dtb generated from /sys/firmware/fdt (or /proc/device-tree)
(as in the case of LE -> LE) and require users to provide a dtb file explicitly.
As I mentioned above, the problem exists when memory nodes also exist
(for describing NUMA topology). In that case the BE kernel would try to
use the information from the memory nodes.
quoted
For BE -> LE, BE kernel doesn't know wther UEFI memmap table is available or not
and so use the same (explicitly-provided) dtb (as LE -> LE in !UEFI)
See above. The problem I imagine is:
LE kernel - uses EFI mmap, takes NUMA information from DT memory nodes
v kexec
BE kernel - uses DT memory nodes
- clobbers EFI runtime regions as it sees them as available
v kexec
LE kernel - uses EFI mmap, takes NUMA information from DT memory nodes
- tries to call EFI runtime services, and explodes.
I'm not really sure what the best approach is here, but I thought that
it would be good to raise awareness of the edge-case.
Mark.
Hi Geoff,
On 15/01/16 19:18, Geoff Levand wrote:
Can I donate a commit message:
Kexec and hibernate need to copy pages of memory, but may not have all
of the kernel mapped, and are unable to call copy_page().
Convert copy_page() to a macro, so that it can be inlined in these
situations.
@@ -240,6 +241,24 @@ lr .req x30 // link register.endm/*+*copy_page-copysrctodestusingtempregisterst1-t8+*/+.macrocopy_pagedest:reqsrc:reqt1:reqt2:reqt3:reqt4:reqt5:reqt6:reqt7:reqt8:req+1:ldp\t1,\t2,[\src]
Using '1' as a label here means callers can't jump back over it using
the same label. The convention with USER() and alternatives is to use
unlikely values like '9999'.
On 20 January 2016 at 13:36, Mark Rutland [off-list ref] wrote:
Ard, Ganapatrao, the below is something we need to consider for the
combination of the NUMA & kexec approaches. It only becomes a problem
if/when we preserve DT memory nodes in the presence of EFI, though it
would be nice to not box ourselves into a corner.
On Wed, Jan 20, 2016 at 12:02:58PM +0000, Mark Rutland wrote:
quoted
On Wed, Jan 20, 2016 at 02:25:07PM +0900, AKASHI Takahiro wrote:
quoted
On 01/19/2016 11:01 PM, Mark Rutland wrote:
quoted
For NUMA topology in !ACPI kernels, we might need to also retain and
parse memory nodes, but only for toplogy information. The kernel would
still only use memory as described by the EFI memory map.
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
BE kernel doesn't support UEFI yet and cannot access UEFI memmap table. So,
for LE -> BE, we don't use a dtb generated from /sys/firmware/fdt (or /proc/device-tree)
(as in the case of LE -> LE) and require users to provide a dtb file explicitly.
As I mentioned above, the problem exists when memory nodes also exist
(for describing NUMA topology). In that case the BE kernel would try to
use the information from the memory nodes.
quoted
For BE -> LE, BE kernel doesn't know wther UEFI memmap table is available or not
and so use the same (explicitly-provided) dtb (as LE -> LE in !UEFI)
See above. The problem I imagine is:
LE kernel - uses EFI mmap, takes NUMA information from DT memory nodes
v kexec
BE kernel - uses DT memory nodes
- clobbers EFI runtime regions as it sees them as available
v kexec
LE kernel - uses EFI mmap, takes NUMA information from DT memory nodes
- tries to call EFI runtime services, and explodes.
I'm not really sure what the best approach is here, but I thought that
it would be good to raise awareness of the edge-case.
I think we should simply allow the BE kernel to deal with a UEFI
memory map. It only involves a bit of byte swapping (which I already
implemented at some point)
It would require some minor refactoring to make the UEFI init code
separate from all the other bits, but I don't see any major issues
here
On Wed, Jan 20, 2016 at 03:59:08PM +0100, Ard Biesheuvel wrote:
On 20 January 2016 at 13:36, Mark Rutland [off-list ref] wrote:
quoted
Ard, Ganapatrao, the below is something we need to consider for the
combination of the NUMA & kexec approaches. It only becomes a problem
if/when we preserve DT memory nodes in the presence of EFI, though it
would be nice to not box ourselves into a corner.
On Wed, Jan 20, 2016 at 12:02:58PM +0000, Mark Rutland wrote:
quoted
On Wed, Jan 20, 2016 at 02:25:07PM +0900, AKASHI Takahiro wrote:
quoted
On 01/19/2016 11:01 PM, Mark Rutland wrote:
quoted
For NUMA topology in !ACPI kernels, we might need to also retain and
parse memory nodes, but only for toplogy information. The kernel would
still only use memory as described by the EFI memory map.
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
BE kernel doesn't support UEFI yet and cannot access UEFI memmap table. So,
for LE -> BE, we don't use a dtb generated from /sys/firmware/fdt (or /proc/device-tree)
(as in the case of LE -> LE) and require users to provide a dtb file explicitly.
As I mentioned above, the problem exists when memory nodes also exist
(for describing NUMA topology). In that case the BE kernel would try to
use the information from the memory nodes.
quoted
For BE -> LE, BE kernel doesn't know wther UEFI memmap table is available or not
and so use the same (explicitly-provided) dtb (as LE -> LE in !UEFI)
See above. The problem I imagine is:
LE kernel - uses EFI mmap, takes NUMA information from DT memory nodes
v kexec
BE kernel - uses DT memory nodes
- clobbers EFI runtime regions as it sees them as available
v kexec
LE kernel - uses EFI mmap, takes NUMA information from DT memory nodes
- tries to call EFI runtime services, and explodes.
I'm not really sure what the best approach is here, but I thought that
it would be good to raise awareness of the edge-case.
I think we should simply allow the BE kernel to deal with a UEFI
memory map. It only involves a bit of byte swapping (which I already
implemented at some point)
It would require some minor refactoring to make the UEFI init code
separate from all the other bits, but I don't see any major issues
here
Ok. I had assumed that getting the BE kernel to deal with the UEFI
memory map would be a bit more involved.
I'm happy to be proven wrong. :)
Thanks,
Mark.
From: Dave Young <hidden> Date: 2016-01-21 02:54:22
On 01/20/16 at 11:28am, Mark Rutland wrote:
On Wed, Jan 20, 2016 at 10:49:46AM +0800, Dave Young wrote:
quoted
On 01/19/16 at 02:01pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 09:45:53PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 12:51pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 02:35pm, AKASHI Takahiro wrote:
quoted
On 01/19/2016 10:43 AM, Dave Young wrote:
quoted
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
quoted
I think it is X86 specific. Personally I think device tree property is
better.
Do you think so?
I'm not sure it is the best way. For X86 we run into problem with
memmap= design, one example is pci domain X (X>1) need the pci memory
ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem
to 2nd kernel we find that cmdline[] array is not big enough.
I'm not sure how PCI ranges relate to the memory map used for normal
memory (i.e. RAM), though I'm probably missing some caveat with the way
ACPI and UEFI describe PCI. Why does memmap= affect PCI memory?
If the kernel got the rest of its system topology from DT, the PCI
regions would be described there.
Yes, if kdump kernel use same DT as 1st kernel.
Other than for testing purposes, I don't see why you'd pass the kdump
kernel a DTB inconsistent with that the 1st kernel was passsed (other
than some proerties under /chosen).
We added /sys/firmware/fdt specifically to allow the kexec tools to get
the exact DTB the first kernel used. There's no reason for tools to have
to make something up.
Agreed, but kexec-tools has an option to pass in any dtb files. Who knows
how one will use it unless dropping the option and use /sys/firmware/fdt
unconditionally.
I think this is a tangential discussion. I think it's fine to say that
for kdump we do not expect this -- a user would be shooting themselves
in the foot if they did. Regardless, I was under the impression that
kdump was usually set up by distribution-provided init code.
or kdump, which typically is set up automatically by the OS,
Yes, usually os setup kdump but with some config file user can tune the kexec
arguments. Anyway I agree that one should do right but if we are sure exact
fdt in 1st kernel is needed we can drop kexec-tools --dtb option.
quoted
If we choose to implement kexec_file_load only in kernel, the interfaces
provided are kernel, initrd and cmdline. We can always use same dtb.
There are use-cases where being in complete control of the purgatory
code is necessary. For example, the next OS might not be Linux (and
might not accept a DTB, or have different requirements on the initial
register state).
Regardless of the need for something like kexec_file_load for kdump in
Secure Boot environments, there is also a need for kexec_load with the
user having complete control.
I'm not sure if there are such use cases in arm64 in real life.
But indeed it is a reason kexec_load can exist if there really are such requests.
quoted
quoted
quoted
quoted
quoted
Do you think for arm64 only usable memory is necessary to let kdump kernel
know? I'm curious about how arm64 kernel get all memory layout from boot loader,
via UEFI memmap?
When booted via EFI, we use the EFI memory map. The EFI stub handles
acquring the relevant information and passing that to the first kernel
in the DTB (see Documentation/arm/uefi.txt).
Ok, thanks for the pointer. So in dt we are just have uefi memmap infomation
instead of memory nodes details..
When booted via EFI, yes.
For NUMA topology in !ACPI kernels, we might need to also retain and
parse memory nodes, but only for toplogy information. The kernel would
still only use memory as described by the EFI memory map.
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
Firmware do not know kernel endianniess, kernel should respect firmware
maps and adapt to it, it sounds like a generic issue not specfic to kexec.
I agree that this isn't kexec's fault as such, but in the absence of
kexec, the above issue does not exist, so one can't consider it in
isolation.
quoted
quoted
quoted
quoted
A kexec'd kernel should simply inherit that. So long as the DTB and/or
UEFI tables in memory are the same, it would be the same as a cold boot.
For kexec all memory ranges are same, for kdump we need use original reserved
range with crashkernel= as usable memory and all other orignal usable ranges
are not usable anymore.
Sure. This is what I believe we should expose with an additional
property under /chosen, while keeping everything else pristine.
The crash kernel can then limit itself to that region, while it would
have the information of the full memory map (which it could log and/or
use to drive other dumping).
In this way kernel should be aware it is a kdump booting, it is doable though
I feel it is better for kdump kernel in a black box with infomations it
can use just like the 1st kernel. Things here is where we choose to cook
the memory infomation in boot loader or in kernel itself.
Sorry, I can't follow what you are trying to say here. Could you
elaborate?
Hmm, I menas if we prepare a kdump usable uefi memmap then we do not need introduce
the extra dtb property and kdump kernel just works like a normal boot.
I think we have understand each other upon latter part of this mail :)
One additianl issue with the simple way is if it can be used only in kdump kernel
Or it applys to both normal boot and kdump kernel boot so that it becomes a
general interface instead of only for kdump.
That means in 1st kernel we need override all system ram sections from uefi if
the usable chosen property is provided in 1st kernel.
quoted
quoted
quoted
Is it possible to modify uefi memmap for kdump case?
Technically it would be possible, however I don't think it's necessary,
and I think it would be disadvantageous to do so.
Describing the range(s) the crash kernel can use in separate properties
under /chosen has a number of advantages.
Ok, I got the points. We have a is_kdump_kernel() by checking if there is
elfcorehdr_addr kernel cmdline. This is mainly for some drivers which
do not work well in kdump kernel some uncertain reasons. But ideally I
think kernel should handle things just like in 1st kernel and avoid to use
it.
I agree that we should not have kexec/kdump knowledge spread throughout
the kernel, and that the boot protocol should be uniform with a cold
boot as far as possible.
However, requiring userspace or the first kernel to modify
firmware-provided information has a number of risks and reduces the
amount of information available to the kdump kernel. To that end I am
opposed to modifying the memory nodes in the DTB, or to modifying the
EFI memory map.
Having a property in the DTB describing the range(s) of memory reserved
for use by the kdump kernel is vastly simpler, and avoids those risks:
* It requires a tiny amount of self-contained code in the kdump kernel
to parse the property and apply the constraints imposed (i.e. carve up
memblock).
This is easy to contain in a single function (or at least within a
single file), and need not affect drivers or other code.
* It is uniform regardless of whether the EFI memory map, DT memory
nodes, or some other mechanism is used to discover memory in the
systems.
This makes it easy to impose the restrictions consistently, and is
somewhat future-proof.
Ok, considering arm64 specific complexity of the several combind cases
especially this one I would say choosing a simple solution may be the
best choice.
* Userspace or the first kernel to not need to parse and modify an
arbitrary amount of data (which might be in an extended format it
doesn't fully understand). There is less risk for this to go wrong.
It is far easier to add a property than it is to correctly modify the
EFI memory map, memory nodes, or some other data structure. There is
less risk, and it is somewhat future-proof.
* The original memory map information is preserved, even though unused.
This may be useful for debugging, and it may turn out that the kdump
kernel needs to know about certain portions of the original memory
map, even if we are not currently aware of why we would need this.
From: Dave Young <hidden> Date: 2016-01-21 02:57:53
Hi, Mark
On 01/20/16 at 11:54am, Mark Rutland wrote:
On Wed, Jan 20, 2016 at 02:38:56PM +0800, Dave Young wrote:
quoted
Maybe I did not say it clearly, I prefer kexec syscall/tool to modifiy dtb
or uefi-memmap so that we do not need any extra kernel cmdline.
I am strongly opposed to modifying the FW-provided memroy map
information, for the reasons I expressed in other replies.
What are your concerns with a property under /chosen?
quoted
For x86 we would like to drop the memmap= usage in kexec-tools but we can not
do that for a compatibility problem about calgary iommu. So that currently
kexec-tools supports both recreating E820 maps and passing memmap=.
We should think it carefully because it will be hard to remove once we support it.
I agree that we don't want a plethora of solutions that we have to
support forever.
quoted
IMO handling it in code is better than using an external interface.
I'm not sure what you mean by this. What is the "external interface",
and which code do you beleive it is better to handle this in?
I think we have covered all these in another reply. Let's continue
the discussion if needed in that thread.
Thanks
Dave
From: Dave Young <hidden> Date: 2016-01-21 03:03:22
I am strongly opposed to modifying the FW-provided memroy map
information, for the reasons I expressed in other replies.
What are your concerns with a property under /chosen?
If we choose a simpler way between memmap= and /chosen property then
I think a property in /chosen looks better to me.
Thanks
Dave
On 20 January 2016 at 13:36, Mark Rutland [off-list ref] wrote:
quoted
Ard, Ganapatrao, the below is something we need to consider for the
combination of the NUMA & kexec approaches. It only becomes a problem
if/when we preserve DT memory nodes in the presence of EFI, though it
would be nice to not box ourselves into a corner.
On Wed, Jan 20, 2016 at 12:02:58PM +0000, Mark Rutland wrote:
quoted
On Wed, Jan 20, 2016 at 02:25:07PM +0900, AKASHI Takahiro wrote:
quoted
On 01/19/2016 11:01 PM, Mark Rutland wrote:
quoted
For NUMA topology in !ACPI kernels, we might need to also retain and
parse memory nodes, but only for toplogy information. The kernel would
still only use memory as described by the EFI memory map.
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
BE kernel doesn't support UEFI yet and cannot access UEFI memmap table. So,
for LE -> BE, we don't use a dtb generated from /sys/firmware/fdt (or /proc/device-tree)
(as in the case of LE -> LE) and require users to provide a dtb file explicitly.
As I mentioned above, the problem exists when memory nodes also exist
(for describing NUMA topology). In that case the BE kernel would try to
use the information from the memory nodes.
quoted
For BE -> LE, BE kernel doesn't know wther UEFI memmap table is available or not
and so use the same (explicitly-provided) dtb (as LE -> LE in !UEFI)
See above. The problem I imagine is:
LE kernel - uses EFI mmap, takes NUMA information from DT memory nodes
v kexec
BE kernel - uses DT memory nodes
- clobbers EFI runtime regions as it sees them as available
v kexec
LE kernel - uses EFI mmap, takes NUMA information from DT memory nodes
- tries to call EFI runtime services, and explodes.
I'm not really sure what the best approach is here, but I thought that
it would be good to raise awareness of the edge-case.
I think we should simply allow the BE kernel to deal with a UEFI
memory map. It only involves a bit of byte swapping (which I already
implemented at some point)
Just from my curiosity,
will runtime services be also available on BE kernel with LE uefi?
-Takahiro AKASHI
It would require some minor refactoring to make the UEFI init code
separate from all the other bits, but I don't see any major issues
here
On Wed, Jan 20, 2016 at 03:07:53PM +0900, AKASHI Takahiro wrote:
quoted
On 01/20/2016 11:49 AM, Dave Young wrote:
quoted
On 01/19/16 at 02:01pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 09:45:53PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 12:51pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 02:35pm, AKASHI Takahiro wrote:
quoted
On 01/19/2016 10:43 AM, Dave Young wrote:
quoted
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
quoted
I think it is X86 specific. Personally I think device tree property is
better.
Do you think so?
I'm not sure it is the best way. For X86 we run into problem with
memmap= design, one example is pci domain X (X>1) need the pci memory
ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem
to 2nd kernel we find that cmdline[] array is not big enough.
I'm not sure how PCI ranges relate to the memory map used for normal
memory (i.e. RAM), though I'm probably missing some caveat with the way
ACPI and UEFI describe PCI. Why does memmap= affect PCI memory?
If the kernel got the rest of its system topology from DT, the PCI
regions would be described there.
Yes, if kdump kernel use same DT as 1st kernel.
Other than for testing purposes, I don't see why you'd pass the kdump
kernel a DTB inconsistent with that the 1st kernel was passsed (other
than some proerties under /chosen).
We added /sys/firmware/fdt specifically to allow the kexec tools to get
the exact DTB the first kernel used. There's no reason for tools to have
to make something up.
Agreed, but kexec-tools has an option to pass in any dtb files. Who knows
how one will use it unless dropping the option and use /sys/firmware/fdt
unconditionally.
As a matter of fact, specifying proper command line parameters as well as
dtb is partly users' responsibility for kdump to work correctly.
(especially for BE kernel)
quoted
If we choose to implement kexec_file_load only in kernel, the interfaces
provided are kernel, initrd and cmdline. We can always use same dtb.
I would say that we can always use the same dtb even with kexec_load
from user's perspective. Right?
No.
This breaks using kexec for boot-loader purposes, and imposes a policy.
What kind of policy?
I said "can", but if we want to use other setting/configuration, we can
still have a full control.
For better or worse kexec_file_load has always imposed a constrained
Linux-only policy, so that's a different story.
quoted
quoted
quoted
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
Firmware do not know kernel endianniess, kernel should respect firmware
maps and adapt to it, it sounds like a generic issue not specfic to kexec.
On arm64, a kernel image header has a bit field to specify the image's endianness.
Anyway, our current implementation replies on a user-supplied dtb to start BE kernel.
The firmware should _never_ care about the kernel's endianness. The
bootlaoder or first kernel shouldn't care about the next kernel's
endianness apart from in exceptional circumstances. The DTB for a LE
kernel should look identical to that passed to a BE kernel.
Please note that I didn't say anything different from your last two statements.
The current arm64 kexec implementation doesn't do anything specific to BE,
but as far as BE kernel doesn't support UEFI, users are responsible for
providing a proper dtb.
In my mind, the only valid reason to look at that bit is so that
bootloaders can provide a warning if the CPU does not implement that
endianness.
The issue I mention above should be solved by changes to the BE kernel.
quoted
quoted
quoted
quoted
Is it possible to modify uefi memmap for kdump case?
Technically it would be possible, however I don't think it's necessary,
and I think it would be disadvantageous to do so.
Describing the range(s) the crash kernel can use in separate properties
under /chosen has a number of advantages.
Ok, I got the points. We have a is_kdump_kernel() by checking if there is
elfcorehdr_addr kernel cmdline. This is mainly for some drivers which
do not work well in kdump kernel some uncertain reasons. But ideally I
think kernel should handle things just like in 1st kernel and avoid to use
it.
So I'm not still sure about what are advantages of a property under /chosen
over "memmap=" kernel parameter.
Both are simple and can have the same effect with minimizing changes to dtb.
(But if, in the latter case, we have to provide *all* the memory-related information
through "memmap=" parameters, it would be much complicated.)
The reason I prefer a property over command line additions include:
Take some examples:
(a) a property under /chosen
{
chosen = {
cmdline = "elfcorehdr=AA at BB maxcpus=1 ...";
}
usable-memory = <XX YY>;
memory {
...
}
}
(b) a kernel command line parameter
(I use the same name, "usable-memory", to show the similarity. may use another name though.)
{
chosen = {
cmdline = "elfcorehdr=AA at BB maxcpus=1 usable-memory=YY at XX ...";
}
memory {
...
}
}
* It keeps the command line simple (as you mention the opposite is
"complicated").
I think both are simple.
* It is logically separate from options the user may pass to the kernel
in that the restricted region(s) of memory avaialble are effectively
properties of the system (in that the crashed OS is part of the system
state).
"elfcorehdr=" parameter already breaks your point.
"elfcorehdr=" looks to be, what you say, a system property, and is actually
added by kexec-tools on all architectures, and "usable-memory", whether it is
a DT property or a kernel parameter, will also be added by kexec-tools.
(Users don't have to care.)
* The semantics of the command line parsing can change subtly over time
(for example, see 51e158c12aca3c9a, which terminates command line
parseing at "--"). Maknig sure that a command line option will
actually be parsed by the next kernel is not trivial.
Keeping this information isolated from the command line is more
robust.
Even so, who wants to use kdump without testing?
and this is not a kdump specific issue.
* Addition of a property is a self-contained operation, that doesn't
require any knowledge about the command line.
I don't get your point here.
For a kernel parameter, early_param() can encapsulate all the stuffs necessary.
Once the kernel recognizes a usable memory region, limiting available
memory should be done in the exact same way.
Thanks,
-Takahiro AKASHI
On Thu, Jan 21, 2016 at 03:53:42PM +0900, AKASHI Takahiro wrote:
On 01/20/2016 08:49 PM, Mark Rutland wrote:
quoted
On Wed, Jan 20, 2016 at 03:07:53PM +0900, AKASHI Takahiro wrote:
quoted
On 01/20/2016 11:49 AM, Dave Young wrote:
quoted
On 01/19/16 at 02:01pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 09:45:53PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 12:51pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 02:35pm, AKASHI Takahiro wrote:
quoted
On 01/19/2016 10:43 AM, Dave Young wrote:
quoted
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
quoted
I think it is X86 specific. Personally I think device tree property is
better.
Do you think so?
I'm not sure it is the best way. For X86 we run into problem with
memmap= design, one example is pci domain X (X>1) need the pci memory
ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem
to 2nd kernel we find that cmdline[] array is not big enough.
I'm not sure how PCI ranges relate to the memory map used for normal
memory (i.e. RAM), though I'm probably missing some caveat with the way
ACPI and UEFI describe PCI. Why does memmap= affect PCI memory?
If the kernel got the rest of its system topology from DT, the PCI
regions would be described there.
Yes, if kdump kernel use same DT as 1st kernel.
Other than for testing purposes, I don't see why you'd pass the kdump
kernel a DTB inconsistent with that the 1st kernel was passsed (other
than some proerties under /chosen).
We added /sys/firmware/fdt specifically to allow the kexec tools to get
the exact DTB the first kernel used. There's no reason for tools to have
to make something up.
Agreed, but kexec-tools has an option to pass in any dtb files. Who knows
how one will use it unless dropping the option and use /sys/firmware/fdt
unconditionally.
As a matter of fact, specifying proper command line parameters as well as
dtb is partly users' responsibility for kdump to work correctly.
(especially for BE kernel)
quoted
If we choose to implement kexec_file_load only in kernel, the interfaces
provided are kernel, initrd and cmdline. We can always use same dtb.
I would say that we can always use the same dtb even with kexec_load
from user's perspective. Right?
No.
This breaks using kexec for boot-loader purposes, and imposes a policy.
What kind of policy?
I said "can", but if we want to use other setting/configuration, we can
still have a full control.
Apologies, I misunderstood.
In most cases, using the existing DTB (with minor modifications to
/chosen for bootargs and such) is fine. If the user just wants to boot
another Linux kernel, that's generally what they should do.
I think we're agreed on that.
However, there are cases when the user may want to use a different DTB,
or use a different purgatory. So we cannot mandate that the existing DTB
is reused, nor that an in-kernel purgatory must be used, as that imposes
a policy.
quoted
For better or worse kexec_file_load has always imposed a constrained
Linux-only policy, so that's a different story.
quoted
quoted
quoted
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
Firmware do not know kernel endianniess, kernel should respect firmware
maps and adapt to it, it sounds like a generic issue not specfic to kexec.
On arm64, a kernel image header has a bit field to specify the image's endianness.
Anyway, our current implementation replies on a user-supplied dtb to start BE kernel.
The firmware should _never_ care about the kernel's endianness. The
bootlaoder or first kernel shouldn't care about the next kernel's
endianness apart from in exceptional circumstances. The DTB for a LE
kernel should look identical to that passed to a BE kernel.
Please note that I didn't say anything different from your last two statements.
The current arm64 kexec implementation doesn't do anything specific to BE,
but as far as BE kernel doesn't support UEFI, users are responsible for
providing a proper dtb.
I'm just confused as to what you mean by a "proper dtb" in that case.
If you just mean one with memory nodes hacked in, then that would
currently be a way to make that work, yes.
It seems like the better option is to fix the BE kernel to support a
UEFI memory map, as that solves other issues.
quoted
In my mind, the only valid reason to look at that bit is so that
bootloaders can provide a warning if the CPU does not implement that
endianness.
The issue I mention above should be solved by changes to the BE kernel.
quoted
quoted
quoted
quoted
Is it possible to modify uefi memmap for kdump case?
Technically it would be possible, however I don't think it's necessary,
and I think it would be disadvantageous to do so.
Describing the range(s) the crash kernel can use in separate properties
under /chosen has a number of advantages.
Ok, I got the points. We have a is_kdump_kernel() by checking if there is
elfcorehdr_addr kernel cmdline. This is mainly for some drivers which
do not work well in kdump kernel some uncertain reasons. But ideally I
think kernel should handle things just like in 1st kernel and avoid to use
it.
So I'm not still sure about what are advantages of a property under /chosen
over "memmap=" kernel parameter.
Both are simple and can have the same effect with minimizing changes to dtb.
(But if, in the latter case, we have to provide *all* the memory-related information
through "memmap=" parameters, it would be much complicated.)
The reason I prefer a property over command line additions include:
Take some examples:
(a) a property under /chosen
{
chosen = {
cmdline = "elfcorehdr=AA at BB maxcpus=1 ...";
}
usable-memory = <XX YY>;
memory {
...
}
}
(b) a kernel command line parameter
(I use the same name, "usable-memory", to show the similarity. may use another name though.)
{
chosen = {
cmdline = "elfcorehdr=AA at BB maxcpus=1 usable-memory=YY at XX ...";
}
memory {
...
}
}
quoted
* It keeps the command line simple (as you mention the opposite is
"complicated").
I think both are simple.
quoted
* It is logically separate from options the user may pass to the kernel
in that the restricted region(s) of memory avaialble are effectively
properties of the system (in that the crashed OS is part of the system
state).
"elfcorehdr=" parameter already breaks your point.
"elfcorehdr=" looks to be, what you say, a system property, and is actually
added by kexec-tools on all architectures, and "usable-memory", whether it is
a DT property or a kernel parameter, will also be added by kexec-tools.
(Users don't have to care.)
Just because architectures do one thing today does not mean that we have
to follow it.
I don't think that breaks my point so much as shows that a different
approach is taken by others today.
There's also no reason this cannot be a property under /chosen.
quoted
* The semantics of the command line parsing can change subtly over time
(for example, see 51e158c12aca3c9a, which terminates command line
parseing at "--"). Maknig sure that a command line option will
actually be parsed by the next kernel is not trivial.
Keeping this information isolated from the command line is more
robust.
Even so, who wants to use kdump without testing?
and this is not a kdump specific issue.
quoted
* Addition of a property is a self-contained operation, that doesn't
require any knowledge about the command line.
I don't get your point here.
For a kernel parameter, early_param() can encapsulate all the stuffs necessary.
Once the kernel recognizes a usable memory region, limiting available
memory should be done in the exact same way.
I mean when modifying the command line.
To place "elfcorehdr=" or "memmap="/"usable-memory=" into the command
line, one needs to know where it is valid to place it. Appending doesn't
always work, as per the example above with 51e158c12aca3c9a.
For both of these my point was that generally there is some fragility in
this area. While it's easy to say that breaking this would be someone
else's fault, we can easily avoid the possibility of that happening, and
avoid a set of problems trying to maintain backwards compatibility if
there were a sensible change that happened to break things.
Thanks,
Mark.
On Wed, Jan 20, 2016 at 10:56:21AM +0800, Dave Young wrote:
On 01/19/16 at 04:15pm, Geoff Levand wrote:
quoted
On Tue, 2016-01-19 at 20:32 +0800, Dave Young wrote:
quoted
Geoff, another question about kexec-tools part is, can the kexec
-tools code
been written in kernel? We have the infrastructure for kexec_file_load.
I see no technical reason why the arm64 kernel cannot support
kexec_file_load.
Cool, care to port it to kernel so that we have kexec_file_load only in arm64
we do not need to support both kexec_load and kexec_file_load?
I have reasons for wanting kexec_load, even if we have kexec_file_load.
For example, being able to test modified DTBs during development, and
being able to kexec to non-Linux OSs.
I don't think we should drop kexec_load, as kexec_file_load is designed
such that it cannot be used for these purposes, while kexec_load is more
general.
I appreciate that we will need kexec_file_load for Secure Boot, and it
would be perfectly fine for your kdump userspace to require and always
use kexec_file_load.
Thanks,
Mark.
On Thu, Jan 21, 2016 at 02:43:15PM +0900, AKASHI Takahiro wrote:
On 01/20/2016 11:59 PM, Ard Biesheuvel wrote:
quoted
On 20 January 2016 at 13:36, Mark Rutland [off-list ref] wrote:
quoted
Ard, Ganapatrao, the below is something we need to consider for the
combination of the NUMA & kexec approaches. It only becomes a problem
if/when we preserve DT memory nodes in the presence of EFI, though it
would be nice to not box ourselves into a corner.
On Wed, Jan 20, 2016 at 12:02:58PM +0000, Mark Rutland wrote:
quoted
On Wed, Jan 20, 2016 at 02:25:07PM +0900, AKASHI Takahiro wrote:
quoted
On 01/19/2016 11:01 PM, Mark Rutland wrote:
quoted
For NUMA topology in !ACPI kernels, we might need to also retain and
parse memory nodes, but only for toplogy information. The kernel would
still only use memory as described by the EFI memory map.
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
BE kernel doesn't support UEFI yet and cannot access UEFI memmap table. So,
for LE -> BE, we don't use a dtb generated from /sys/firmware/fdt (or /proc/device-tree)
(as in the case of LE -> LE) and require users to provide a dtb file explicitly.
As I mentioned above, the problem exists when memory nodes also exist
(for describing NUMA topology). In that case the BE kernel would try to
use the information from the memory nodes.
quoted
For BE -> LE, BE kernel doesn't know wther UEFI memmap table is available or not
and so use the same (explicitly-provided) dtb (as LE -> LE in !UEFI)
See above. The problem I imagine is:
LE kernel - uses EFI mmap, takes NUMA information from DT memory nodes
v kexec
BE kernel - uses DT memory nodes
- clobbers EFI runtime regions as it sees them as available
v kexec
LE kernel - uses EFI mmap, takes NUMA information from DT memory nodes
- tries to call EFI runtime services, and explodes.
I'm not really sure what the best approach is here, but I thought that
it would be good to raise awareness of the edge-case.
I think we should simply allow the BE kernel to deal with a UEFI
memory map. It only involves a bit of byte swapping (which I already
implemented at some point)
Just from my curiosity,
will runtime services be also available on BE kernel with LE uefi?
It may be possible to implement that (I recall that Ard had a go), but
that's far more complicated than simply supporting the EFI memory map,
as you need separate (endian-swapped) page tables and other data
structures, lose the ability to handle exceptions, etc.
All that's suggested above is supporting the memory map.
Thanks,
Mark.
From: AKASHI Takahiro <redacted>
On crash dump kernel, all the information about primary kernel's core
image is available in elf core header specified by "elfcorehdr=" boot
parameter. reserve_elfcorehdr() will set aside the region to avoid any
corruption by crash dump kernel.
Crash dump kernel will access the system memory of primary kernel via
copy_oldmem_page(), which reads one page by ioremap'ing it since it does
not reside in linear mapping on crash dump kernel.
Please note that we should add "mem=X[MG]" boot parameter to limit the
memory size and avoid the following assertion at ioremap():
if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
return NULL;
when accessing any pages beyond the usable memories of crash dump kernel.
We also need our own elfcorehdr_read() here since the weak definition of
elfcorehdr_read() utilizes copy_oldmem_page() and will hit the assertion
above on arm64.
How does this work for a different-endian crash kernel?
It looks like fs/proc/vmcore.c:parse_crash_elf64_headers() does some
validation on the elf-headers that doesn't look like it will work if
elfcorehdr:endian != kernel:endian.
Is it worth preventing this corner case by getting kexec-tools to
prevent linux with a different endianness being loaded as a kdump kernel?
Thanks,
James
From: AKASHI Takahiro <redacted>
On crash dump kernel, all the information about primary kernel's core
image is available in elf core header specified by "elfcorehdr=" boot
parameter. reserve_elfcorehdr() will set aside the region to avoid any
corruption by crash dump kernel.
Crash dump kernel will access the system memory of primary kernel via
copy_oldmem_page(), which reads one page by ioremap'ing it since it does
not reside in linear mapping on crash dump kernel.
Please note that we should add "mem=X[MG]" boot parameter to limit the
memory size and avoid the following assertion at ioremap():
if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
return NULL;
when accessing any pages beyond the usable memories of crash dump kernel.
We also need our own elfcorehdr_read() here since the weak definition of
elfcorehdr_read() utilizes copy_oldmem_page() and will hit the assertion
above on arm64.
How does this work for a different-endian crash kernel?
It looks like fs/proc/vmcore.c:parse_crash_elf64_headers() does some
validation on the elf-headers that doesn't look like it will work if
elfcorehdr:endian != kernel:endian.
Good point!
Is it worth preventing this corner case by getting kexec-tools to
prevent linux with a different endianness being loaded as a kdump kernel?
It may be, but I think that people should always check whether or not kdump
will work in their environment before puting the system in practical use.
(I know the check costs almost nothing though.)
Thanks,
-Takahiro AKASHI
On Thu, Jan 21, 2016 at 03:53:42PM +0900, AKASHI Takahiro wrote:
quoted
On 01/20/2016 08:49 PM, Mark Rutland wrote:
quoted
On Wed, Jan 20, 2016 at 03:07:53PM +0900, AKASHI Takahiro wrote:
quoted
On 01/20/2016 11:49 AM, Dave Young wrote:
quoted
On 01/19/16 at 02:01pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 09:45:53PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 12:51pm, Mark Rutland wrote:
quoted
On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote:
quoted
On 01/19/16 at 02:35pm, AKASHI Takahiro wrote:
quoted
On 01/19/2016 10:43 AM, Dave Young wrote:
quoted
X86 takes another way in latest kexec-tools and kexec_file_load, that is
recreating E820 table and pass it to kexec/kdump kernel, if the entries
are over E820 limitation then turn to use setup_data list for remain
entries.
Thanks. I will visit x86 code again.
quoted
I think it is X86 specific. Personally I think device tree property is
better.
Do you think so?
I'm not sure it is the best way. For X86 we run into problem with
memmap= design, one example is pci domain X (X>1) need the pci memory
ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem
to 2nd kernel we find that cmdline[] array is not big enough.
I'm not sure how PCI ranges relate to the memory map used for normal
memory (i.e. RAM), though I'm probably missing some caveat with the way
ACPI and UEFI describe PCI. Why does memmap= affect PCI memory?
If the kernel got the rest of its system topology from DT, the PCI
regions would be described there.
Yes, if kdump kernel use same DT as 1st kernel.
Other than for testing purposes, I don't see why you'd pass the kdump
kernel a DTB inconsistent with that the 1st kernel was passsed (other
than some proerties under /chosen).
We added /sys/firmware/fdt specifically to allow the kexec tools to get
the exact DTB the first kernel used. There's no reason for tools to have
to make something up.
Agreed, but kexec-tools has an option to pass in any dtb files. Who knows
how one will use it unless dropping the option and use /sys/firmware/fdt
unconditionally.
As a matter of fact, specifying proper command line parameters as well as
dtb is partly users' responsibility for kdump to work correctly.
(especially for BE kernel)
quoted
If we choose to implement kexec_file_load only in kernel, the interfaces
provided are kernel, initrd and cmdline. We can always use same dtb.
I would say that we can always use the same dtb even with kexec_load
from user's perspective. Right?
No.
This breaks using kexec for boot-loader purposes, and imposes a policy.
What kind of policy?
I said "can", but if we want to use other setting/configuration, we can
still have a full control.
Apologies, I misunderstood.
In most cases, using the existing DTB (with minor modifications to
/chosen for bootargs and such) is fine. If the user just wants to boot
another Linux kernel, that's generally what they should do.
I think we're agreed on that.
Yes.
However, there are cases when the user may want to use a different DTB,
or use a different purgatory. So we cannot mandate that the existing DTB
is reused, nor that an in-kernel purgatory must be used, as that imposes
a policy.
Agree!
quoted
quoted
For better or worse kexec_file_load has always imposed a constrained
Linux-only policy, so that's a different story.
quoted
quoted
quoted
There's a horrible edge case I've spotted if performing a chain of
cross-endian kexecs: LE -> BE -> LE, as the BE kernel would have to
respect the EFI memory map so as to avoid corrupting it for the
subsequent LE kernel. Other than this I believe everything should just
work.
Firmware do not know kernel endianniess, kernel should respect firmware
maps and adapt to it, it sounds like a generic issue not specfic to kexec.
On arm64, a kernel image header has a bit field to specify the image's endianness.
Anyway, our current implementation replies on a user-supplied dtb to start BE kernel.
The firmware should _never_ care about the kernel's endianness. The
bootlaoder or first kernel shouldn't care about the next kernel's
endianness apart from in exceptional circumstances. The DTB for a LE
kernel should look identical to that passed to a BE kernel.
Please note that I didn't say anything different from your last two statements.
The current arm64 kexec implementation doesn't do anything specific to BE,
but as far as BE kernel doesn't support UEFI, users are responsible for
providing a proper dtb.
I'm just confused as to what you mean by a "proper dtb" in that case.
If you just mean one with memory nodes hacked in, then that would
currently be a way to make that work, yes.
One of useful cases that I have in my mind is kdump.
We may want to use a small sub-set of dtb, especially devices, to
make the reboot more reliable. Device drivers are likely to be vulnerable
at crash.
It seems like the better option is to fix the BE kernel to support a
UEFI memory map, as that solves other issues.
Why did Ard throw away his patch?
quoted
quoted
In my mind, the only valid reason to look at that bit is so that
bootloaders can provide a warning if the CPU does not implement that
endianness.
The issue I mention above should be solved by changes to the BE kernel.
quoted
quoted
quoted
quoted
Is it possible to modify uefi memmap for kdump case?
Technically it would be possible, however I don't think it's necessary,
and I think it would be disadvantageous to do so.
Describing the range(s) the crash kernel can use in separate properties
under /chosen has a number of advantages.
Ok, I got the points. We have a is_kdump_kernel() by checking if there is
elfcorehdr_addr kernel cmdline. This is mainly for some drivers which
do not work well in kdump kernel some uncertain reasons. But ideally I
think kernel should handle things just like in 1st kernel and avoid to use
it.
So I'm not still sure about what are advantages of a property under /chosen
over "memmap=" kernel parameter.
Both are simple and can have the same effect with minimizing changes to dtb.
(But if, in the latter case, we have to provide *all* the memory-related information
through "memmap=" parameters, it would be much complicated.)
The reason I prefer a property over command line additions include:
Take some examples:
(a) a property under /chosen
{
chosen = {
cmdline = "elfcorehdr=AA at BB maxcpus=1 ...";
}
usable-memory = <XX YY>;
memory {
...
}
}
(b) a kernel command line parameter
(I use the same name, "usable-memory", to show the similarity. may use another name though.)
{
chosen = {
cmdline = "elfcorehdr=AA at BB maxcpus=1 usable-memory=YY at XX ...";
}
memory {
...
}
}
quoted
* It keeps the command line simple (as you mention the opposite is
"complicated").
I think both are simple.
quoted
* It is logically separate from options the user may pass to the kernel
in that the restricted region(s) of memory avaialble are effectively
properties of the system (in that the crashed OS is part of the system
state).
"elfcorehdr=" parameter already breaks your point.
"elfcorehdr=" looks to be, what you say, a system property, and is actually
added by kexec-tools on all architectures, and "usable-memory", whether it is
a DT property or a kernel parameter, will also be added by kexec-tools.
(Users don't have to care.)
Just because architectures do one thing today does not mean that we have
to follow it.
I don't think that breaks my point so much as shows that a different
approach is taken by others today.
There's also no reason this cannot be a property under /chosen.
No, but no strong reason to be so IMO.
quoted
quoted
* The semantics of the command line parsing can change subtly over time
(for example, see 51e158c12aca3c9a, which terminates command line
parseing at "--"). Maknig sure that a command line option will
actually be parsed by the next kernel is not trivial.
Keeping this information isolated from the command line is more
robust.
Even so, who wants to use kdump without testing?
and this is not a kdump specific issue.
quoted
* Addition of a property is a self-contained operation, that doesn't
require any knowledge about the command line.
I don't get your point here.
For a kernel parameter, early_param() can encapsulate all the stuffs necessary.
Once the kernel recognizes a usable memory region, limiting available
memory should be done in the exact same way.
I mean when modifying the command line.
OK, I understand what you mean.
To place "elfcorehdr=" or "memmap="/"usable-memory=" into the command
line, one needs to know where it is valid to place it. Appending doesn't
always work, as per the example above with 51e158c12aca3c9a.
So, are you now suggesting that we put both "elfcorehdr=" and
"usable-memory=" under /chosen in dtb? That's fair enough.
(as far as nobody cares about incompatibility with other archs.)
-Takahiro AKASHI
For both of these my point was that generally there is some fragility in
this area. While it's easy to say that breaking this would be someone
else's fault, we can easily avoid the possibility of that happening, and
avoid a set of problems trying to maintain backwards compatibility if
there were a sensible change that happened to break things.
Thanks,
Mark.
On Fri, Jan 22, 2016 at 03:23:14PM +0900, AKASHI Takahiro wrote:
On 01/21/2016 09:02 PM, Mark Rutland wrote:
quoted
On Thu, Jan 21, 2016 at 03:53:42PM +0900, AKASHI Takahiro wrote:
quoted
On 01/20/2016 08:49 PM, Mark Rutland wrote:
quoted
On Wed, Jan 20, 2016 at 03:07:53PM +0900, AKASHI Takahiro wrote:
quoted
On 01/20/2016 11:49 AM, Dave Young wrote:
quoted
Firmware do not know kernel endianniess, kernel should respect firmware
maps and adapt to it, it sounds like a generic issue not specfic to kexec.
On arm64, a kernel image header has a bit field to specify the image's endianness.
Anyway, our current implementation replies on a user-supplied dtb to start BE kernel.
The firmware should _never_ care about the kernel's endianness. The
bootlaoder or first kernel shouldn't care about the next kernel's
endianness apart from in exceptional circumstances. The DTB for a LE
kernel should look identical to that passed to a BE kernel.
Please note that I didn't say anything different from your last two statements.
The current arm64 kexec implementation doesn't do anything specific to BE,
but as far as BE kernel doesn't support UEFI, users are responsible for
providing a proper dtb.
I'm just confused as to what you mean by a "proper dtb" in that case.
If you just mean one with memory nodes hacked in, then that would
currently be a way to make that work, yes.
One of useful cases that I have in my mind is kdump.
We may want to use a small sub-set of dtb, especially devices, to
make the reboot more reliable. Device drivers are likely to be vulnerable
at crash.
I don't think that we can reliably have userspace carve out devices from
the DTB or from ACPI tables in order to achieve that. That's going to
end up complex and/or incomplete. We also can't do this in the
kexec_load_file / Secure Boot case.
That's not to say we cannot try, as it's possible when using kexec_load.
However, it's only going to be possible on a subset of systems, and it
would probably make sense to reserve this approach to those cases we
cannot work around by other means (e.g. whitelisting "safe" devices in
the kdump kernel, forcing explicit resets, etc).
quoted
It seems like the better option is to fix the BE kernel to support a
UEFI memory map, as that solves other issues.
Why did Ard throw away his patch?
In the absence of kexec it wasn't necessary, it only supported a subset
of the runtime services (and no other features like DMI IIRC), and it
looked like it would be painful to debug (if something went wrong while
a CPU was in LE mode, we couldn't even panic()).
Given BE kernels on UEFI were never supported until that point, there
wasn't a compelling reason to support that case.
Even if we support the UEFI memory map, I don't think it's worth the
effort to support runtime services, ACPI, and related code that's only
ever been tested on LE. So realistically this would only work on systems
using UEFI && DT rather than UEFI && ACPI.
So, are you now suggesting that we put both "elfcorehdr=" and
"usable-memory=" under /chosen in dtb?
Yes.
That's fair enough. (as far as nobody cares about incompatibility
with other archs.)
From: Dave Young <hidden> Date: 2016-01-25 03:19:17
Hi, AKASHI
quoted
To place "elfcorehdr=" or "memmap="/"usable-memory=" into the command
line, one needs to know where it is valid to place it. Appending doesn't
always work, as per the example above with 51e158c12aca3c9a.
So, are you now suggesting that we put both "elfcorehdr=" and
"usable-memory=" under /chosen in dtb? That's fair enough.
(as far as nobody cares about incompatibility with other archs.)
You may need move is_kdump_kernel as a weak function so that in arm64 you
can still use it in kdump kernel.
Thanks
Dave