Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1621240 > unrolled thread

Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

Started byJuergen Gross <jgross@suse.com>
First post2017-04-11 14:50 +0200
Last post2017-04-15 16:40 +0200
Articles 7 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in  paddr_vmcoreinfo_note() Juergen Gross <jgross@suse.com> - 2017-04-11 14:50 +0200
    Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in  paddr_vmcoreinfo_note() Daniel Kiper <daniel.kiper@oracle.com> - 2017-04-11 15:10 +0200
      Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in  paddr_vmcoreinfo_note() Petr Tesarik <ptesarik@suse.com> - 2017-04-11 17:00 +0200
        Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in  paddr_vmcoreinfo_note() Daniel Kiper <daniel.kiper@oracle.com> - 2017-04-11 19:30 +0200
          Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in  paddr_vmcoreinfo_note() Petr Tesarik <ptesarik@suse.com> - 2017-04-14 19:00 +0200
            Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in  paddr_vmcoreinfo_note() Daniel Kiper <daniel.kiper@oracle.com> - 2017-04-15 00:30 +0200
              Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in  paddr_vmcoreinfo_note() Petr Tesarik <ptesarik@suse.com> - 2017-04-15 16:40 +0200

#1621240 — Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

FromJuergen Gross <jgross@suse.com>
Date2017-04-11 14:50 +0200
SubjectRe: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()
Message-ID<tv3p8-73W-7@gated-at.bofh.it>
On 03/04/17 14:42, Daniel Kiper wrote:
> On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
>> For kdump to work correctly it needs the physical address of
>> vmcoreinfo_note. When running as dom0 this means the virtual address
>> has to be translated to the related machine address.
>>
>> paddr_vmcoreinfo_note() is meant to do the translation via
>> __pa_symbol() only, but being attributed "weak" it can be replaced
>> easily in Xen case.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Have you tested this patch with latest crash tool? Do dom0 and Xen
> hypervisor analysis work without any issue (at least basic commands
> like dmesg, bt, ps, etc.)? If yes for both you can add:
> 
> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

So can I add your R-b: now?


Juergen

[toc] | [next] | [standalone]

#1621252

FromDaniel Kiper <daniel.kiper@oracle.com>
Date2017-04-11 15:10 +0200
Message-ID<tv3It-7q1-5@gated-at.bofh.it>
In reply to#1621240
On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote:
> On 03/04/17 14:42, Daniel Kiper wrote:
> > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> >> For kdump to work correctly it needs the physical address of
> >> vmcoreinfo_note. When running as dom0 this means the virtual address
> >> has to be translated to the related machine address.
> >>
> >> paddr_vmcoreinfo_note() is meant to do the translation via
> >> __pa_symbol() only, but being attributed "weak" it can be replaced
> >> easily in Xen case.
> >>
> >> Signed-off-by: Juergen Gross <jgross@suse.com>
> >
> > Have you tested this patch with latest crash tool? Do dom0 and Xen
> > hypervisor analysis work without any issue (at least basic commands
> > like dmesg, bt, ps, etc.)? If yes for both you can add:
> >
> > Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
>
> So can I add your R-b: now?

My R-b is still valid. Though, let's wait for Petr's Tested-by. He
did makedumpfile tests but I asked him to do crash tool tests too.
I think it is important.

Daniel

[toc] | [prev] | [next] | [standalone]

#1621390

FromPetr Tesarik <ptesarik@suse.com>
Date2017-04-11 17:00 +0200
Message-ID<tv5qV-8me-9@gated-at.bofh.it>
In reply to#1621252
On Tue, 11 Apr 2017 15:00:58 +0200
Daniel Kiper <daniel.kiper@oracle.com> wrote:

> On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote:
> > On 03/04/17 14:42, Daniel Kiper wrote:
> > > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> > >> For kdump to work correctly it needs the physical address of
> > >> vmcoreinfo_note. When running as dom0 this means the virtual address
> > >> has to be translated to the related machine address.
> > >>
> > >> paddr_vmcoreinfo_note() is meant to do the translation via
> > >> __pa_symbol() only, but being attributed "weak" it can be replaced
> > >> easily in Xen case.
> > >>
> > >> Signed-off-by: Juergen Gross <jgross@suse.com>
> > >
> > > Have you tested this patch with latest crash tool? Do dom0 and Xen
> > > hypervisor analysis work without any issue (at least basic commands
> > > like dmesg, bt, ps, etc.)? If yes for both you can add:
> > >
> > > Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
> >
> > So can I add your R-b: now?
> 
> My R-b is still valid. Though, let's wait for Petr's Tested-by. He
> did makedumpfile tests but I asked him to do crash tool tests too.
> I think it is important.

Tested-by: Petr Tesarik <ptesarik@suse.com>

I copied the complete /proc/vmcore to a directory on disk. Exactly
as expected, crash works both without the patch and with the patch, as
it does not use VMCOREINFO at all (instead, crash obtains the
information from kernel debuginfo directly).

Without the patch:

morricone:/abuild/dumps/2017-04-11-16:38/:[0]# crash vmlinux vmcore 

crash 7.1.8
Copyright (C) 2002-2016  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.
 
crash: vmlinux: no .gnu_debuglink section
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...

      KERNEL: vmlinux                           
    DUMPFILE: vmcore
        CPUS: 12 [OFFLINE: 11]
        DATE: Tue Apr 11 16:37:34 2017
      UPTIME: 00:11:51
LOAD AVERAGE: 0.04, 0.08, 0.08
       TASKS: 269
    NODENAME: morricone
     RELEASE: 4.11.0-rc5-default-pt+
     VERSION: #1 SMP PREEMPT Thu Apr 6 17:40:53 CEST 2017
     MACHINE: x86_64  (2400 Mhz)
      MEMORY: 16 GB
       PANIC: "sysrq: SysRq : Trigger a crash"
         PID: 12009
     COMMAND: "bash"
        TASK: ffff8804065d2080  [THREAD_INFO: ffff8804065d2080]
         CPU: 7
       STATE: TASK_RUNNING (SYSRQ)

crash> 


With the patch included:

morricone:/abuild/dumps/2017-04-11-12:52/:[0]# crash vmlinux vmcore  

crash 7.1.8
Copyright (C) 2002-2016  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.
 
crash: vmlinux: no .gnu_debuglink section
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...

      KERNEL: vmlinux                           
    DUMPFILE: vmcore
        CPUS: 12 [OFFLINE: 11]
        DATE: Tue Apr 11 12:51:15 2017
      UPTIME: 4 days, 01:31:42
LOAD AVERAGE: 0.04, 0.01, 0.00
       TASKS: 634
    NODENAME: morricone
     RELEASE: 4.11.0-rc5-default-pt+
     VERSION: #2 SMP PREEMPT Fri Apr 7 09:34:10 CEST 2017
     MACHINE: x86_64  (2400 Mhz)
      MEMORY: 16 GB
       PANIC: "sysrq: SysRq : Trigger a crash"
         PID: 19503
     COMMAND: "bash"
        TASK: ffff8803367762c0  [THREAD_INFO: ffff8803367762c0]
         CPU: 3
       STATE: TASK_RUNNING (SYSRQ)

crash> 

Petr T

[toc] | [prev] | [next] | [standalone]

#1621492

FromDaniel Kiper <daniel.kiper@oracle.com>
Date2017-04-11 19:30 +0200
Message-ID<tv7M6-1zf-29@gated-at.bofh.it>
In reply to#1621390
On Tue, Apr 11, 2017 at 04:59:16PM +0200, Petr Tesarik wrote:
> On Tue, 11 Apr 2017 15:00:58 +0200
> Daniel Kiper <daniel.kiper@oracle.com> wrote:
>
> > On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote:
> > > On 03/04/17 14:42, Daniel Kiper wrote:
> > > > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> > > >> For kdump to work correctly it needs the physical address of
> > > >> vmcoreinfo_note. When running as dom0 this means the virtual address
> > > >> has to be translated to the related machine address.
> > > >>
> > > >> paddr_vmcoreinfo_note() is meant to do the translation via
> > > >> __pa_symbol() only, but being attributed "weak" it can be replaced
> > > >> easily in Xen case.
> > > >>
> > > >> Signed-off-by: Juergen Gross <jgross@suse.com>
> > > >
> > > > Have you tested this patch with latest crash tool? Do dom0 and Xen
> > > > hypervisor analysis work without any issue (at least basic commands
> > > > like dmesg, bt, ps, etc.)? If yes for both you can add:
> > > >
> > > > Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
> > >
> > > So can I add your R-b: now?
> >
> > My R-b is still valid. Though, let's wait for Petr's Tested-by. He
> > did makedumpfile tests but I asked him to do crash tool tests too.
> > I think it is important.
>
> Tested-by: Petr Tesarik <ptesarik@suse.com>
>
> I copied the complete /proc/vmcore to a directory on disk. Exactly
> as expected, crash works both without the patch and with the patch, as
> it does not use VMCOREINFO at all (instead, crash obtains the
> information from kernel debuginfo directly).

Thanks for doing the tests. I suppose that you have tested HVM guests.
IIRC, PV guests are not supported by crash right now due to p2m VMA
mapping. At least it was an issue some time ago. Is it still valid?
Anyway, one guy in Oracle works on fix for that issue and I do review.
We are going to post it in 2-3 weeks.

Juergen, I do not have any objections any longer. You can go ahead.
Ahhh... I see. You have posted v3. Good!

Daniel

[toc] | [prev] | [next] | [standalone]

#1623776

FromPetr Tesarik <ptesarik@suse.com>
Date2017-04-14 19:00 +0200
Message-ID<twcJH-3tb-1@gated-at.bofh.it>
In reply to#1621492
On Tue, 11 Apr 2017 19:20:08 +0200
Daniel Kiper <daniel.kiper@oracle.com> wrote:

> On Tue, Apr 11, 2017 at 04:59:16PM +0200, Petr Tesarik wrote:
>[...]
> > Tested-by: Petr Tesarik <ptesarik@suse.com>
> >
> > I copied the complete /proc/vmcore to a directory on disk. Exactly
> > as expected, crash works both without the patch and with the patch, as
> > it does not use VMCOREINFO at all (instead, crash obtains the
> > information from kernel debuginfo directly).
> 
> Thanks for doing the tests. I suppose that you have tested HVM guests.

Not really. I crashed Dom0, which is in turn sent to the hypervisor, so
the result is a complete host dump, including Xen hypervisor data and
all domains.

> IIRC, PV guests are not supported by crash right now due to p2m VMA
> mapping. At least it was an issue some time ago. Is it still valid?

Yes, this is correct. I tested this behaviour a few weeks ago.

> Anyway, one guy in Oracle works on fix for that issue and I do review.
> We are going to post it in 2-3 weeks.

All right. FYI I do not plan to put much effort into it, as my focus has
shifted towards libkdumpfile (https://github.com/ptesarik/libkdumpfile),
and this library can open PV guest dump files without any issues.

Petr T

[toc] | [prev] | [next] | [standalone]

#1623935

FromDaniel Kiper <daniel.kiper@oracle.com>
Date2017-04-15 00:30 +0200
Message-ID<twhT3-6QO-1@gated-at.bofh.it>
In reply to#1623776
On Fri, Apr 14, 2017 at 06:53:36PM +0200, Petr Tesarik wrote:
> On Tue, 11 Apr 2017 19:20:08 +0200
> Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > On Tue, Apr 11, 2017 at 04:59:16PM +0200, Petr Tesarik wrote:
> >[...]
> > > Tested-by: Petr Tesarik <ptesarik@suse.com>
> > >
> > > I copied the complete /proc/vmcore to a directory on disk. Exactly
> > > as expected, crash works both without the patch and with the patch, as
> > > it does not use VMCOREINFO at all (instead, crash obtains the
> > > information from kernel debuginfo directly).
> >
> > Thanks for doing the tests. I suppose that you have tested HVM guests.
>
> Not really. I crashed Dom0, which is in turn sent to the hypervisor, so
> the result is a complete host dump, including Xen hypervisor data and
> all domains.

OK.

> > IIRC, PV guests are not supported by crash right now due to p2m VMA
> > mapping. At least it was an issue some time ago. Is it still valid?
>
> Yes, this is correct. I tested this behaviour a few weeks ago.

Thanks for update.

> > Anyway, one guy in Oracle works on fix for that issue and I do review.
> > We are going to post it in 2-3 weeks.
>
> All right. FYI I do not plan to put much effort into it, as my focus has

OK.

> shifted towards libkdumpfile (https://github.com/ptesarik/libkdumpfile),
> and this library can open PV guest dump files without any issues.

Great! AIUI, it reminds my idea to make such think. However, I have not
have time to make it happen. Is it based on makedumpfile or written from
scratch? Do you plan support for Linux kernel dumps and/or Xen ones?

Daniel

[toc] | [prev] | [next] | [standalone]

#1624077

FromPetr Tesarik <ptesarik@suse.com>
Date2017-04-15 16:40 +0200
Message-ID<twx1L-7H3-1@gated-at.bofh.it>
In reply to#1623935
On Sat, 15 Apr 2017 00:26:05 +0200
Daniel Kiper <daniel.kiper@oracle.com> wrote:

> On Fri, Apr 14, 2017 at 06:53:36PM +0200, Petr Tesarik wrote:
>[...]
> > shifted towards libkdumpfile (https://github.com/ptesarik/libkdumpfile),
> > and this library can open PV guest dump files without any issues.
> 
> Great! AIUI, it reminds my idea to make such think. However, I have not
> have time to make it happen. Is it based on makedumpfile or written from
> scratch? Do you plan support for Linux kernel dumps and/or Xen ones?

Some ideas are borrowed from existing tools (makedumpfile, crash). All
code is written from scratch, however.

The kdumpfile library itself is designed for use with any platform and
operating system. Xen is treated as just another type of operating
system. Based on which OS type is initialized, the library is able to
provide a hypervisor view or a Dom0 view.

There is another project led by Jeff Mahoney, which extends standard
gdb with semantic commands. This project supports only x86_64 Linux
right now. See https://github.com/jeffmahoney/crash-python.

Petr T

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web