Re: [PATCH Makedumpfile 00/10] arm64 cleanup and kaslr support
Hi Atsushi, There would be a conflict because of following patch while applying these patches. Other than that I also see a an issue with --config option. So I will fix that as well and repost the series soon. 0068010b9b83 [PATCH v2 2/2] Clean up unused KERNEL_IMAGE_SIZE ~Pratyush On Tue, Nov 1, 2016 at 2:41 PM, Atsushi Kumagai wrote: > Hello Pratyush, > >>These patches were lying in my tree for quite some time now. VMCOREINFO >>numbers/symbols used in these patches have been made part of kdump kernel >>patches for last few versions including v26. So, there seems no contention >>on embedding VA_BITS, kimage_voffset and PHYS_OFFSET into vmcore. >> >>These patches cleans up a lot arm64 code and also immunize it with many >>kernel changes. Additionally,it adds 4 level 4K page support and support for >>KASLR enabled kernel. >> >>Azriel Samson (1): >> arm64: Add support for 4level 4K page translations table >> >>Pratyush Anand (9): >> arm64: cleanup code, comment, blank space, blank lines etc >> read_vmcoreinfo_long: Allow to read hex values as well >> Introduce read_vmcoreinfo_ulong() >> arm64: use already available PAGESIZE() and PAGESHIFT() macros >> arm64: fix page_offset definition >> arm64: fix re-filtering >> arm64: use value of VA_BITS and PHYS_OFFSET embedded into vmcore >> arm64: immunize identity mapped address finding w.r.t. kernel changes >> arm64: fix memory layout as per changes in v4.6 kernel >> >> arch/arm64.c | 245 >> ++--- >> makedumpfile.c | 46 +++ >> makedumpfile.h | 28 +-- >> 3 files changed, 162 insertions(+), 157 deletions(-) > > Thanks always for your work for arm64, I've reviewed this patch set. > I'll merge them into v1.6.1. > > Regards, > Atsushi Kumagai ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v1] Add in kexec -S for status, and add new Xen hypercall to support this.
On Tuesday 15 November 2016 03:42 AM, Konrad Rzeszutek Wilk wrote: Heya! I am cross-posting on two mailing lists: xen-de...@lists.xenproject.org kexec@lists.infradead.org as it may be easier to review and provide input then me going back and forth. Hu..its confusing infact. Patch 1/2 does not belong to kexec-tools repository. patch 2/2 is independent in itself, so send 2/2 individually to kexec list and once it is getting acked, you can send only 1/2 to xen-devel list. Anyhow the patches are to help with the various distro's poking in /sys/../kexec to figure out whether an kexec image is loaded. This can be done using the -S parameter now with the patch #2. Also I add an hypercall to Xen so that if kexec is running under Xen the same information can be retrieved (see patch #1). ~Pratyush ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v1 2/2] kexec: Support -S paramter to return whether the kexec payload is loaded.
On Tuesday 15 November 2016 03:42 AM, Konrad Rzeszutek Wilk wrote: Instead of the scripts having to poke at various fields we can provide that functionality via the -S parameter. Returns 0 if the payload is loaded. Can be used in combination with -l or -p to get the state of the proper kexec image. Signed-off-by: Konrad Rzeszutek Wilk --- v0: First version (internal product). v1: Posted on kexec mailing list. Changed -s to -S CC: kexec@lists.infradead.org CC: xen-de...@lists.xenproject.org CC: Daniel Kiper --- kexec/kexec-xen.c | 20 ++ kexec/kexec.8 | 5 + kexec/kexec.c | 61 ++- kexec/kexec.h | 5 - 4 files changed, 85 insertions(+), 6 deletions(-) diff --git a/kexec/kexec-xen.c b/kexec/kexec-xen.c index 24a4191..5a1e9d2 100644 --- a/kexec/kexec-xen.c +++ b/kexec/kexec-xen.c @@ -105,6 +105,26 @@ int xen_kexec_unload(uint64_t kexec_flags) return ret; } +int xen_kexec_status(uint64_t kexec_flags) +{ + xc_interface *xch; + uint8_t type; + int ret; + + xch = xc_interface_open(NULL, NULL, 0); + if (!xch) + return -1; + + type = (kexec_flags & KEXEC_ON_CRASH) ? KEXEC_TYPE_CRASH + : KEXEC_TYPE_DEFAULT; + + ret = xc_kexec_status(xch, type); + + xc_interface_close(xch); + + return ret; +} + void xen_kexec_exec(void) { xc_interface *xch; diff --git a/kexec/kexec.8 b/kexec/kexec.8 index 4d0c1d1..02f4ccf 100644 --- a/kexec/kexec.8 +++ b/kexec/kexec.8 @@ -107,6 +107,11 @@ command: .B \-d\ (\-\-debug) Enable debugging messages. .TP +.B \-D\ (\-\-status) +Return 0 if the type (by default crash) is loaded. Can be used in conjuction +with -l or -p to toggle the type. Note it will +.BR not\ load\ the\ kernel. Better to specify that it will supersede all other options and will neither load nor unload the kernel. +.TP .B \-e\ (\-\-exec) Run the currently loaded kernel. Note that it will reboot into the loaded kernel without calling shutdown(8). .TP diff --git a/kexec/kexec.c b/kexec/kexec.c index 500e5a9..bc72688 100644 --- a/kexec/kexec.c +++ b/kexec/kexec.c @@ -855,6 +855,32 @@ static int k_unload (unsigned long kexec_flags) return result; } +static int kexec_loaded(void); +static int __kexec_loaded(const char *f); + Why not to define k_status below kexec_loaded() so that you do not need above prototypes. +static int k_status(unsigned long kexec_flags) +{ + int result; + long native_arch; + + /* set the arch */ + native_arch = physical_arch(); + if (native_arch < 0) { + return -1; + } + kexec_flags |= native_arch; + + if (xen_present()) + result = xen_kexec_status(kexec_flags); + else { + if (kexec_flags & KEXEC_ON_CRASH) + result = __kexec_loaded("/sys/kernel/kexec_crash_loaded"); + else + result = kexec_loaded(); + } + return result; +} + /* * Start a reboot. */ @@ -890,8 +916,6 @@ static int my_exec(void) return -1; } -static int kexec_loaded(void); - static int load_jump_back_helper_image(unsigned long kexec_flags, void *entry) { int result; @@ -970,6 +994,7 @@ void usage(void) " to original kernel.\n" " -s, --kexec-file-syscall Use file based syscall for kexec operation\n" " -d, --debug Enable debugging to help spot a failure.\n" + " -S, --status Return 0 if the type (by default crash) is loaded.\n" "\n" "Supported kernel file types and options: \n"); for (i = 0; i < file_types; i++) { @@ -981,7 +1006,7 @@ void usage(void) printf("\n"); } -static int kexec_loaded(void) +static int __kexec_loaded(const char *file) { long ret = -1; FILE *fp; @@ -992,7 +1017,7 @@ static int kexec_loaded(void) if (xen_present()) return 1; - fp = fopen("/sys/kernel/kexec_loaded", "r"); + fp = fopen(file, "r"); if (fp == NULL) return -1; @@ -1015,6 +1040,12 @@ static int kexec_loaded(void) return (int)ret; } +static int kexec_loaded(void) +{ + return __kexec_loaded("/sys/kernel/kexec_loaded"); +} Since kexec_loaded() has been called at only one place, better to remove above function and use __kexec_loaded() directly. And then you might not need to rename kexec_loaded() to __kexec_loaded() as well. + + /* * Remove parameter from a kernel command line. Helper function by get_command_line(). */ @@ -1204,6 +1235,7 @@ int main(int argc, char *argv[]) int do_unload = 0; int do_reuse_initrd = 0; int do_kexec_file_syscall = 0; + int do_status = 0; void *entry = 0; char *type = 0; char *endptr; @@ -1345,6 +1377,9 @@ int main(int
[PATCH v1] Add in kexec -S for status, and add new Xen hypercall to support this.
Heya! I am cross-posting on two mailing lists: xen-de...@lists.xenproject.org kexec@lists.infradead.org as it may be easier to review and provide input then me going back and forth. Anyhow the patches are to help with the various distro's poking in /sys/../kexec to figure out whether an kexec image is loaded. This can be done using the -S parameter now with the patch #2. Also I add an hypercall to Xen so that if kexec is running under Xen the same information can be retrieved (see patch #1). Thanks! ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v1 1/2] xen/kexec: Find out whether an kexec type is loaded.
The tools that use kexec are asynchronous in nature and do not keep state changes. As such provide an hypercall to find out whether an image has been loaded for either type. Note: No need to modify XSM as it has one size fits all check and does not check for subcommands. Signed-off-by: Konrad Rzeszutek Wilk --- v0: Internal version. v1: Dropped Reviewed-by, posting on xen-devel. CC: Elena Ufimtseva CC: Daniel Kiper --- tools/libxc/include/xenctrl.h | 8 tools/libxc/xc_kexec.c| 27 +++ xen/common/kexec.c| 25 + xen/include/public/kexec.h| 11 +++ 4 files changed, 71 insertions(+) diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index 2c83544..aa5d798 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -2574,6 +2574,14 @@ int xc_kexec_load(xc_interface *xch, uint8_t type, uint16_t arch, */ int xc_kexec_unload(xc_interface *xch, int type); +/* + * Find out whether the image has been succesfully loaded. + * + * The can be either KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH. + * If zero is returned that means the image is loaded for the type. + */ +int xc_kexec_status(xc_interface *xch, int type); + typedef xenpf_resource_entry_t xc_resource_entry_t; /* diff --git a/tools/libxc/xc_kexec.c b/tools/libxc/xc_kexec.c index 1cceb5d..95d36ff 100644 --- a/tools/libxc/xc_kexec.c +++ b/tools/libxc/xc_kexec.c @@ -126,3 +126,30 @@ out: return ret; } + +int xc_kexec_status(xc_interface *xch, int type) +{ +DECLARE_HYPERCALL; +DECLARE_HYPERCALL_BUFFER(xen_kexec_status_t, status); +int ret = -1; + +status = xc_hypercall_buffer_alloc(xch, status, sizeof(*status)); +if ( status == NULL ) +{ +PERROR("Count not alloc buffer for kexec status hypercall"); +goto out; +} + +status->type = type; + +hypercall.op = __HYPERVISOR_kexec_op; +hypercall.arg[0] = KEXEC_CMD_kexec_status; +hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(status); + +ret = do_xen_hypercall(xch, &hypercall); + +out: +xc_hypercall_buffer_free(xch, status); + +return ret; +} diff --git a/xen/common/kexec.c b/xen/common/kexec.c index c83d48f..1148f85 100644 --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -1169,6 +1169,28 @@ static int kexec_unload(XEN_GUEST_HANDLE_PARAM(void) uarg) return kexec_do_unload(&unload); } +static int kexec_status(XEN_GUEST_HANDLE_PARAM(void) uarg) +{ +xen_kexec_status_t status; +int base, bit, pos; + +if ( unlikely(copy_from_guest(&status, uarg, 1)) ) +return -EFAULT; + +if ( test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags) ) +return -EBUSY; + +if ( kexec_load_get_bits(status.type, &base, &bit) ) +return -EINVAL; + +pos = (test_bit(bit, &kexec_flags) != 0); + +if ( !test_bit(base + pos, &kexec_flags) ) +return -ENOENT; + +return 0; +} + static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg, bool_t compat) @@ -1208,6 +1230,9 @@ static int do_kexec_op_internal(unsigned long op, case KEXEC_CMD_kexec_unload: ret = kexec_unload(uarg); break; +case KEXEC_CMD_kexec_status: + ret = kexec_status(uarg); + break; } return ret; diff --git a/xen/include/public/kexec.h b/xen/include/public/kexec.h index a6a0a88..29dcb5d 100644 --- a/xen/include/public/kexec.h +++ b/xen/include/public/kexec.h @@ -227,6 +227,17 @@ typedef struct xen_kexec_unload { } xen_kexec_unload_t; DEFINE_XEN_GUEST_HANDLE(xen_kexec_unload_t); +/* + * Figure out whether we have an image loaded. An return value of + * zero indicates success while XEN_ENODEV implies no image loaded. + * + * Type must be one of KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH. + */ +#define KEXEC_CMD_kexec_status 6 +typedef struct xen_kexec_status { +uint8_t type; +} xen_kexec_status_t; +DEFINE_XEN_GUEST_HANDLE(xen_kexec_status_t); #else /* __XEN_INTERFACE_VERSION__ < 0x00040400 */ #define KEXEC_CMD_kexec_load KEXEC_CMD_kexec_load_v1 -- 2.5.5 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v1 2/2] kexec: Support -S paramter to return whether the kexec payload is loaded.
Instead of the scripts having to poke at various fields we can provide that functionality via the -S parameter. Returns 0 if the payload is loaded. Can be used in combination with -l or -p to get the state of the proper kexec image. Signed-off-by: Konrad Rzeszutek Wilk --- v0: First version (internal product). v1: Posted on kexec mailing list. Changed -s to -S CC: kexec@lists.infradead.org CC: xen-de...@lists.xenproject.org CC: Daniel Kiper --- kexec/kexec-xen.c | 20 ++ kexec/kexec.8 | 5 + kexec/kexec.c | 61 ++- kexec/kexec.h | 5 - 4 files changed, 85 insertions(+), 6 deletions(-) diff --git a/kexec/kexec-xen.c b/kexec/kexec-xen.c index 24a4191..5a1e9d2 100644 --- a/kexec/kexec-xen.c +++ b/kexec/kexec-xen.c @@ -105,6 +105,26 @@ int xen_kexec_unload(uint64_t kexec_flags) return ret; } +int xen_kexec_status(uint64_t kexec_flags) +{ + xc_interface *xch; + uint8_t type; + int ret; + + xch = xc_interface_open(NULL, NULL, 0); + if (!xch) + return -1; + + type = (kexec_flags & KEXEC_ON_CRASH) ? KEXEC_TYPE_CRASH + : KEXEC_TYPE_DEFAULT; + + ret = xc_kexec_status(xch, type); + + xc_interface_close(xch); + + return ret; +} + void xen_kexec_exec(void) { xc_interface *xch; diff --git a/kexec/kexec.8 b/kexec/kexec.8 index 4d0c1d1..02f4ccf 100644 --- a/kexec/kexec.8 +++ b/kexec/kexec.8 @@ -107,6 +107,11 @@ command: .B \-d\ (\-\-debug) Enable debugging messages. .TP +.B \-D\ (\-\-status) +Return 0 if the type (by default crash) is loaded. Can be used in conjuction +with -l or -p to toggle the type. Note it will +.BR not\ load\ the\ kernel. +.TP .B \-e\ (\-\-exec) Run the currently loaded kernel. Note that it will reboot into the loaded kernel without calling shutdown(8). .TP diff --git a/kexec/kexec.c b/kexec/kexec.c index 500e5a9..bc72688 100644 --- a/kexec/kexec.c +++ b/kexec/kexec.c @@ -855,6 +855,32 @@ static int k_unload (unsigned long kexec_flags) return result; } +static int kexec_loaded(void); +static int __kexec_loaded(const char *f); + +static int k_status(unsigned long kexec_flags) +{ + int result; + long native_arch; + + /* set the arch */ + native_arch = physical_arch(); + if (native_arch < 0) { + return -1; + } + kexec_flags |= native_arch; + + if (xen_present()) + result = xen_kexec_status(kexec_flags); + else { + if (kexec_flags & KEXEC_ON_CRASH) + result = __kexec_loaded("/sys/kernel/kexec_crash_loaded"); + else + result = kexec_loaded(); + } + return result; +} + /* * Start a reboot. */ @@ -890,8 +916,6 @@ static int my_exec(void) return -1; } -static int kexec_loaded(void); - static int load_jump_back_helper_image(unsigned long kexec_flags, void *entry) { int result; @@ -970,6 +994,7 @@ void usage(void) " to original kernel.\n" " -s, --kexec-file-syscall Use file based syscall for kexec operation\n" " -d, --debug Enable debugging to help spot a failure.\n" + " -S, --status Return 0 if the type (by default crash) is loaded.\n" "\n" "Supported kernel file types and options: \n"); for (i = 0; i < file_types; i++) { @@ -981,7 +1006,7 @@ void usage(void) printf("\n"); } -static int kexec_loaded(void) +static int __kexec_loaded(const char *file) { long ret = -1; FILE *fp; @@ -992,7 +1017,7 @@ static int kexec_loaded(void) if (xen_present()) return 1; - fp = fopen("/sys/kernel/kexec_loaded", "r"); + fp = fopen(file, "r"); if (fp == NULL) return -1; @@ -1015,6 +1040,12 @@ static int kexec_loaded(void) return (int)ret; } +static int kexec_loaded(void) +{ + return __kexec_loaded("/sys/kernel/kexec_loaded"); +} + + /* * Remove parameter from a kernel command line. Helper function by get_command_line(). */ @@ -1204,6 +1235,7 @@ int main(int argc, char *argv[]) int do_unload = 0; int do_reuse_initrd = 0; int do_kexec_file_syscall = 0; + int do_status = 0; void *entry = 0; char *type = 0; char *endptr; @@ -1345,6 +1377,9 @@ int main(int argc, char *argv[]) case OPT_KEXEC_FILE_SYSCALL: /* We already parsed it. Nothing to do. */ break; + case OPT_STATUS: + do_status = 1; + break; default: break; } @@ -1355,6 +1390,20 @@ int main(int argc, char *argv[]) if (skip_sync) do_sync = 0; + if (do_status) { +
Re: [PATCH v2] kexec: Increase the upper limit for RAM segments
I meant MAX_MEMORY_RANGES. Updated KEXEC_SEGMENT_MAX to just match this. I can revert KEXEC_SEGMENT_MAX. Thanks, Sameer On 11/14/2016 3:51 AM, Xunlei Pang wrote: On 2016/11/12 at 06:21, Sameer Goel wrote: On a newer UEFI based Qualcomm target the number of system ram regions retrieved from /proc/iomem are ~40. So increasing the current hardcoded values to 64 from 16. I am a little confused, memory regions from /proc/iomem should be MAX_MEMORY_RANGES used as the elfcorehdr, while KEXEC_SEGMENT_MAX stands for the kexec segments passed to the kexec syscall, like kernel image, initrd image, purgatory, etc. Do you mean KEXEC_SEGMENT_MAX or MAX_MEMORY_RANGES? Regards, Xunlei Signed-off-by: Sameer Goel --- kexec/arch/arm64/kexec-arm64.h | 2 +- kexec/kexec-syscall.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/kexec/arch/arm64/kexec-arm64.h b/kexec/arch/arm64/kexec-arm64.h index bac62f8..bd4c20e 100644 --- a/kexec/arch/arm64/kexec-arm64.h +++ b/kexec/arch/arm64/kexec-arm64.h @@ -11,7 +11,7 @@ #include "image-header.h" #include "kexec.h" -#define KEXEC_SEGMENT_MAX 16 +#define KEXEC_SEGMENT_MAX 64 #define BOOT_BLOCK_VERSION 17 #define BOOT_BLOCK_LAST_COMP_VERSION 16 diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h index c0d0bea..f84c937 100644 --- a/kexec/kexec-syscall.h +++ b/kexec/kexec-syscall.h @@ -115,7 +115,7 @@ static inline long kexec_file_load(int kernel_fd, int initrd_fd, #define KEXEC_ARCH_MIPS( 8 << 16) #define KEXEC_ARCH_CRIS(76 << 16) -#define KEXEC_MAX_SEGMENTS 16 +#define KEXEC_MAX_SEGMENTS 64 #ifdef __i386__ #define KEXEC_ARCH_NATIVE KEXEC_ARCH_386 -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2] kexec: Increase the upper limit for RAM segments
On 2016/11/12 at 06:21, Sameer Goel wrote: > On a newer UEFI based Qualcomm target the number of system ram regions > retrieved from /proc/iomem are ~40. So increasing the current hardcoded > values to 64 from 16. I am a little confused, memory regions from /proc/iomem should be MAX_MEMORY_RANGES used as the elfcorehdr, while KEXEC_SEGMENT_MAX stands for the kexec segments passed to the kexec syscall, like kernel image, initrd image, purgatory, etc. Do you mean KEXEC_SEGMENT_MAX or MAX_MEMORY_RANGES? Regards, Xunlei > > Signed-off-by: Sameer Goel > --- > kexec/arch/arm64/kexec-arm64.h | 2 +- > kexec/kexec-syscall.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kexec/arch/arm64/kexec-arm64.h b/kexec/arch/arm64/kexec-arm64.h > index bac62f8..bd4c20e 100644 > --- a/kexec/arch/arm64/kexec-arm64.h > +++ b/kexec/arch/arm64/kexec-arm64.h > @@ -11,7 +11,7 @@ > #include "image-header.h" > #include "kexec.h" > > -#define KEXEC_SEGMENT_MAX 16 > +#define KEXEC_SEGMENT_MAX 64 > > #define BOOT_BLOCK_VERSION 17 > #define BOOT_BLOCK_LAST_COMP_VERSION 16 > diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h > index c0d0bea..f84c937 100644 > --- a/kexec/kexec-syscall.h > +++ b/kexec/kexec-syscall.h > @@ -115,7 +115,7 @@ static inline long kexec_file_load(int kernel_fd, int > initrd_fd, > #define KEXEC_ARCH_MIPS( 8 << 16) > #define KEXEC_ARCH_CRIS(76 << 16) > > -#define KEXEC_MAX_SEGMENTS 16 > +#define KEXEC_MAX_SEGMENTS 64 > > #ifdef __i386__ > #define KEXEC_ARCH_NATIVEKEXEC_ARCH_386 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/3] crash: move crashkernel parsing and vmcore related code under CONFIG_CRASH_CORE
On 11/10/16 at 05:27pm, Hari Bathini wrote: > Traditionally, kdump is used to save vmcore in case of a crash. Some > architectures like powerpc can save vmcore using architecture specific > support instead of kexec/kdump mechanism. Such architecture specific > support also needs to reserve memory, to be used by dump capture kernel. > crashkernel parameter can be a reused, for memory reservation, by such > architecture specific infrastructure. > > But currently, code related to vmcoreinfo and parsing of crashkernel > parameter is built under CONFIG_KEXEC_CORE. This patch introduces > CONFIG_CRASH_CORE and moves the above mentioned code under this config, > allowing code reuse without dependency on CONFIG_KEXEC. While here, > removing the multiple definitions of append_elf_note() and final_note() > for one defined under CONFIG_CONFIG_CORE. There is no functional change > with this patch. Can't think of a reason to object. Could it be that do the moving from kexec_core.c to crash_core.c only, then do the arch specific clean up in another patch? Besides there's already a file crash_dump.h, can we reuse that? > > Signed-off-by: Hari Bathini > --- > arch/Kconfig |4 > arch/ia64/kernel/crash.c | 22 -- > arch/powerpc/Kconfig | 10 - > arch/powerpc/include/asm/fadump.h |2 > arch/powerpc/kernel/crash.c|2 > arch/powerpc/kernel/fadump.c | 34 --- > arch/powerpc/kernel/setup-common.c |5 > include/linux/crash_core.h | 75 ++ > include/linux/kexec.h | 63 - > kernel/Makefile|1 > kernel/crash_core.c| 450 > > kernel/kexec_core.c| 435 --- > 12 files changed, 550 insertions(+), 553 deletions(-) > create mode 100644 include/linux/crash_core.h > create mode 100644 kernel/crash_core.c > > diff --git a/arch/Kconfig b/arch/Kconfig > index 659bdd0..4ad34b9 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -2,7 +2,11 @@ > # General architecture dependent options > # > > +config CRASH_CORE > + bool > + > config KEXEC_CORE > + select CRASH_CORE > bool > > config OPROFILE > diff --git a/arch/ia64/kernel/crash.c b/arch/ia64/kernel/crash.c > index 2955f35..75859a0 100644 > --- a/arch/ia64/kernel/crash.c > +++ b/arch/ia64/kernel/crash.c > @@ -27,28 +27,6 @@ static int kdump_freeze_monarch; > static int kdump_on_init = 1; > static int kdump_on_fatal_mca = 1; > > -static inline Elf64_Word > -*append_elf_note(Elf64_Word *buf, char *name, unsigned type, void *data, > - size_t data_len) > -{ > - struct elf_note *note = (struct elf_note *)buf; > - note->n_namesz = strlen(name) + 1; > - note->n_descsz = data_len; > - note->n_type = type; > - buf += (sizeof(*note) + 3)/4; > - memcpy(buf, name, note->n_namesz); > - buf += (note->n_namesz + 3)/4; > - memcpy(buf, data, data_len); > - buf += (data_len + 3)/4; > - return buf; > -} > - > -static void > -final_note(void *buf) > -{ > - memset(buf, 0, sizeof(struct elf_note)); > -} > - > extern void ia64_dump_cpu_regs(void *); > > static DEFINE_PER_CPU(struct elf_prstatus, elf_prstatus); > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 65fba4c..644703f 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -479,21 +479,23 @@ config RELOCATABLE > load address of the kernel (eg. u-boot/mkimage). > > config CRASH_DUMP > - bool "Build a kdump crash kernel" > + bool "Build a dump capture kernel" > depends on PPC64 || 6xx || FSL_BOOKE || (44x && !SMP) > select RELOCATABLE if (PPC64 && !COMPILE_TEST) || 44x || FSL_BOOKE > help > - Build a kernel suitable for use as a kdump capture kernel. > + Build a kernel suitable for use as a dump capture kernel. > The same kernel binary can be used as production kernel and dump > capture kernel. > > config FA_DUMP > bool "Firmware-assisted dump" > - depends on PPC64 && PPC_RTAS && CRASH_DUMP && KEXEC > + depends on PPC64 && PPC_RTAS > + select CRASH_CORE > + select CRASH_DUMP > help > A robust mechanism to get reliable kernel crash dump with > assistance from firmware. This approach does not use kexec, > - instead firmware assists in booting the kdump kernel > + instead firmware assists in booting the capture kernel > while preserving memory contents. Firmware-assisted dump > is meant to be a kdump replacement offering robustness and > speed not possible without system firmware assistance. > diff --git a/arch/powerpc/include/asm/fadump.h > b/arch/powerpc/include/asm/fadump.h > index 0031806..60b9108 100644 > --- a/arch/powerpc/include/asm/fadump.h > +++ b/arch/powerpc/include/asm/fadump.h > @@ -73,6 +73,8 @@ > reg_entry++;
Re: [PATCH 1/3] crash: move crashkernel parsing and vmcore related code under CONFIG_CRASH_CORE
On Monday 14 November 2016 11:06 AM, Baoquan He wrote: On 11/10/16 at 05:27pm, Hari Bathini wrote: Traditionally, kdump is used to save vmcore in case of a crash. Some architectures like powerpc can save vmcore using architecture specific support instead of kexec/kdump mechanism. Such architecture specific support also needs to reserve memory, to be used by dump capture kernel. crashkernel parameter can be a reused, for memory reservation, by such architecture specific infrastructure. But currently, code related to vmcoreinfo and parsing of crashkernel parameter is built under CONFIG_KEXEC_CORE. This patch introduces CONFIG_CRASH_CORE and moves the above mentioned code under this config, allowing code reuse without dependency on CONFIG_KEXEC. While here, removing the multiple definitions of append_elf_note() and final_note() for one defined under CONFIG_CONFIG_CORE. There is no functional change with this patch. Can't think of a reason to object. Could it be that do the moving from kexec_core.c to crash_core.c only, then do the arch specific clean up in another patch? Right. Will move arch specific code into a separate patch, on the next version.. Besides there's already a file crash_dump.h, can we reuse that? Did think about it. But as it is meant for dump capture kernel (CONFIG_CRASH_DUMP) and CONFIG_KEXEC_CORE being independent, didn't pursue it.. Thanks Hari ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec