Re: [Xen-devel] [PATCH] Add xentrace/xen_crash.

[Don Slutz <dslutz@xxxxxxxxxxx>]

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

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