From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH] Add xentrace/xen_crash. Date: Tue, 15 Oct 2013 12:26:14 -0400 Message-ID: <525D6CA6.3050905@terremark.com> References: <1381759647-29797-1-git-send-email-dslutz@verizon.com> <1381763583.24708.124.camel@kazak.uk.xensource.com> <525D5E59.8030102@terremark.com> <1381852054.21901.44.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7510609271659773723==" Return-path: In-Reply-To: <1381852054.21901.44.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Stefano Stabellini , George Dunlap , Don Slutz , Ian Jackson , Don Slutz , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============7510609271659773723== Content-Type: multipart/alternative; boundary="------------040709020400020407010402" --------------040709020400020407010402 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit 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 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 --------------040709020400020407010402 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
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
--------------040709020400020407010402-- --===============7510609271659773723== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7510609271659773723==--