Re: [PATCH] Add xentrace/xen_crash.

[Don Slutz <dslutz@verizon.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3474 bytes --]

On 10/15/13 11:47, Ian Campbell wrote:
> On Tue, 2013-10-15 at 11:25 -0400, Don Slutz wrote:
>>> Is this some protocol defined by crash? Can you include a reference to
>>> their specification somewhere please. Is it intended for consumption
>>> externally to the crash tools -- i.e. is it a stable protocol? (it
>>> smells a bit ad-hoc is why I'm asking).
>> So far I have not found a specification. Will keep looking.  I had
>> assumed it was, will work with the crash tools person to see.
> Thanks.
>
>>> If it's not intended to be consumed like this perhaps the tool would be
>>> better off living in the crash source base?
>> Maybe.  Since this has code that needs the XEN headers and crash is
>> currently one program with extension modules, it does not fit as well there.
> I had it in my mind that crash already had some level of Xen support and
> therefore already dependended on the headers. I don't know why I think
> that so it may be a fantasy.
Crash does have support for XEN crash dumps.  I do not think it supports 
live access to the hypervisor (crash live on dom0 allows you to look at 
dom0, not the hypervisor).  Most of the data structures are fetched out 
of the debug info in ELF files.  So to build crash, xen does not need to 
be installed.

For example:

    dcs-xen-50:~/dump2>crash vmcore xenrpm/boot/xen-syms-4.2.2

    crash 6.1.4
    Copyright (C) 2002-2013  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.

    GNU gdb (GDB) 7.3.1
    Copyright (C) 2011 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: xenrpm/boot/xen-syms-4.2.2
      DUMPFILE: vmcore
          CPUS: 8
       DOMAINS: 5
        UPTIME: --:--:--
       MACHINE: Intel(R) Xeon(R) CPU E31265L @ 2.40GHz  (2400 Mhz)
        MEMORY: 32 GB
       PCPU-ID: 0
          PCPU: ffff82c4802bff18
       VCPU-ID: 0
          VCPU: ffff8300bf2fa000  (VCPU_RUNNING)
    DOMAIN-ID: 0
        DOMAIN: ffff830823fb6000  (DOMAIN_RUNNING)
         STATE: CRASH

    crash> quit


> Don't these extension modules have all sorts of random dependencies? In
> which case adding the Xen ones doesn't seem too horrible, assuming they
> are smart enough to only enable the ones whose dependencies are
> available.
I think that they do, but not sure.  The ones I have looked at are ways 
to process the data in a dump in a more easy way for a user to use.

Since this is changing the way that crash gets to the data, I know of no 
way to do it as an extension module.
> Ian.
>
   -Don Slutz

[-- Attachment #1.2: Type: text/html, Size: 5685 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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