All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] kdump, vmcoreinfo: report actual value of phys_base
@ 2014-11-13  2:30 ` HATAYAMA Daisuke
  0 siblings, 0 replies; 7+ messages in thread
From: HATAYAMA Daisuke @ 2014-11-13  2:30 UTC (permalink / raw)
  To: ebiederm, vgoyal; +Cc: linux-kernel, kexec, kumagai-atsushi, anderson

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 <d.hatayama@jp.fujitsu.com>
---
 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)
 
 extern struct kimage *kexec_image;
 extern struct kimage *kexec_crash_image;
-- 
1.9.3



^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH v2] kdump, vmcoreinfo: report actual value of phys_base
@ 2014-11-13  2:30 ` HATAYAMA Daisuke
  0 siblings, 0 replies; 7+ messages in thread
From: HATAYAMA Daisuke @ 2014-11-13  2:30 UTC (permalink / raw)
  To: ebiederm, vgoyal; +Cc: kumagai-atsushi, kexec, linux-kernel, anderson

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 <d.hatayama@jp.fujitsu.com>
---
 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)
 
 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

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] kdump, vmcoreinfo: report actual value of phys_base
  2014-11-13  2:30 ` HATAYAMA Daisuke
  (?)
@ 2014-12-15 23:11 ` Andrew Morton
  2015-01-02 13:42   ` Vivek Goyal
  -1 siblings, 1 reply; 7+ messages in thread
From: Andrew Morton @ 2014-12-15 23:11 UTC (permalink / raw)
  To: HATAYAMA Daisuke; +Cc: kumagai-atsushi, kexec, ebiederm, vgoyal, anderson


(cc trimmed a bit)

On Thu, 13 Nov 2014 11:30:11 +0900 (JST) HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> 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.

Folks, could we please get a bit of reviewing, acking or nacking for
this one?


From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Subject: kdump, vmcoreinfo: report actual value of phys_base

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.

Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: Dave Anderson <anderson@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/x86/kernel/machine_kexec_64.c |    1 +
 include/linux/kexec.h              |    2 ++
 2 files changed, 3 insertions(+)

diff -puN arch/x86/kernel/machine_kexec_64.c~kdump-vmcoreinfo-report-actual-value-of-phys_base arch/x86/kernel/machine_kexec_64.c
--- a/arch/x86/kernel/machine_kexec_64.c~kdump-vmcoreinfo-report-actual-value-of-phys_base
+++ a/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 -puN include/linux/kexec.h~kdump-vmcoreinfo-report-actual-value-of-phys_base include/linux/kexec.h
--- a/include/linux/kexec.h~kdump-vmcoreinfo-report-actual-value-of-phys_base
+++ a/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)
 
 extern struct kimage *kexec_image;
 extern struct kimage *kexec_crash_image;
_


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] kdump, vmcoreinfo: report actual value of phys_base
  2014-11-13  2:30 ` HATAYAMA Daisuke
@ 2014-12-19  2:39   ` Baoquan He
  -1 siblings, 0 replies; 7+ messages in thread
From: Baoquan He @ 2014-12-19  2:39 UTC (permalink / raw)
  To: HATAYAMA Daisuke
  Cc: ebiederm, vgoyal, kumagai-atsushi, kexec, linux-kernel, anderson

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 <d.hatayama@jp.fujitsu.com>
> ---
>  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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] kdump, vmcoreinfo: report actual value of phys_base
@ 2014-12-19  2:39   ` Baoquan He
  0 siblings, 0 replies; 7+ messages in thread
From: Baoquan He @ 2014-12-19  2:39 UTC (permalink / raw)
  To: HATAYAMA Daisuke
  Cc: kexec, linux-kernel, anderson, ebiederm, kumagai-atsushi, vgoyal

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 <d.hatayama@jp.fujitsu.com>
> ---
>  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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] kdump, vmcoreinfo: report actual value of phys_base
  2014-12-15 23:11 ` Andrew Morton
@ 2015-01-02 13:42   ` Vivek Goyal
  2015-01-05  8:49     ` Petr Tesarik
  0 siblings, 1 reply; 7+ messages in thread
From: Vivek Goyal @ 2015-01-02 13:42 UTC (permalink / raw)
  To: Andrew Morton
  Cc: kumagai-atsushi, HATAYAMA Daisuke, kexec, ebiederm, anderson

On Mon, Dec 15, 2014 at 03:11:20PM -0800, Andrew Morton wrote:
> 
> (cc trimmed a bit)
> 
> On Thu, 13 Nov 2014 11:30:11 +0900 (JST) HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> 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.
> 
> Folks, could we please get a bit of reviewing, acking or nacking for
> this one?

To me this patch is more like a hack or a quick fix to get dump filtering
working when dump is generated using virsh-dump like tools. I feel there
should be discussion on what's the proper way to do this. I don't have
very specific ideas though at this point of time.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] kdump, vmcoreinfo: report actual value of phys_base
  2015-01-02 13:42   ` Vivek Goyal
@ 2015-01-05  8:49     ` Petr Tesarik
  0 siblings, 0 replies; 7+ messages in thread
From: Petr Tesarik @ 2015-01-05  8:49 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: kexec, HATAYAMA Daisuke, kumagai-atsushi, ebiederm, anderson,
	Andrew Morton

On Fri, 2 Jan 2015 08:42:40 -0500
Vivek Goyal <vgoyal@redhat.com> wrote:

> On Mon, Dec 15, 2014 at 03:11:20PM -0800, Andrew Morton wrote:
> > 
> > (cc trimmed a bit)
> > 
> > On Thu, 13 Nov 2014 11:30:11 +0900 (JST) HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> 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.
> > 
> > Folks, could we please get a bit of reviewing, acking or nacking for
> > this one?
> 
> To me this patch is more like a hack or a quick fix to get dump filtering
> working when dump is generated using virsh-dump like tools. I feel there
> should be discussion on what's the proper way to do this. I don't have
> very specific ideas though at this point of time.

For one thing, the virtual address of phys_base is useless. This is
nicely demonstrated by the fact that it is not used by any kernel dump
processing project I'm aware of (crash, makedumpfile, libkdumpfile).

On the other hand, either the _value_ of phys_base or its _physical_
location in RAM would be useful. If it was available, I would
immediately start using it in libkdumpfile to determine kernel physical
base. In fact, writing a similar patch was already on my TODO list when
Daisuke sent his.

Petr T

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-01-05  8:49 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-13  2:30 [PATCH v2] kdump, vmcoreinfo: report actual value of phys_base HATAYAMA Daisuke
2014-11-13  2:30 ` HATAYAMA Daisuke
2014-12-15 23:11 ` Andrew Morton
2015-01-02 13:42   ` Vivek Goyal
2015-01-05  8:49     ` Petr Tesarik
2014-12-19  2:39 ` Baoquan He
2014-12-19  2:39   ` Baoquan He

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.