Xen devel - Jul 2012 - [PATCH] kexec-tools: Read always one vmcoreinfo file

vmcoreinfo file could exists under /sys/kernel (valid on baremetal only)
and/or under /sys/hypervisor (valid when Xen dom0 is running).
Read only one of them. It means that only one PT_NOTE will be
always created. Remove extra code for second PT_NOTE creation.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 kexec/crashdump-elf.c |   33 +++++++--------------------------
 1 files changed, 7 insertions(+), 26 deletions(-)

diff --git a/kexec/crashdump-elf.c b/kexec/crashdump-elf.c
index 8d82db9..ec66548 100644
--- a/kexec/crashdump-elf.c
+++ b/kexec/crashdump-elf.c
@@ -40,8 +40,6 @@ int FUNC(struct kexec_info *info,
 	uint64_t notes_addr, notes_len;
 	uint64_t vmcoreinfo_addr, vmcoreinfo_len;
 	int has_vmcoreinfo = 0;
-	uint64_t vmcoreinfo_addr_xen, vmcoreinfo_len_xen;
-	int has_vmcoreinfo_xen = 0;
 	int (*get_note_info)(int cpu, uint64_t *addr, uint64_t *len);
 
 	if (xen_present())
@@ -53,16 +51,14 @@ int FUNC(struct kexec_info *info,
 		return -1;
 	}
 
-	if (get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len) == 0) {
-		has_vmcoreinfo = 1;
-	}
-
-	if (xen_present() &&
-	    get_xen_vmcoreinfo(&vmcoreinfo_addr_xen, &vmcoreinfo_len_xen) ==
0) {
-		has_vmcoreinfo_xen = 1;
-	}
+	if (xen_present()) {
+		if (!get_xen_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
+			has_vmcoreinfo = 1;
+	} else
+		if (!get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
+			has_vmcoreinfo = 1;
 
-	sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo + has_vmcoreinfo_xen) *
sizeof(PHDR) +
+	sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo) * sizeof(PHDR) +
 	     ranges * sizeof(PHDR);
 
 	/*
@@ -179,21 +175,6 @@ int FUNC(struct kexec_info *info,
 		dbgprintf_phdr("vmcoreinfo header", phdr);
 	}
 
-	if (has_vmcoreinfo_xen) {
-		phdr = (PHDR *) bufp;
-		bufp += sizeof(PHDR);
-		phdr->p_type	= PT_NOTE;
-		phdr->p_flags	= 0;
-		phdr->p_offset  = phdr->p_paddr = vmcoreinfo_addr_xen;
-		phdr->p_vaddr   = 0;
-		phdr->p_filesz	= phdr->p_memsz	= vmcoreinfo_len_xen;
-		/* Do we need any alignment of segments? */
-		phdr->p_align	= 0;
-
-		(elf->e_phnum)++;
-		dbgprintf_phdr("vmcoreinfo_xen header", phdr);
-	}
-
 	/* Setup an PT_LOAD type program header for the region where
 	 * Kernel is mapped if elf_info->kern_size is non-zero.
 	 */
-- 
1.5.6.5

On Thu, Jul 05, 2012 at 02:16:35PM +0200, Daniel Kiper
wrote:
> vmcoreinfo file could exists under /sys/kernel (valid on baremetal only)
> and/or under /sys/hypervisor (valid when Xen dom0 is running).
> Read only one of them. It means that only one PT_NOTE will be
> always created. Remove extra code for second PT_NOTE creation.
> 
> Signed-off-by: Daniel Kiper
<daniel.kiper-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Thanks, applied.

Dne Čt 5. července 2012 14:16:35 Daniel Kiper napsal(a):
> vmcoreinfo file could exists under /sys/kernel (valid on baremetal only)
> and/or under /sys/hypervisor (valid when Xen dom0 is running).
> Read only one of them. It means that only one PT_NOTE will be
> always created. Remove extra code for second PT_NOTE creation.
Hi Daniel,

are you absolutely sure this is the right thing to do? IIUC these two 
VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo 
describes the Dom0 kernel (type 'VMCOREINFO'), while the one from 
/sys/hypervisor describes the Xen hypervisor (type 'XEN_VMCOREINFO'). If
you
keep only the hypervisor note, then e.g. makedumpfile won't be able to use 
dumplevel greater than 1, nor will it be able to extract the log buffer.

Petr Tesarik
SUSE Linux
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  kexec/crashdump-elf.c |   33 +++++++--------------------------
>  1 files changed, 7 insertions(+), 26 deletions(-)
> 
> diff --git a/kexec/crashdump-elf.c b/kexec/crashdump-elf.c
> index 8d82db9..ec66548 100644
> --- a/kexec/crashdump-elf.c
> +++ b/kexec/crashdump-elf.c
> @@ -40,8 +40,6 @@ int FUNC(struct kexec_info *info,
>  	uint64_t notes_addr, notes_len;
>  	uint64_t vmcoreinfo_addr, vmcoreinfo_len;
>  	int has_vmcoreinfo = 0;
> -	uint64_t vmcoreinfo_addr_xen, vmcoreinfo_len_xen;
> -	int has_vmcoreinfo_xen = 0;
>  	int (*get_note_info)(int cpu, uint64_t *addr, uint64_t *len);
> 
>  	if (xen_present())
> @@ -53,16 +51,14 @@ int FUNC(struct kexec_info *info,
>  		return -1;
>  	}
> 
> -	if (get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len) ==
0) {
> -		has_vmcoreinfo = 1;
> -	}
> -
> -	if (xen_present() &&
> -	    get_xen_vmcoreinfo(&vmcoreinfo_addr_xen, &vmcoreinfo_len_xen)
== 0) {
> -		has_vmcoreinfo_xen = 1;
> -	}
> +	if (xen_present()) {
> +		if (!get_xen_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
> +			has_vmcoreinfo = 1;
> +	} else
> +		if (!get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
> +			has_vmcoreinfo = 1;
> 
> -	sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo + has_vmcoreinfo_xen) *
> sizeof(PHDR) + +	sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo) *
> sizeof(PHDR) +
>  	     ranges * sizeof(PHDR);
> 
>  	/*
> @@ -179,21 +175,6 @@ int FUNC(struct kexec_info *info,
>  		dbgprintf_phdr("vmcoreinfo header", phdr);
>  	}
> 
> -	if (has_vmcoreinfo_xen) {
> -		phdr = (PHDR *) bufp;
> -		bufp += sizeof(PHDR);
> -		phdr->p_type	= PT_NOTE;
> -		phdr->p_flags	= 0;
> -		phdr->p_offset  = phdr->p_paddr = vmcoreinfo_addr_xen;
> -		phdr->p_vaddr   = 0;
> -		phdr->p_filesz	= phdr->p_memsz	= vmcoreinfo_len_xen;
> -		/* Do we need any alignment of segments? */
> -		phdr->p_align	= 0;
> -
> -		(elf->e_phnum)++;
> -		dbgprintf_phdr("vmcoreinfo_xen header", phdr);
> -	}
> -
>  	/* Setup an PT_LOAD type program header for the region where
>  	 * Kernel is mapped if elf_info->kern_size is non-zero.
>  	 */
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Dne Po 23. července 2012 14:56:07 Petr Tesarik
napsal(a):
> Dne Čt 5. července 2012 14:16:35 Daniel Kiper napsal(a):
> > vmcoreinfo file could exists under /sys/kernel (valid on baremetal
only)
> > and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > Read only one of them. It means that only one PT_NOTE will be
> > always created. Remove extra code for second PT_NOTE creation.
> 
> Hi Daniel,
> 
> are you absolutely sure this is the right thing to do? IIUC these two
> VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo
> describes the Dom0 kernel (type ''VMCOREINFO''), while the
one from
> /sys/hypervisor describes the Xen hypervisor (type
''XEN_VMCOREINFO''). If
> you keep only the hypervisor note, then e.g. makedumpfile won''t be
able to
> use dumplevel greater than 1, nor will it be able to extract the log
> buffer.
I''ve just verified this, and I''m confident we have to keep
both notes in the
dump file. Simon, please revert Daniel''s patch to avoid regressions.

I''m attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the
difference. Note that the VMCOREINFO_XEN note is actually too big, because Xen 
doesn''t bother to maintain the correct note size in the note header, so
it
always spans a complete page minus sizeof(Elf64_Nhdr)...

Regards,
Petr Tesarik
> Petr Tesarik
> SUSE Linux
> 
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> > ---
> > 
> >  kexec/crashdump-elf.c |   33 +++++++--------------------------
> >  1 files changed, 7 insertions(+), 26 deletions(-)
> > 
> > diff --git a/kexec/crashdump-elf.c b/kexec/crashdump-elf.c
> > index 8d82db9..ec66548 100644
> > --- a/kexec/crashdump-elf.c
> > +++ b/kexec/crashdump-elf.c
> > @@ -40,8 +40,6 @@ int FUNC(struct kexec_info *info,
> > 
> >  	uint64_t notes_addr, notes_len;
> >  	uint64_t vmcoreinfo_addr, vmcoreinfo_len;
> >  	int has_vmcoreinfo = 0;
> > 
> > -	uint64_t vmcoreinfo_addr_xen, vmcoreinfo_len_xen;
> > -	int has_vmcoreinfo_xen = 0;
> > 
> >  	int (*get_note_info)(int cpu, uint64_t *addr, uint64_t *len);
> >  	
> >  	if (xen_present())
> > 
> > @@ -53,16 +51,14 @@ int FUNC(struct kexec_info *info,
> > 
> >  		return -1;
> >  	
> >  	}
> > 
> > -	if (get_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len)
== 0) {
> > -		has_vmcoreinfo = 1;
> > -	}
> > -
> > -	if (xen_present() &&
> > -	    get_xen_vmcoreinfo(&vmcoreinfo_addr_xen,
&vmcoreinfo_len_xen) ==
0)
> > { -		has_vmcoreinfo_xen = 1;
> > -	}
> > +	if (xen_present()) {
> > +		if (!get_xen_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
> > +			has_vmcoreinfo = 1;
> > +	} else
> > +		if (!get_kernel_vmcoreinfo(&vmcoreinfo_addr,
&vmcoreinfo_len))
> > +			has_vmcoreinfo = 1;
> > 
> > -	sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo + has_vmcoreinfo_xen) 
*
> > sizeof(PHDR) + +	sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo) *
> > sizeof(PHDR) +
> > 
> >  	     ranges * sizeof(PHDR);
> >  	
> >  	/*
> > 
> > @@ -179,21 +175,6 @@ int FUNC(struct kexec_info *info,
> > 
> >  		dbgprintf_phdr("vmcoreinfo header", phdr);
> >  	
> >  	}
> > 
> > -	if (has_vmcoreinfo_xen) {
> > -		phdr = (PHDR *) bufp;
> > -		bufp += sizeof(PHDR);
> > -		phdr->p_type	= PT_NOTE;
> > -		phdr->p_flags	= 0;
> > -		phdr->p_offset  = phdr->p_paddr = vmcoreinfo_addr_xen;
> > -		phdr->p_vaddr   = 0;
> > -		phdr->p_filesz	= phdr->p_memsz	= vmcoreinfo_len_xen;
> > -		/* Do we need any alignment of segments? */
> > -		phdr->p_align	= 0;
> > -
> > -		(elf->e_phnum)++;
> > -		dbgprintf_phdr("vmcoreinfo_xen header", phdr);
> > -	}
> > -
> > 
> >  	/* Setup an PT_LOAD type program header for the region where
> >  	
> >  	 * Kernel is mapped if elf_info->kern_size is non-zero.
> >  	 */
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Hi Petr,

On Mon, Jul 23, 2012 at 03:30:55PM +0200, Petr Tesarik
wrote:
> Dne Po 23. ??ervence 2012 14:56:07 Petr Tesarik napsal(a):
> > Dne ??t 5. ??ervence 2012 14:16:35 Daniel Kiper napsal(a):
> > > vmcoreinfo file could exists under /sys/kernel (valid on
baremetal only)
> > > and/or under /sys/hypervisor (valid when Xen dom0 is running).
> > > Read only one of them. It means that only one PT_NOTE will be
> > > always created. Remove extra code for second PT_NOTE creation.
> >
> > Hi Daniel,
> >
> > are you absolutely sure this is the right thing to do? IIUC these two
> > VMCORINFO notes are very different. The one from
/sys/kernel/vmcoreinfo
> > describes the Dom0 kernel (type ''VMCOREINFO''), while
the one from
> > /sys/hypervisor describes the Xen hypervisor (type
''XEN_VMCOREINFO''). If
> > you keep only the hypervisor note, then e.g. makedumpfile
won''t be able to
> > use dumplevel greater than 1, nor will it be able to extract the log
> > buffer.
>
> I''ve just verified this, and I''m confident we have to
keep both notes in the
> dump file. Simon, please revert Daniel''s patch to avoid
regressions.
>
> I''m attaching a sample VMCOREINFO_XEN and VMCOREINFO to
demonstrate the
> difference. Note that the VMCOREINFO_XEN note is actually too big, because
Xen
> doesn''t bother to maintain the correct note size in the note
header, so it
> always spans a complete page minus sizeof(Elf64_Nhdr)...
[...]

The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
physical address. It breaks /proc/vmcore in crash kernel. That is why I proposed
that fix. Additionally, /sys/kernel/vmcoreinfo is not available under Xen Linux
Ver. 2.6.18. However, I did not do any makedumpfile tests. If you discovered any
issues with my patch please drop me more details about your tests (Xen version,
Linux Kernel version, makedumpfile version, command lines, config files, logs,
etc.). I will be more then happy to fix/improve kexec-tools and makedumpfile.

Daniel

Dne Po 23. července 2012 22:10:59 Daniel Kiper
napsal(a):
> Hi Petr,
> 
> On Mon, Jul 23, 2012 at 03:30:55PM +0200, Petr Tesarik wrote:
> > Dne Po 23. ??ervence 2012 14:56:07 Petr Tesarik napsal(a):
> > > Dne ??t 5. ??ervence 2012 14:16:35 Daniel Kiper napsal(a):
> > > > vmcoreinfo file could exists under /sys/kernel (valid on
baremetal
> > > > only) and/or under /sys/hypervisor (valid when Xen dom0 is
running).
> > > > Read only one of them. It means that only one PT_NOTE will
be always
> > > > created. Remove extra code for second PT_NOTE creation.
> > > 
> > > Hi Daniel,
> > > 
> > > are you absolutely sure this is the right thing to do? IIUC these
two
> > > VMCORINFO notes are very different. The one from
/sys/kernel/vmcoreinfo
> > > describes the Dom0 kernel (type 'VMCOREINFO'), while the
one from
> > > /sys/hypervisor describes the Xen hypervisor (type
'XEN_VMCOREINFO').
> > > If you keep only the hypervisor note, then e.g. makedumpfile
won't be
> > > able to use dumplevel greater than 1, nor will it be able to
extract
> > > the log buffer.
> > 
> > I've just verified this, and I'm confident we have to keep
both notes in
> > the dump file. Simon, please revert Daniel's patch to avoid
regressions.
> > 
> > I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to
demonstrate the
> > difference. Note that the VMCOREINFO_XEN note is actually too big,
> > because Xen doesn't bother to maintain the correct note size in
the note
> > header, so it always spans a complete page minus sizeof(Elf64_Nhdr)...
> 
> [...]
> 
> The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid
> physical address. It breaks /proc/vmcore in crash kernel. That is why I
> proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available
> under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests.
> If you discovered any issues with my patch please drop me more details
> about your tests (Xen version, Linux Kernel version, makedumpfile version,
> command lines, config files, logs, etc.). I will be more then happy to
> fix/improve kexec-tools and makedumpfile.
Hi Daniel,

well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the 
VMCOREINFO infrastructure was not present in 2.6.18. It was added later with 
commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.

I tested with the following combinations:

* xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
* xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
* xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0

These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2, 
respectively. All of them work just fine and save both ELF notes into the 
dump.

What do you mean by "invalid physical address"? I'm getting the
correct
physical address under Xen. Obviously, it must be translated to machine 
addresses if you need them from the secondary kernel.

Anyway, let me re-install my test system and send all the necessary 
information. What kind of log files are you interested in?

Petr Tesarik
SUSE Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik
wrote:
> Dne Po 23. ??ervence 2012 22:10:59 Daniel Kiper napsal(a):
> > Hi Petr,
> >
> > On Mon, Jul 23, 2012 at 03:30:55PM +0200, Petr Tesarik wrote:
> > > Dne Po 23. ??ervence 2012 14:56:07 Petr Tesarik napsal(a):
> > > > Dne ??t 5. ??ervence 2012 14:16:35 Daniel Kiper napsal(a):
> > > > > vmcoreinfo file could exists under /sys/kernel (valid
on baremetal
> > > > > only) and/or under /sys/hypervisor (valid when Xen dom0
is running).
> > > > > Read only one of them. It means that only one PT_NOTE
will be always
> > > > > created. Remove extra code for second PT_NOTE creation.
> > > >
> > > > Hi Daniel,
> > > >
> > > > are you absolutely sure this is the right thing to do? IIUC
these two
> > > > VMCORINFO notes are very different. The one from
/sys/kernel/vmcoreinfo
> > > > describes the Dom0 kernel (type
''VMCOREINFO''), while the one from
> > > > /sys/hypervisor describes the Xen hypervisor (type
''XEN_VMCOREINFO'').
> > > > If you keep only the hypervisor note, then e.g. makedumpfile
won''t be
> > > > able to use dumplevel greater than 1, nor will it be able to
extract
> > > > the log buffer.
> > >
> > > I''ve just verified this, and I''m confident we
have to keep both notes in
> > > the dump file. Simon, please revert Daniel''s patch to
avoid regressions.
> > >
> > > I''m attaching a sample VMCOREINFO_XEN and VMCOREINFO to
demonstrate the
> > > difference. Note that the VMCOREINFO_XEN note is actually too
big,
> > > because Xen doesn''t bother to maintain the correct note
size in the note
> > > header, so it always spans a complete page minus
sizeof(Elf64_Nhdr)...
> >
> > [...]
> >
> > The problem with /sys/kernel/vmcoreinfo under Xen is that it expose
invalid
> > physical address. It breaks /proc/vmcore in crash kernel. That is why
I
> > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not
available
> > under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile
tests.
> > If you discovered any issues with my patch please drop me more details
> > about your tests (Xen version, Linux Kernel version, makedumpfile
version,
> > command lines, config files, logs, etc.). I will be more then happy to
> > fix/improve kexec-tools and makedumpfile.
>
> Hi Daniel,
>
> well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because
the
> VMCOREINFO infrastructure was not present in 2.6.18. It was added later
with
Yep.
> commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24.
Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct?
> I tested with the following combinations:
>
> * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1
> * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0
>
> These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> respectively. All of them work just fine and save both ELF notes into the
> dump.
Could you test current kexec-tools development version and
latest makedumpfile version on latest SLES version?
> What do you mean by "invalid physical address"? I''m
getting the correct
> physical address under Xen. Obviously, it must be translated to machine
> addresses if you need them from the secondary kernel.
Correct vmcoreinfo address should be established by calling
HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
Address exposed by /sys/kernel/vmcoreinfo is calculated in other way.
/sys/hypervisor/vmcoreinfo does it correctly (in older implementations
and in my new upstream implementation which I am going to post shortly).
> Anyway, let me re-install my test system and send all the necessary
> information. What kind of log files are you interested in?
If you spot any error in any logfile which in your opinion
is relevent to our testes please send me it.

Daniel

On Tue, Jul 24, 2012 at 03:54:10PM +0200, Daniel Kiper
wrote:
> On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote:
> > Dne Po 23. ??ervence 2012 22:10:59 Daniel Kiper napsal(a):
> > > Hi Petr,
> > >
> > > On Mon, Jul 23, 2012 at 03:30:55PM +0200, Petr Tesarik wrote:
> > > > Dne Po 23. ??ervence 2012 14:56:07 Petr Tesarik napsal(a):
> > > > > Dne ??t 5. ??ervence 2012 14:16:35 Daniel Kiper
napsal(a):
> > > > > > vmcoreinfo file could exists under /sys/kernel
(valid on baremetal
> > > > > > only) and/or under /sys/hypervisor (valid when Xen
dom0 is running).
> > > > > > Read only one of them. It means that only one
PT_NOTE will be always
> > > > > > created. Remove extra code for second PT_NOTE
creation.
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > are you absolutely sure this is the right thing to do?
IIUC these two
> > > > > VMCORINFO notes are very different. The one from
/sys/kernel/vmcoreinfo
> > > > > describes the Dom0 kernel (type
''VMCOREINFO''), while the one from
> > > > > /sys/hypervisor describes the Xen hypervisor (type
''XEN_VMCOREINFO'').
> > > > > If you keep only the hypervisor note, then e.g.
makedumpfile won''t be
> > > > > able to use dumplevel greater than 1, nor will it be
able to extract
> > > > > the log buffer.
> > > >
> > > > I''ve just verified this, and I''m confident
we have to keep both notes in
> > > > the dump file. Simon, please revert Daniel''s patch
to avoid regressions.
> > > >
> > > > I''m attaching a sample VMCOREINFO_XEN and
VMCOREINFO to demonstrate the
> > > > difference. Note that the VMCOREINFO_XEN note is actually
too big,
> > > > because Xen doesn''t bother to maintain the correct
note size in the note
> > > > header, so it always spans a complete page minus
sizeof(Elf64_Nhdr)...
> > >
> > > [...]
> > >
> > > The problem with /sys/kernel/vmcoreinfo under Xen is that it
expose invalid
> > > physical address. It breaks /proc/vmcore in crash kernel. That is
why I
> > > proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not
available
> > > under Xen Linux Ver. 2.6.18. However, I did not do any
makedumpfile tests.
> > > If you discovered any issues with my patch please drop me more
details
> > > about your tests (Xen version, Linux Kernel version, makedumpfile
version,
> > > command lines, config files, logs, etc.). I will be more then
happy to
> > > fix/improve kexec-tools and makedumpfile.
> >
> > Hi Daniel,
> >
> > well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply
because the
> > VMCOREINFO infrastructure was not present in 2.6.18. It was added
later with
> 
> Yep.
> 
> > commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into
2.6.24.
> 
> Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0.
Correct?
> 
> > I tested with the following combinations:
> >
> > * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 +
makedumpfile-1.3.1
> > * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 +
makedumpfile-1.3.1
> > * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 +
makedumpfile-1.4.0
> >
> > These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2,
> > respectively. All of them work just fine and save both ELF notes into
the
> > dump.
> 
> Could you test current kexec-tools development version and
> latest makedumpfile version on latest SLES version?
> 
> > What do you mean by "invalid physical address"? I''m
getting the correct
> > physical address under Xen. Obviously, it must be translated to
machine
> > addresses if you need them from the secondary kernel.
> 
> Correct vmcoreinfo address should be established by calling
> HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO).
> Address exposed by /sys/kernel/vmcoreinfo is calculated in other way.
> /sys/hypervisor/vmcoreinfo does it correctly (in older implementations
> and in my new upstream implementation which I am going to post shortly).
> 
> > Anyway, let me re-install my test system and send all the necessary
> > information. What kind of log files are you interested in?
> 
> If you spot any error in any logfile which in your opinion
> is relevent to our testes please send me it.
Hi,

is there any consensus on what to do here?

Hi Simon,

[...]
> > If you spot any error in any logfile which in your opinion
> > is relevent to our testes please send me it.
>
> Hi,
>
> is there any consensus on what to do here?
As I know Petr was going to do some tests.
I have not received any reply from him till now.
Maybe he is busy or on vacation.

Daniel

Hi,
> > > If you spot any error in any logfile which in your opinion
> > > is relevent to our testes please send me it.
> >
> > Hi,
> >
> > is there any consensus on what to do here?
>
> As I know Petr was going to do some tests.
> I have not received any reply from him till now.
> Maybe he is busy or on vacation.
According to automatic reply he is on vacation until 13/08/2012.

Daniel

On Thu, Aug 02, 2012 at 06:27:24AM -0700, Daniel Kiper
wrote:
> Hi,
> 
> > > > If you spot any error in any logfile which in your opinion
> > > > is relevent to our testes please send me it.
> > >
> > > Hi,
> > >
> > > is there any consensus on what to do here?
> >
> > As I know Petr was going to do some tests.
> > I have not received any reply from him till now.
> > Maybe he is busy or on vacation.
> 
> According to automatic reply he is on vacation until 13/08/2012.
Thanks. I guess we should wait then.

Incidently, I will be on vacation for a week from the 13th.