From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751810AbaLSCkY (ORCPT ); Thu, 18 Dec 2014 21:40:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46286 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751158AbaLSCkX (ORCPT ); Thu, 18 Dec 2014 21:40:23 -0500 Date: Fri, 19 Dec 2014 10:39:50 +0800 From: Baoquan He To: HATAYAMA Daisuke Cc: ebiederm@xmission.com, vgoyal@redhat.com, kumagai-atsushi@mxc.nes.nec.co.jp, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, anderson@redhat.com Subject: Re: [PATCH v2] kdump, vmcoreinfo: report actual value of phys_base Message-ID: <20141219023950.GC23128@dhcp-16-116.nay.redhat.com> References: <20141113.113011.630216167285231824.d.hatayama@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141113.113011.630216167285231824.d.hatayama@jp.fujitsu.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/13/14 at 11:30am, HATAYAMA Daisuke wrote: > Currently, VMCOREINFO note information reports the virtual address of > phys_base that is assigned to symbol phys_base. But this doesn't make > sense because to refer to phys_base, it's necessary to get the value > of phys_base itself we are now about to refer to. > > Userland tools related to kdump such as makedumpfile and crash utility > so far have made some efforts to calculate phys_base on crash dump > formats generated by mechanisms running outside Linux kernel, such as > virtual machine hypervisor such as qemu dump, which ordinary users use > via virsh dump, or ones implemented on vendor specific firmware. > > That is, find a kernel data whose virtual and physical addresses are > available via its note information and calculate phys_base from > it. However, such data structure is not the one prepared for phys_base > purpose. There's no guarantee that other crash dump mechanisms include > such information that can be used to calculate phys_base similarly. > > To get VMCOREINFO in vmcore, it's easy to use strings and grep > commands like this; VMCOREINFO consists of simple string: > > $ strings vmcore-3.10.0-121.el7.x86_64 | grep -E ".*VMCOREINFO.*" -A 100 > VMCOREINFO > OSRELEASE=3.10.0-121.el7.x86_64 > PAGESIZE=4096 > ... > > This is also useful to get value of phys_base in kdump 2nd kernel > contained in vmcore using the above-mentioned external crash dump > mechanism; kdump 2nd kernel is an inherently relocated kernel. > > This commit doesn't remove VMCOREINFO_SYMBOL(phys_base) line because > makedumpfile refers to it and if removing it, old versions > makedumpfile doesn't work well. > > ChangeLog: > v2: > - Introduce VMCOREINFO_PHYS_BASE(). > - Correct patch description: this work is primarily for mechanisms > running outside (kdump 1st) Linux kernel. > > Signed-off-by: HATAYAMA Daisuke > --- > arch/x86/kernel/machine_kexec_64.c | 1 + > include/linux/kexec.h | 2 ++ > 2 files changed, 3 insertions(+) > > diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c > index 4859810..47cc835 100644 > --- a/arch/x86/kernel/machine_kexec_64.c > +++ b/arch/x86/kernel/machine_kexec_64.c > @@ -334,6 +334,7 @@ void arch_crash_save_vmcoreinfo(void) > #endif > vmcoreinfo_append_str("KERNELOFFSET=%lx\n", > (unsigned long)&_text - __START_KERNEL); > + VMCOREINFO_PHYS_BASE(phys_base); > } > > /* arch-dependent functionality related to kexec file-based syscall */ > diff --git a/include/linux/kexec.h b/include/linux/kexec.h > index 9d957b7..bee3c5b 100644 > --- a/include/linux/kexec.h > +++ b/include/linux/kexec.h > @@ -258,6 +258,8 @@ unsigned long paddr_vmcoreinfo_note(void); > vmcoreinfo_append_str("NUMBER(%s)=%ld\n", #name, (long)name) > #define VMCOREINFO_CONFIG(name) \ > vmcoreinfo_append_str("CONFIG_%s=y\n", #name) > +#define VMCOREINFO_PHYS_BASE(value) \ > + vmcoreinfo_append_str("PHYS_BASE=%lx\n", (unsigned long)value) I don't like the idea that add a new MACRO for a specific case. I prefer it to be a generic MACRO which can be used by later adding if they want to add a unsigned long value. > > extern struct kimage *kexec_image; > extern struct kimage *kexec_crash_image; > -- > 1.9.3 > > > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Y1nUJ-0001f1-1k for kexec@lists.infradead.org; Fri, 19 Dec 2014 02:40:20 +0000 Date: Fri, 19 Dec 2014 10:39:50 +0800 From: Baoquan He Subject: Re: [PATCH v2] kdump, vmcoreinfo: report actual value of phys_base Message-ID: <20141219023950.GC23128@dhcp-16-116.nay.redhat.com> References: <20141113.113011.630216167285231824.d.hatayama@jp.fujitsu.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20141113.113011.630216167285231824.d.hatayama@jp.fujitsu.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: HATAYAMA Daisuke Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, anderson@redhat.com, ebiederm@xmission.com, kumagai-atsushi@mxc.nes.nec.co.jp, vgoyal@redhat.com On 11/13/14 at 11:30am, HATAYAMA Daisuke wrote: > Currently, VMCOREINFO note information reports the virtual address of > phys_base that is assigned to symbol phys_base. But this doesn't make > sense because to refer to phys_base, it's necessary to get the value > of phys_base itself we are now about to refer to. > > Userland tools related to kdump such as makedumpfile and crash utility > so far have made some efforts to calculate phys_base on crash dump > formats generated by mechanisms running outside Linux kernel, such as > virtual machine hypervisor such as qemu dump, which ordinary users use > via virsh dump, or ones implemented on vendor specific firmware. > > That is, find a kernel data whose virtual and physical addresses are > available via its note information and calculate phys_base from > it. However, such data structure is not the one prepared for phys_base > purpose. There's no guarantee that other crash dump mechanisms include > such information that can be used to calculate phys_base similarly. > > To get VMCOREINFO in vmcore, it's easy to use strings and grep > commands like this; VMCOREINFO consists of simple string: > > $ strings vmcore-3.10.0-121.el7.x86_64 | grep -E ".*VMCOREINFO.*" -A 100 > VMCOREINFO > OSRELEASE=3.10.0-121.el7.x86_64 > PAGESIZE=4096 > ... > > This is also useful to get value of phys_base in kdump 2nd kernel > contained in vmcore using the above-mentioned external crash dump > mechanism; kdump 2nd kernel is an inherently relocated kernel. > > This commit doesn't remove VMCOREINFO_SYMBOL(phys_base) line because > makedumpfile refers to it and if removing it, old versions > makedumpfile doesn't work well. > > ChangeLog: > v2: > - Introduce VMCOREINFO_PHYS_BASE(). > - Correct patch description: this work is primarily for mechanisms > running outside (kdump 1st) Linux kernel. > > Signed-off-by: HATAYAMA Daisuke > --- > arch/x86/kernel/machine_kexec_64.c | 1 + > include/linux/kexec.h | 2 ++ > 2 files changed, 3 insertions(+) > > diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c > index 4859810..47cc835 100644 > --- a/arch/x86/kernel/machine_kexec_64.c > +++ b/arch/x86/kernel/machine_kexec_64.c > @@ -334,6 +334,7 @@ void arch_crash_save_vmcoreinfo(void) > #endif > vmcoreinfo_append_str("KERNELOFFSET=%lx\n", > (unsigned long)&_text - __START_KERNEL); > + VMCOREINFO_PHYS_BASE(phys_base); > } > > /* arch-dependent functionality related to kexec file-based syscall */ > diff --git a/include/linux/kexec.h b/include/linux/kexec.h > index 9d957b7..bee3c5b 100644 > --- a/include/linux/kexec.h > +++ b/include/linux/kexec.h > @@ -258,6 +258,8 @@ unsigned long paddr_vmcoreinfo_note(void); > vmcoreinfo_append_str("NUMBER(%s)=%ld\n", #name, (long)name) > #define VMCOREINFO_CONFIG(name) \ > vmcoreinfo_append_str("CONFIG_%s=y\n", #name) > +#define VMCOREINFO_PHYS_BASE(value) \ > + vmcoreinfo_append_str("PHYS_BASE=%lx\n", (unsigned long)value) I don't like the idea that add a new MACRO for a specific case. I prefer it to be a generic MACRO which can be used by later adding if they want to add a unsigned long value. > > extern struct kimage *kexec_image; > extern struct kimage *kexec_crash_image; > -- > 1.9.3 > > > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec