[patch 0/2] kdump: Initialize vmcoreinfo note at startup

[patch 0/2] kdump: Initialize vmcoreinfo note at startup

[Michael Holzheu]

Hello Vivek,

Another patch that we would like to have upstream is the vmcoreinfo
note intitialization. This is independent from the s390 kdump port.
We need that for our traditional stand-alone and hypervisor dump
tools. You already have agreed that the patch looks ok:
https://lkml.org/lkml/2011/7/20/296

So could we get an ACK from you for the patch?

[1] kdump: Initialize vmcoreinfo note at startup
[2] s390: Export vmcoreinfo note

Thanks!

Michael

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

[patch 0/2] kdump: Initialize vmcoreinfo note at startup

[Michael Holzheu]

Hello Vivek,

Another patch that we would like to have upstream is the vmcoreinfo
note intitialization. This is independent from the s390 kdump port.
We need that for our traditional stand-alone and hypervisor dump
tools. You already have agreed that the patch looks ok:
https://lkml.org/lkml/2011/7/20/296

So could we get an ACK from you for the patch?

[1] kdump: Initialize vmcoreinfo note at startup
[2] s390: Export vmcoreinfo note

Thanks!

Michael

[patch 1/2] kdump: Initialize vmcoreinfo note at startup

[Michael Holzheu]

[-- Attachment #1: s390-kdump-common-vmcoreinfo-init.patch --]
[-- Type: text/plain, Size: 1774 bytes --]

From: Michael Holzheu <holzheu@linux.vnet.ibm.com>

Currently the vmcoreinfo note is only initialized in case of kdump. On s390
it is possible to create kernel dumps with other dump mechanisms than kdump
(e.g. via hypervisor dump or stand-alone dump tools). For those dumps it
would also be desirable to include the vmcoreinfo data. To accomplish this,
with this patch the vmcoreinfo ELF note is always initialized, not only in
case of a (kdump) crash. On s390 we will add an ABI defined pointer at
a well known address to vmcoreinfo so that dump analysis tools are able to
find this information.

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
---
 kernel/kexec.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1392,24 +1392,23 @@ int __init parse_crashkernel(char 		 *cm
 }
 
 
-
-void crash_save_vmcoreinfo(void)
+static void update_vmcoreinfo_note(void)
 {
-	u32 *buf;
+	u32 *buf = (u32 *) vmcoreinfo_note;
 
 	if (!vmcoreinfo_size)
 		return;
-
-	vmcoreinfo_append_str("CRASHTIME=%ld", get_seconds());
-
-	buf = (u32 *)vmcoreinfo_note;
-
 	buf = append_elf_note(buf, VMCOREINFO_NOTE_NAME, 0, vmcoreinfo_data,
 			      vmcoreinfo_size);
-
 	final_note(buf);
 }
 
+void crash_save_vmcoreinfo(void)
+{
+	vmcoreinfo_append_str("CRASHTIME=%ld", get_seconds());
+	update_vmcoreinfo_note();
+}
+
 void vmcoreinfo_append_str(const char *fmt, ...)
 {
 	va_list args;
@@ -1495,6 +1494,7 @@ static int __init crash_save_vmcoreinfo_
 	VMCOREINFO_NUMBER(PG_swapcache);
 
 	arch_crash_save_vmcoreinfo();
+	update_vmcoreinfo_note();
 
 	return 0;
 }


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

[patch 1/2] kdump: Initialize vmcoreinfo note at startup

[Michael Holzheu]

[-- Attachment #1: s390-kdump-common-vmcoreinfo-init.patch --]
[-- Type: text/plain, Size: 1630 bytes --]

From: Michael Holzheu <holzheu@linux.vnet.ibm.com>

Currently the vmcoreinfo note is only initialized in case of kdump. On s390
it is possible to create kernel dumps with other dump mechanisms than kdump
(e.g. via hypervisor dump or stand-alone dump tools). For those dumps it
would also be desirable to include the vmcoreinfo data. To accomplish this,
with this patch the vmcoreinfo ELF note is always initialized, not only in
case of a (kdump) crash. On s390 we will add an ABI defined pointer at
a well known address to vmcoreinfo so that dump analysis tools are able to
find this information.

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
---
 kernel/kexec.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1392,24 +1392,23 @@ int __init parse_crashkernel(char 		 *cm
 }
 
 
-
-void crash_save_vmcoreinfo(void)
+static void update_vmcoreinfo_note(void)
 {
-	u32 *buf;
+	u32 *buf = (u32 *) vmcoreinfo_note;
 
 	if (!vmcoreinfo_size)
 		return;
-
-	vmcoreinfo_append_str("CRASHTIME=%ld", get_seconds());
-
-	buf = (u32 *)vmcoreinfo_note;
-
 	buf = append_elf_note(buf, VMCOREINFO_NOTE_NAME, 0, vmcoreinfo_data,
 			      vmcoreinfo_size);
-
 	final_note(buf);
 }
 
+void crash_save_vmcoreinfo(void)
+{
+	vmcoreinfo_append_str("CRASHTIME=%ld", get_seconds());
+	update_vmcoreinfo_note();
+}
+
 void vmcoreinfo_append_str(const char *fmt, ...)
 {
 	va_list args;
@@ -1495,6 +1494,7 @@ static int __init crash_save_vmcoreinfo_
 	VMCOREINFO_NUMBER(PG_swapcache);
 
 	arch_crash_save_vmcoreinfo();
+	update_vmcoreinfo_note();
 
 	return 0;
 }

Re: [patch 1/2] kdump: Initialize vmcoreinfo note at startup

[Vivek Goyal]

On Fri, Sep 09, 2011 at 12:27:00PM +0200, Michael Holzheu wrote:
> From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> 
> Currently the vmcoreinfo note is only initialized in case of kdump. On s390
> it is possible to create kernel dumps with other dump mechanisms than kdump
> (e.g. via hypervisor dump or stand-alone dump tools).

Both of these will be invoked through panic notifiers because kdump kernel
is not loaded?

>For those dumps it
> would also be desirable to include the vmcoreinfo data.

Curious that how these two dump schemes make use vmcoreinfo data?

> To accomplish this,
> with this patch the vmcoreinfo ELF note is always initialized, not only in
> case of a (kdump) crash. On s390 we will add an ABI defined pointer at
> a well known address to vmcoreinfo so that dump analysis tools are able to
> find this information.

Instead of this, why don't you initialize the notes in your arch specific
call. IOW, why don't you give a call to crash_save_vmcoreinfo() in stand
alone dump path to prepare the note and then continue with stand alone
dump.

Thanks
Vivek

> 
> Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> ---
>  kernel/kexec.c |   18 +++++++++---------
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -1392,24 +1392,23 @@ int __init parse_crashkernel(char 		 *cm
>  }
>  
>  
> -
> -void crash_save_vmcoreinfo(void)
> +static void update_vmcoreinfo_note(void)
>  {
> -	u32 *buf;
> +	u32 *buf = (u32 *) vmcoreinfo_note;
>  
>  	if (!vmcoreinfo_size)
>  		return;
> -
> -	vmcoreinfo_append_str("CRASHTIME=%ld", get_seconds());
> -
> -	buf = (u32 *)vmcoreinfo_note;
> -
>  	buf = append_elf_note(buf, VMCOREINFO_NOTE_NAME, 0, vmcoreinfo_data,
>  			      vmcoreinfo_size);
> -
>  	final_note(buf);
>  }
>  
> +void crash_save_vmcoreinfo(void)
> +{
> +	vmcoreinfo_append_str("CRASHTIME=%ld", get_seconds());
> +	update_vmcoreinfo_note();
> +}
> +
>  void vmcoreinfo_append_str(const char *fmt, ...)
>  {
>  	va_list args;
> @@ -1495,6 +1494,7 @@ static int __init crash_save_vmcoreinfo_
>  	VMCOREINFO_NUMBER(PG_swapcache);
>  
>  	arch_crash_save_vmcoreinfo();
> +	update_vmcoreinfo_note();
>  
>  	return 0;
>  }

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

Re: [patch 1/2] kdump: Initialize vmcoreinfo note at startup

[Vivek Goyal]

On Fri, Sep 09, 2011 at 12:27:00PM +0200, Michael Holzheu wrote:
> From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> 
> Currently the vmcoreinfo note is only initialized in case of kdump. On s390
> it is possible to create kernel dumps with other dump mechanisms than kdump
> (e.g. via hypervisor dump or stand-alone dump tools).

Both of these will be invoked through panic notifiers because kdump kernel
is not loaded?

>For those dumps it
> would also be desirable to include the vmcoreinfo data.

Curious that how these two dump schemes make use vmcoreinfo data?

> To accomplish this,
> with this patch the vmcoreinfo ELF note is always initialized, not only in
> case of a (kdump) crash. On s390 we will add an ABI defined pointer at
> a well known address to vmcoreinfo so that dump analysis tools are able to
> find this information.

Instead of this, why don't you initialize the notes in your arch specific
call. IOW, why don't you give a call to crash_save_vmcoreinfo() in stand
alone dump path to prepare the note and then continue with stand alone
dump.

Thanks
Vivek

> 
> Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> ---
>  kernel/kexec.c |   18 +++++++++---------
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -1392,24 +1392,23 @@ int __init parse_crashkernel(char 		 *cm
>  }
>  
>  
> -
> -void crash_save_vmcoreinfo(void)
> +static void update_vmcoreinfo_note(void)
>  {
> -	u32 *buf;
> +	u32 *buf = (u32 *) vmcoreinfo_note;
>  
>  	if (!vmcoreinfo_size)
>  		return;
> -
> -	vmcoreinfo_append_str("CRASHTIME=%ld", get_seconds());
> -
> -	buf = (u32 *)vmcoreinfo_note;
> -
>  	buf = append_elf_note(buf, VMCOREINFO_NOTE_NAME, 0, vmcoreinfo_data,
>  			      vmcoreinfo_size);
> -
>  	final_note(buf);
>  }
>  
> +void crash_save_vmcoreinfo(void)
> +{
> +	vmcoreinfo_append_str("CRASHTIME=%ld", get_seconds());
> +	update_vmcoreinfo_note();
> +}
> +
>  void vmcoreinfo_append_str(const char *fmt, ...)
>  {
>  	va_list args;
> @@ -1495,6 +1494,7 @@ static int __init crash_save_vmcoreinfo_
>  	VMCOREINFO_NUMBER(PG_swapcache);
>  
>  	arch_crash_save_vmcoreinfo();
> +	update_vmcoreinfo_note();
>  
>  	return 0;
>  }

Re: [patch 1/2] kdump: Initialize vmcoreinfo note at startup

[Michael Holzheu]

Hello Vivek,

On Thu, 2011-09-15 at 14:46 -0400, Vivek Goyal wrote:
> On Fri, Sep 09, 2011 at 12:27:00PM +0200, Michael Holzheu wrote:
> > From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> > 
> > Currently the vmcoreinfo note is only initialized in case of kdump. On s390
> > it is possible to create kernel dumps with other dump mechanisms than kdump
> > (e.g. via hypervisor dump or stand-alone dump tools).
> 
> Both of these will be invoked through panic notifiers because kdump kernel
> is not loaded?

This is only one possibility. The other is that they are invoked
manually or by hypervisor watchdog without any Linux kernel involvement.

> 
> >For those dumps it
> > would also be desirable to include the vmcoreinfo data.
> 
> Curious that how these two dump schemes make use vmcoreinfo data?

We have a tool named zgetdump. With this tool it is possible to convert
dump formats on the fly using fuse. E.g. you can mount a s390
stand-alone dump as ELF dump. When this is done, the tool finds the
vmcoreinfo in the stand-alone dump via our well known ABI defined
address and it creates the respective VMCOREINFO ELF note in the output
ELF dump. This then can be used e.g. by makedumpfile for dump filtering.
No more need for a vmlinux file with debug information.

So this will look like the following:

# zgetdump --mount standalone.dump -f elf /mnt
# ls /mnt
# dump.elf
# readelf -n /mnt/dump.elf
# ...
  VMCOREINFO		0x00000474	Unknown note type: (0x00000000)
# makedumpfile -c -d 31 /mnt/dump.elf dump.kdump

> 
> > To accomplish this,
> > with this patch the vmcoreinfo ELF note is always initialized, not only in
> > case of a (kdump) crash. On s390 we will add an ABI defined pointer at
> > a well known address to vmcoreinfo so that dump analysis tools are able to
> > find this information.
> 
> Instead of this, why don't you initialize the notes in your arch specific
> call. IOW, why don't you give a call to crash_save_vmcoreinfo() in stand
> alone dump path to prepare the note and then continue with stand alone
> dump.

We can't do that because stand-alone and hypervisor dump can be
triggered completely without Linux. So no Linux kernel function can/will
be called.

Michael


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

Re: [patch 1/2] kdump: Initialize vmcoreinfo note at startup

[Michael Holzheu]

Hello Vivek,

On Thu, 2011-09-15 at 14:46 -0400, Vivek Goyal wrote:
> On Fri, Sep 09, 2011 at 12:27:00PM +0200, Michael Holzheu wrote:
> > From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> > 
> > Currently the vmcoreinfo note is only initialized in case of kdump. On s390
> > it is possible to create kernel dumps with other dump mechanisms than kdump
> > (e.g. via hypervisor dump or stand-alone dump tools).
> 
> Both of these will be invoked through panic notifiers because kdump kernel
> is not loaded?

This is only one possibility. The other is that they are invoked
manually or by hypervisor watchdog without any Linux kernel involvement.

> 
> >For those dumps it
> > would also be desirable to include the vmcoreinfo data.
> 
> Curious that how these two dump schemes make use vmcoreinfo data?

We have a tool named zgetdump. With this tool it is possible to convert
dump formats on the fly using fuse. E.g. you can mount a s390
stand-alone dump as ELF dump. When this is done, the tool finds the
vmcoreinfo in the stand-alone dump via our well known ABI defined
address and it creates the respective VMCOREINFO ELF note in the output
ELF dump. This then can be used e.g. by makedumpfile for dump filtering.
No more need for a vmlinux file with debug information.

So this will look like the following:

# zgetdump --mount standalone.dump -f elf /mnt
# ls /mnt
# dump.elf
# readelf -n /mnt/dump.elf
# ...
  VMCOREINFO		0x00000474	Unknown note type: (0x00000000)
# makedumpfile -c -d 31 /mnt/dump.elf dump.kdump

> 
> > To accomplish this,
> > with this patch the vmcoreinfo ELF note is always initialized, not only in
> > case of a (kdump) crash. On s390 we will add an ABI defined pointer at
> > a well known address to vmcoreinfo so that dump analysis tools are able to
> > find this information.
> 
> Instead of this, why don't you initialize the notes in your arch specific
> call. IOW, why don't you give a call to crash_save_vmcoreinfo() in stand
> alone dump path to prepare the note and then continue with stand alone
> dump.

We can't do that because stand-alone and hypervisor dump can be
triggered completely without Linux. So no Linux kernel function can/will
be called.

Michael

Re: [patch 1/2] kdump: Initialize vmcoreinfo note at startup

[Vivek Goyal]

On Fri, Sep 16, 2011 at 10:21:17AM +0200, Michael Holzheu wrote:
> Hello Vivek,
> 
> On Thu, 2011-09-15 at 14:46 -0400, Vivek Goyal wrote:
> > On Fri, Sep 09, 2011 at 12:27:00PM +0200, Michael Holzheu wrote:
> > > From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> > > 
> > > Currently the vmcoreinfo note is only initialized in case of kdump. On s390
> > > it is possible to create kernel dumps with other dump mechanisms than kdump
> > > (e.g. via hypervisor dump or stand-alone dump tools).
> > 
> > Both of these will be invoked through panic notifiers because kdump kernel
> > is not loaded?
> 
> This is only one possibility. The other is that they are invoked
> manually or by hypervisor watchdog without any Linux kernel involvement.
> 
> > 
> > >For those dumps it
> > > would also be desirable to include the vmcoreinfo data.
> > 
> > Curious that how these two dump schemes make use vmcoreinfo data?
> 
> We have a tool named zgetdump. With this tool it is possible to convert
> dump formats on the fly using fuse. E.g. you can mount a s390
> stand-alone dump as ELF dump. When this is done, the tool finds the
> vmcoreinfo in the stand-alone dump via our well known ABI defined
> address and it creates the respective VMCOREINFO ELF note in the output
> ELF dump. This then can be used e.g. by makedumpfile for dump filtering.
> No more need for a vmlinux file with debug information.

Ok, so you basically need it so that makedumpfile can do filtering without
debug info.

Well, if zgetdump is doing everything and you are stashing away an arch
specific pointer, I guss you could have saved pointer directly to
vmcoreinfo_data and then zgetdump could have made an ELF note out of it
for use of makedumpfile.

But anyway, having kernel exported the note does not harm.

> So this will look like the following:
> 
> # zgetdump --mount standalone.dump -f elf /mnt
> # ls /mnt
> # dump.elf
> # readelf -n /mnt/dump.elf
> # ...
>   VMCOREINFO		0x00000474	Unknown note type: (0x00000000)
> # makedumpfile -c -d 31 /mnt/dump.elf dump.kdump

If you can do this easily, then you really did not need kdump in kernel? 
Just use stand alone dump to take dump and then do this to filter dump.

But what happens to ELF headers which map kernel virtual address to
physical addresses? kexec-tools prepares those. So in this case when
you are capturing the dump, who prepares those? IOW, how does zgetdump
creates a mapping between kernel virtual and physical addresses?

Thanks
Vivek

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

Re: [patch 1/2] kdump: Initialize vmcoreinfo note at startup

[Vivek Goyal]

On Fri, Sep 16, 2011 at 10:21:17AM +0200, Michael Holzheu wrote:
> Hello Vivek,
> 
> On Thu, 2011-09-15 at 14:46 -0400, Vivek Goyal wrote:
> > On Fri, Sep 09, 2011 at 12:27:00PM +0200, Michael Holzheu wrote:
> > > From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> > > 
> > > Currently the vmcoreinfo note is only initialized in case of kdump. On s390
> > > it is possible to create kernel dumps with other dump mechanisms than kdump
> > > (e.g. via hypervisor dump or stand-alone dump tools).
> > 
> > Both of these will be invoked through panic notifiers because kdump kernel
> > is not loaded?
> 
> This is only one possibility. The other is that they are invoked
> manually or by hypervisor watchdog without any Linux kernel involvement.
> 
> > 
> > >For those dumps it
> > > would also be desirable to include the vmcoreinfo data.
> > 
> > Curious that how these two dump schemes make use vmcoreinfo data?
> 
> We have a tool named zgetdump. With this tool it is possible to convert
> dump formats on the fly using fuse. E.g. you can mount a s390
> stand-alone dump as ELF dump. When this is done, the tool finds the
> vmcoreinfo in the stand-alone dump via our well known ABI defined
> address and it creates the respective VMCOREINFO ELF note in the output
> ELF dump. This then can be used e.g. by makedumpfile for dump filtering.
> No more need for a vmlinux file with debug information.

Ok, so you basically need it so that makedumpfile can do filtering without
debug info.

Well, if zgetdump is doing everything and you are stashing away an arch
specific pointer, I guss you could have saved pointer directly to
vmcoreinfo_data and then zgetdump could have made an ELF note out of it
for use of makedumpfile.

But anyway, having kernel exported the note does not harm.

> So this will look like the following:
> 
> # zgetdump --mount standalone.dump -f elf /mnt
> # ls /mnt
> # dump.elf
> # readelf -n /mnt/dump.elf
> # ...
>   VMCOREINFO		0x00000474	Unknown note type: (0x00000000)
> # makedumpfile -c -d 31 /mnt/dump.elf dump.kdump

If you can do this easily, then you really did not need kdump in kernel? 
Just use stand alone dump to take dump and then do this to filter dump.

But what happens to ELF headers which map kernel virtual address to
physical addresses? kexec-tools prepares those. So in this case when
you are capturing the dump, who prepares those? IOW, how does zgetdump
creates a mapping between kernel virtual and physical addresses?

Thanks
Vivek

Re: [patch 1/2] kdump: Initialize vmcoreinfo note at startup

[Michael Holzheu]

Hello Vivek,

On Mon, 2011-09-19 at 14:36 -0400, Vivek Goyal wrote:
> On Fri, Sep 16, 2011 at 10:21:17AM +0200, Michael Holzheu wrote:
> > > Curious that how these two dump schemes make use vmcoreinfo data?
> > 
> > We have a tool named zgetdump. With this tool it is possible to convert
> > dump formats on the fly using fuse. E.g. you can mount a s390
> > stand-alone dump as ELF dump. When this is done, the tool finds the
> > vmcoreinfo in the stand-alone dump via our well known ABI defined
> > address and it creates the respective VMCOREINFO ELF note in the output
> > ELF dump. This then can be used e.g. by makedumpfile for dump filtering.
> > No more need for a vmlinux file with debug information.
> 
> Ok, so you basically need it so that makedumpfile can do filtering without
> debug info.
> 
> Well, if zgetdump is doing everything and you are stashing away an arch
> specific pointer, I guss you could have saved pointer directly to
> vmcoreinfo_data and then zgetdump could have made an ELF note out of it
> for use of makedumpfile.

Yes that would also be an option. But still you have to initialize the
data at startup.

> But anyway, having kernel exported the note does not harm.

Correct.

> > So this will look like the following:
> > 
> > # zgetdump --mount standalone.dump -f elf /mnt
> > # ls /mnt
> > # dump.elf
> > # readelf -n /mnt/dump.elf
> > # ...
> >   VMCOREINFO		0x00000474	Unknown note type: (0x00000000)
> > # makedumpfile -c -d 31 /mnt/dump.elf dump.kdump
> 
> If you can do this easily, then you really did not need kdump in kernel? 
> Just use stand alone dump to take dump and then do this to filter dump.

For large systems we still need kdump to do the the filtering while
dumping. Currently with stand-alone dump tools we first have to dump all
the memory (which takes a long time) and afterwards do the filtering.

And with kdump we just can reuse all the installer stuff that is already
available.

> But what happens to ELF headers which map kernel virtual address to
> physical addresses? kexec-tools prepares those. So in this case when
> you are capturing the dump, who prepares those? IOW, how does zgetdump
> creates a mapping between kernel virtual and physical addresses?

On s390 we have a 1:1 mapping for the kernel. For the ELF header loads
created by zgetdump virtual=real.

I hope this answers your questions.

So do you agree now with the patch and give us your ACK?

Thanks
Michael


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

Re: [patch 1/2] kdump: Initialize vmcoreinfo note at startup

[Michael Holzheu]

Hello Vivek,

On Mon, 2011-09-19 at 14:36 -0400, Vivek Goyal wrote:
> On Fri, Sep 16, 2011 at 10:21:17AM +0200, Michael Holzheu wrote:
> > > Curious that how these two dump schemes make use vmcoreinfo data?
> > 
> > We have a tool named zgetdump. With this tool it is possible to convert
> > dump formats on the fly using fuse. E.g. you can mount a s390
> > stand-alone dump as ELF dump. When this is done, the tool finds the
> > vmcoreinfo in the stand-alone dump via our well known ABI defined
> > address and it creates the respective VMCOREINFO ELF note in the output
> > ELF dump. This then can be used e.g. by makedumpfile for dump filtering.
> > No more need for a vmlinux file with debug information.
> 
> Ok, so you basically need it so that makedumpfile can do filtering without
> debug info.
> 
> Well, if zgetdump is doing everything and you are stashing away an arch
> specific pointer, I guss you could have saved pointer directly to
> vmcoreinfo_data and then zgetdump could have made an ELF note out of it
> for use of makedumpfile.

Yes that would also be an option. But still you have to initialize the
data at startup.

> But anyway, having kernel exported the note does not harm.

Correct.

> > So this will look like the following:
> > 
> > # zgetdump --mount standalone.dump -f elf /mnt
> > # ls /mnt
> > # dump.elf
> > # readelf -n /mnt/dump.elf
> > # ...
> >   VMCOREINFO		0x00000474	Unknown note type: (0x00000000)
> > # makedumpfile -c -d 31 /mnt/dump.elf dump.kdump
> 
> If you can do this easily, then you really did not need kdump in kernel? 
> Just use stand alone dump to take dump and then do this to filter dump.

For large systems we still need kdump to do the the filtering while
dumping. Currently with stand-alone dump tools we first have to dump all
the memory (which takes a long time) and afterwards do the filtering.

And with kdump we just can reuse all the installer stuff that is already
available.

> But what happens to ELF headers which map kernel virtual address to
> physical addresses? kexec-tools prepares those. So in this case when
> you are capturing the dump, who prepares those? IOW, how does zgetdump
> creates a mapping between kernel virtual and physical addresses?

On s390 we have a 1:1 mapping for the kernel. For the ELF header loads
created by zgetdump virtual=real.

I hope this answers your questions.

So do you agree now with the patch and give us your ACK?

Thanks
Michael

Re: [patch 1/2] kdump: Initialize vmcoreinfo note at startup

[Vivek Goyal]

On Fri, Sep 09, 2011 at 12:27:00PM +0200, Michael Holzheu wrote:
> From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> 
> Currently the vmcoreinfo note is only initialized in case of kdump. On s390
> it is possible to create kernel dumps with other dump mechanisms than kdump
> (e.g. via hypervisor dump or stand-alone dump tools). For those dumps it
> would also be desirable to include the vmcoreinfo data. To accomplish this,
> with this patch the vmcoreinfo ELF note is always initialized, not only in
> case of a (kdump) crash. On s390 we will add an ABI defined pointer at
> a well known address to vmcoreinfo so that dump analysis tools are able to
> find this information.
> 
> Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>

Looks good to me.

Acked-by: Vivek Goyal <vgoyal@redhat.com>

> ---
>  kernel/kexec.c |   18 +++++++++---------
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -1392,24 +1392,23 @@ int __init parse_crashkernel(char 		 *cm
>  }
>  
>  
> -
> -void crash_save_vmcoreinfo(void)
> +static void update_vmcoreinfo_note(void)
>  {
> -	u32 *buf;
> +	u32 *buf = (u32 *) vmcoreinfo_note;
>  
>  	if (!vmcoreinfo_size)
>  		return;
> -
> -	vmcoreinfo_append_str("CRASHTIME=%ld", get_seconds());
> -
> -	buf = (u32 *)vmcoreinfo_note;
> -
>  	buf = append_elf_note(buf, VMCOREINFO_NOTE_NAME, 0, vmcoreinfo_data,
>  			      vmcoreinfo_size);
> -
>  	final_note(buf);
>  }
>  
> +void crash_save_vmcoreinfo(void)
> +{
> +	vmcoreinfo_append_str("CRASHTIME=%ld", get_seconds());
> +	update_vmcoreinfo_note();
> +}
> +
>  void vmcoreinfo_append_str(const char *fmt, ...)
>  {
>  	va_list args;
> @@ -1495,6 +1494,7 @@ static int __init crash_save_vmcoreinfo_
>  	VMCOREINFO_NUMBER(PG_swapcache);
>  
>  	arch_crash_save_vmcoreinfo();
> +	update_vmcoreinfo_note();
>  
>  	return 0;
>  }

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

Re: [patch 1/2] kdump: Initialize vmcoreinfo note at startup

[Vivek Goyal]

On Fri, Sep 09, 2011 at 12:27:00PM +0200, Michael Holzheu wrote:
> From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> 
> Currently the vmcoreinfo note is only initialized in case of kdump. On s390
> it is possible to create kernel dumps with other dump mechanisms than kdump
> (e.g. via hypervisor dump or stand-alone dump tools). For those dumps it
> would also be desirable to include the vmcoreinfo data. To accomplish this,
> with this patch the vmcoreinfo ELF note is always initialized, not only in
> case of a (kdump) crash. On s390 we will add an ABI defined pointer at
> a well known address to vmcoreinfo so that dump analysis tools are able to
> find this information.
> 
> Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>

Looks good to me.

Acked-by: Vivek Goyal <vgoyal@redhat.com>

> ---
>  kernel/kexec.c |   18 +++++++++---------
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -1392,24 +1392,23 @@ int __init parse_crashkernel(char 		 *cm
>  }
>  
>  
> -
> -void crash_save_vmcoreinfo(void)
> +static void update_vmcoreinfo_note(void)
>  {
> -	u32 *buf;
> +	u32 *buf = (u32 *) vmcoreinfo_note;
>  
>  	if (!vmcoreinfo_size)
>  		return;
> -
> -	vmcoreinfo_append_str("CRASHTIME=%ld", get_seconds());
> -
> -	buf = (u32 *)vmcoreinfo_note;
> -
>  	buf = append_elf_note(buf, VMCOREINFO_NOTE_NAME, 0, vmcoreinfo_data,
>  			      vmcoreinfo_size);
> -
>  	final_note(buf);
>  }
>  
> +void crash_save_vmcoreinfo(void)
> +{
> +	vmcoreinfo_append_str("CRASHTIME=%ld", get_seconds());
> +	update_vmcoreinfo_note();
> +}
> +
>  void vmcoreinfo_append_str(const char *fmt, ...)
>  {
>  	va_list args;
> @@ -1495,6 +1494,7 @@ static int __init crash_save_vmcoreinfo_
>  	VMCOREINFO_NUMBER(PG_swapcache);
>  
>  	arch_crash_save_vmcoreinfo();
> +	update_vmcoreinfo_note();
>  
>  	return 0;
>  }

[patch 2/2] s390: Export vmcoreinfo note

[Michael Holzheu]

[-- Attachment #1: s390-kdump-arch-vmcoreinfo.patch --]
[-- Type: text/plain, Size: 1596 bytes --]

From: Michael Holzheu <holzheu@linux.vnet.ibm.com>

This patch defines for s390 an ABI defined pointer to the vmcoreinfo note at
a well known address. With this patch tools are able to find this information
in dumps created by stand-alone or hypervisor dump tools.

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
---
 arch/s390/include/asm/lowcore.h |    3 ++-
 arch/s390/kernel/setup.c        |    8 ++++++++
 2 files changed, 10 insertions(+), 1 deletion(-)

--- a/arch/s390/include/asm/lowcore.h
+++ b/arch/s390/include/asm/lowcore.h
@@ -287,7 +287,8 @@ struct _lowcore {
 	 */
 	__u64	ipib;				/* 0x0e00 */
 	__u32	ipib_checksum;			/* 0x0e08 */
-	__u8	pad_0x0e0c[0x0f00-0x0e0c];	/* 0x0e0c */
+	__u64	vmcore_info;			/* 0x0e0c */
+	__u8	pad_0x0e14[0x0f00-0x0e14];	/* 0x0e14 */
 
 	/* Extended facility list */
 	__u64	stfle_fac_list[32];		/* 0x0f00 */
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -559,6 +559,13 @@ static void __init setup_restart_psw(voi
 	copy_to_absolute_zero(&S390_lowcore.restart_psw, &psw, sizeof(psw));
 }
 
+static void __init setup_vmcoreinfo(void)
+{
+	unsigned long ptr = paddr_vmcoreinfo_note();
+
+	copy_to_absolute_zero(&S390_lowcore.vmcore_info, &ptr, sizeof(ptr));
+}
+
 #ifdef CONFIG_CRASH_DUMP
 
 /*
@@ -1019,6 +1026,7 @@ setup_arch(char **cmdline_p)
 	reserve_crashkernel();
 	setup_memory();
 	setup_resources();
+	setup_vmcoreinfo();
 	setup_restart_psw();
 	setup_lowcore();
 


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

[patch 2/2] s390: Export vmcoreinfo note

[Michael Holzheu]

[-- Attachment #1: s390-kdump-arch-vmcoreinfo.patch --]
[-- Type: text/plain, Size: 1452 bytes --]

From: Michael Holzheu <holzheu@linux.vnet.ibm.com>

This patch defines for s390 an ABI defined pointer to the vmcoreinfo note at
a well known address. With this patch tools are able to find this information
in dumps created by stand-alone or hypervisor dump tools.

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
---
 arch/s390/include/asm/lowcore.h |    3 ++-
 arch/s390/kernel/setup.c        |    8 ++++++++
 2 files changed, 10 insertions(+), 1 deletion(-)

--- a/arch/s390/include/asm/lowcore.h
+++ b/arch/s390/include/asm/lowcore.h
@@ -287,7 +287,8 @@ struct _lowcore {
 	 */
 	__u64	ipib;				/* 0x0e00 */
 	__u32	ipib_checksum;			/* 0x0e08 */
-	__u8	pad_0x0e0c[0x0f00-0x0e0c];	/* 0x0e0c */
+	__u64	vmcore_info;			/* 0x0e0c */
+	__u8	pad_0x0e14[0x0f00-0x0e14];	/* 0x0e14 */
 
 	/* Extended facility list */
 	__u64	stfle_fac_list[32];		/* 0x0f00 */
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -559,6 +559,13 @@ static void __init setup_restart_psw(voi
 	copy_to_absolute_zero(&S390_lowcore.restart_psw, &psw, sizeof(psw));
 }
 
+static void __init setup_vmcoreinfo(void)
+{
+	unsigned long ptr = paddr_vmcoreinfo_note();
+
+	copy_to_absolute_zero(&S390_lowcore.vmcore_info, &ptr, sizeof(ptr));
+}
+
 #ifdef CONFIG_CRASH_DUMP
 
 /*
@@ -1019,6 +1026,7 @@ setup_arch(char **cmdline_p)
 	reserve_crashkernel();
 	setup_memory();
 	setup_resources();
+	setup_vmcoreinfo();
 	setup_restart_psw();
 	setup_lowcore();
 

[patch 0/2] kdump: Initialize vmcoreinfo note at startup

[Michael Holzheu]

Hello Andrew,

Another common code patch that we would like to have upstream is the vmcoreinfo
note initialization at Linux startup time. We need that for our traditional
stand-alone and hypervisor dump tools.

[1] kdump: Initialize vmcoreinfo note at startup
[2] s390: Export vmcoreinfo note

I already have discussed this with Vivek and he has acked the common code
patch [1].

Do you agree that Martin sends these patches together with the kdump page
table patches (see https://lkml.org/lkml/2011/9/15/55) in the next merge
window?

Michael

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

[patch 0/2] kdump: Initialize vmcoreinfo note at startup

[Michael Holzheu]

Hello Andrew,

Another common code patch that we would like to have upstream is the vmcoreinfo
note initialization at Linux startup time. We need that for our traditional
stand-alone and hypervisor dump tools.

[1] kdump: Initialize vmcoreinfo note at startup
[2] s390: Export vmcoreinfo note

I already have discussed this with Vivek and he has acked the common code
patch [1].

Do you agree that Martin sends these patches together with the kdump page
table patches (see https://lkml.org/lkml/2011/9/15/55) in the next merge
window?

Michael

Re: [patch 0/2] kdump: Initialize vmcoreinfo note at startup

[Andrew Morton]

On Tue, 20 Sep 2011 16:34:00 +0200
Michael Holzheu <holzheu@linux.vnet.ibm.com> wrote:

> Hello Andrew,
> 
> Another common code patch that we would like to have upstream is the vmcoreinfo
> note initialization at Linux startup time. We need that for our traditional
> stand-alone and hypervisor dump tools.
> 
> [1] kdump: Initialize vmcoreinfo note at startup
> [2] s390: Export vmcoreinfo note
> 
> I already have discussed this with Vivek and he has acked the common code
> patch [1].
> 
> Do you agree that Martin sends these patches together with the kdump page
> table patches (see https://lkml.org/lkml/2011/9/15/55) in the next merge
> window?

Sounds good to me, thanks.

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

Re: [patch 0/2] kdump: Initialize vmcoreinfo note at startup

[Andrew Morton]

On Tue, 20 Sep 2011 16:34:00 +0200
Michael Holzheu <holzheu@linux.vnet.ibm.com> wrote:

> Hello Andrew,
> 
> Another common code patch that we would like to have upstream is the vmcoreinfo
> note initialization at Linux startup time. We need that for our traditional
> stand-alone and hypervisor dump tools.
> 
> [1] kdump: Initialize vmcoreinfo note at startup
> [2] s390: Export vmcoreinfo note
> 
> I already have discussed this with Vivek and he has acked the common code
> patch [1].
> 
> Do you agree that Martin sends these patches together with the kdump page
> table patches (see https://lkml.org/lkml/2011/9/15/55) in the next merge
> window?

Sounds good to me, thanks.