Re: [PATCH] /proc/kcore: Update physical address for kcore ram and text

Hi Dave, On Wednesday 25 January 2017 11:59 AM, Dave Young wrote: Hi Pratyush On 01/25/17 at 10:14am, Pratyush Anand wrote: Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is not true and could be misleading, since 0 is a valid physical address. I do not know the history

Re: [PATCH v30 04/11] arm64: mm: allow for unmapping memory region from kernel mapping

On Tue, Jan 24, 2017 at 05:02:20PM +0530, Pratyush Anand wrote: > > > On Tuesday 24 January 2017 02:19 PM, AKASHI Takahiro wrote: > >The current implementation of create_mapping_late() is only allowed > >to modify permission attributes (read-only or read-write) against > >the existing kernel

Re: [PATCH] /proc/kcore: Update physical address for kcore ram and text

Hi Pratyush On 01/25/17 at 10:14am, Pratyush Anand wrote: > Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is > not true and could be misleading, since 0 is a valid physical address. I do not know the history of /proc/kcore, so a question is why the p_addr was set as 0, if

[PATCH] /proc/kcore: Update physical address for kcore ram and text

Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is not true and could be misleading, since 0 is a valid physical address. User space tools like makedumpfile needs to know physical address for PT_LOAD segments of direct mapped regions. Therefore this patch updates paddr for

Re: [PATCH v3] kexec: implemented XEN KEXEC STATUS to determine if an image is loaded

On 01/24/2017 01:16 PM, Daniel Kiper wrote: On Tue, Jan 24, 2017 at 12:55:35PM -0600, Eric DeVolder wrote: Instead of the scripts having to poke at various fields we can provide that functionality via the -S parameter. kexec_loaded/kexec_crash_loaded exposes Linux kernel kexec/crash state. It

Re: [PATCH v3] kexec: implemented XEN KEXEC STATUS to determine if an image is loaded

On 01/24/2017 01:16 PM, Daniel Kiper wrote: On Tue, Jan 24, 2017 at 12:55:35PM -0600, Eric DeVolder wrote: Instead of the scripts having to poke at various fields we can provide that functionality via the -S parameter. kexec_loaded/kexec_crash_loaded exposes Linux kernel kexec/crash state. It

[PATCH v3] kexec: implemented XEN KEXEC STATUS to determine if an image is loaded

Instead of the scripts having to poke at various fields we can provide that functionality via the -S parameter. kexec_loaded/kexec_crash_loaded exposes Linux kernel kexec/crash state. It does not say anything about Xen kexec/crash state. So, we need a special approach to get the latter. Though

Re: [PATCH v4 2/5] ia64: reuse append_elf_note() and final_note() functions

On Tue, Jan 24, 2017 at 10:11 AM, Hari Bathini wrote: > Hello IA64 folks, > > Could you please review this patch..? It looks OK in principal. My lab is in partial disarray at the moment (just got back from a sabbatical) so I can't test build and boot. Have you

Re: [PATCH v4 2/5] ia64: reuse append_elf_note() and final_note() functions

On Tuesday 17 January 2017 10:36 PM, Hari Bathini wrote: On Friday 06 January 2017 07:33 AM, Dave Young wrote: On 01/05/17 at 11:01pm, Hari Bathini wrote: Get rid of multiple definitions of append_elf_note() & final_note() functions. Reuse these functions compiled under CONFIG_CRASH_CORE

Re: [PATCH v4 2/5] ia64: reuse append_elf_note() and final_note() functions

On Friday 20 January 2017 11:17 AM, Michael Ellerman wrote: Hari Bathini writes: Get rid of multiple definitions of append_elf_note() & final_note() functions. Reuse these functions compiled under CONFIG_CRASH_CORE Also, define Elf_Word and use it instead of

Re: [PATCH v2] kexec: implemented XEN KEXEC STATUS to determine if an image is loaded

On Tue, Jan 24, 2017 at 02:35:17PM +0100, Simon Horman wrote: > On Fri, Jan 20, 2017 at 11:03:54AM -0600, Eric DeVolder 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

Re: [PATCH v3] kexec: Increase the upper limit for RAM segments

On Wed, Jan 18, 2017 at 04:15:12PM -0700, 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. > > Signed-off-by: Sameer Goel Thanks,

Re: [PATCH] alpha: add missing __NR_kexec_load definition

On Tue, Dec 20, 2016 at 09:29:18AM +0100, Simon Horman wrote: > Signed-off-by: Simon Horman > --- > kexec/kexec-syscall.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h > index c0d0beadf932..3b5c528d8aac 100644 > ---

Re: [PATCH v2] kexec: implemented XEN KEXEC STATUS to determine if an image is loaded

On Fri, Jan 20, 2017 at 11:03:54AM -0600, Eric DeVolder 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

Re: [PATCH] ppc64: Reduce number of ELF LOAD segments

On Thu, Jan 19, 2017 at 06:37:09PM +0100, Petr Tesarik wrote: > The number of program header table entries (e_phnum) is an Elf64_Half, > which is a 16-bit entity, i.e. the limit is 65534 entries (one entry is > reserved for NOTE). This is a hard limit, defined by the ELF standard. > It is possible

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

On Tue, Jan 24, 2017 at 09:27:45AM +0800, Xunlei Pang wrote: > It occurred on real hardware when testing crash dump. > > 1) SysRq-c was injected for the test in 1st kernel > [ 49.897279] SysRq : Trigger a crash 2) The 2nd kernel started for kdump >[ 0.00] Command line:

Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after system panic

On 01/23/2017 at 10:50 PM, Borislav Petkov wrote: > On Mon, Jan 23, 2017 at 09:35:53PM +0800, Xunlei Pang wrote: >> One possible timing sequence would be: >> 1st kernel running on multiple cpus panicked >> then the crash dump code starts >> the crash dump code stops the others cpus except the

Re: [PATCH v30 04/11] arm64: mm: allow for unmapping memory region from kernel mapping

On Tuesday 24 January 2017 02:19 PM, AKASHI Takahiro wrote: The current implementation of create_mapping_late() is only allowed to modify permission attributes (read-only or read-write) against the existing kernel mapping. In this patch, PAGE_KERNEL_INVALID protection attribute is introduced.

[PATCH v30 05/11] arm64: kdump: protect crash dump kernel memory

To protect the memory reserved for crash dump kernel once after loaded, arch_kexec_protect_crashres/unprotect_crashres() are meant to deal with permissions of the corresponding kernel mappings. We also have to - put the region in an isolated mapping, and - move copying kexec's control_code_page

[PATCH v30 11/11] Documentation: dt: chosen properties for arm64 kdump

From: James Morse Add documentation for DT properties: linux,usable-memory-range linux,elfcorehdr used by arm64 kdump. Those decribe the usable memory range for crash dump kernel and the elfcorehdr's location within it, respectively. Signed-off-by: James

[PATCH v30 10/11] Documentation: kdump: describe arm64 port

Add arch specific descriptions about kdump usage on arm64 to kdump.txt. Signed-off-by: AKASHI Takahiro Reviewed-by: Baoquan He Acked-by: Dave Young Acked-by: Catalin Marinas ---

[PATCH v30 09/11] arm64: kdump: enable kdump in defconfig

Kdump is enabled by default as kexec is. Signed-off-by: AKASHI Takahiro Acked-by: Catalin Marinas --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig

[PATCH v30 07/11] arm64: kdump: add VMCOREINFO's for user-space tools

In addition to common VMCOREINFO's defined in crash_save_vmcoreinfo_init(), we need to know, for crash utility, - kimage_voffset - PHYS_OFFSET to examine the contents of a dump file (/proc/vmcore) correctly due to the introduction of KASLR (CONFIG_RANDOMIZE_BASE) in v4.6. - VA_BITS is also

[PATCH v30 08/11] arm64: kdump: provide /proc/vmcore file

Add arch-specific functions to provide a dump file, /proc/vmcore. This file is in ELF format and its ELF header needs to be prepared by userspace tools, like kexec-tools, in adance. The primary kernel is responsible to allocate the region with reserve_elfcorehdr() at boot time and advertize its

[PATCH v30 06/11] arm64: kdump: implement machine_crash_shutdown()

Primary kernel calls machine_crash_shutdown() to shut down non-boot cpus and save registers' status in per-cpu ELF notes before starting crash dump kernel. See kernel_kexec(). Even if not all secondary cpus have shut down, we do kdump anyway. As we don't have to make non-boot(crashed) cpus

[PATCH v30 04/11] arm64: mm: allow for unmapping memory region from kernel mapping

The current implementation of create_mapping_late() is only allowed to modify permission attributes (read-only or read-write) against the existing kernel mapping. In this patch, PAGE_KERNEL_INVALID protection attribute is introduced. We will now be able to invalidate (or unmap) some part of the

[PATCH v30 03/11] arm64: kdump: reserve memory for crash dump kernel

"crashkernel=" kernel parameter specifies the size (and optionally the start address) of the system ram used by crash dump kernel. reserve_crashkernel() will allocate and reserve the memory at the startup of primary kernel. This memory range will be exported to userspace via an entry named "Crash

[PATCH v30 02/11] arm64: limit memory regions based on DT property, usable-memory-range

Crash dump kernel utilizes only a subset of available memory as System RAM. On arm64 kdump, This memory range is advertized to crash dump kernel via a device-tree property under /chosen, linux,usable-memory-range = Crash dump kernel reads this property at boot time and calls

[PATCH v30 01/11] memblock: add memblock_cap_memory_range()

Add memblock_cap_memory_range() which will remove all the memblock regions except the memory range specified in the arguments. In addition, rework is done on memblock_mem_limit_remove_map() to re-implement it using memblock_cap_memory_range(). This function, like memblock_mem_limit_remove_map(),

[PATCH v30 00/11] arm64: add kdump support

This patch series adds kdump support on arm64. To load a crash-dump kernel to the systems, a series of patches to kexec-tools[1] are also needed. Please use the latest one, v5 [2]. For your convinience, you can pick them up from: https://git.linaro.org/people/takahiro.akashi/linux-aarch64.git

[PATCH v5 9/9] arm64: kdump: Add support for binary image files

From: Pratyush Anand This patch adds support to use binary image ie arch/arm64/boot/Image with kdump. Signed-off-by: Pratyush Anand [takahiro.aka...@linaro.org: a bit reworked] Signed-off-by: AKASHI Takahiro ---

[PATCH v5 8/9] arm64: kdump: add DT properties to crash dump kernel's dtb

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

[PATCH v5 6/9] arm64: kdump: set up kernel image segment

On arm64, we can use the same kernel image as 1st kernel, but we have to modify the entry point as well as segments' addresses in the kernel's elf header in order to load them into correct places. Signed-off-by: AKASHI Takahiro --- kexec/arch/arm64/crashdump-arm64.c

[PATCH v5 7/9] arm64: kdump: set up other segments

We make sure that all the other segments, initrd and device-tree blob, also be loaded into the reserved memory of crash dump kernel. Signed-off-by: AKASHI Takahiro --- kexec/arch/arm64/kexec-arm64.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff

[PATCH v5 4/9] arm64: kdump: identify memory regions

The following regions need to be identified for later use: a) memory regions which belong to the 1st kernel b) usable memory reserved for crash dump kernel We go through /proc/iomem to find out a) and b) which are marked as "System RAM" and "Crash kernel", respectively. Signed-off-by: AKASHI

[PATCH v5 5/9] arm64: kdump: add elf core header segment

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

[PATCH v5 3/9] arm64: identify PHYS_OFFSET correctly

Due to the kernel patch, commit e7cd190385d1 ("arm64: mark reserved memblock regions explicitly in iomem"), the current code will not be able to identify the correct value of PHYS_OFFSET if some "reserved" memory region, which is likely to be UEFI runtime services code/data, exists at an address

[PATCH v5 2/9] kexec: generalize and rename get_kernel_stext_sym()

From: Pratyush Anand get_kernel_stext_sym() has been defined for both arm and i386. Other architecture might need some other kernel symbol address. Therefore rewrite this function as generic function to get any kernel symbol address. More over, kallsyms is not arch specific