[Crash-utility] crash with Xen image from kdump

[Dave Anderson]

> I added some code to kdump to have it record CR3 for dom0. This is
> done using a second note in the per-cpu notes area, which for now
> just stores a single 4byte entity, the mfn of that CPU in dom0
> if it was present in dom0.
>
> I have made a dump available that includes this. The tarball
> also includes the kernels, xen, symbol files, and patches to xen.
> If you want to find the cr3 saving code its in ./arch/x86/crash.c
>
> I plan to post this update to xen-devel shortly, hopefully tomorrow,
> after upporting to the latest xen tree (I'm still working off about
> 3 weeks ago's tree).
>
> http://packages.vergenet.net/tmp/xen-unstable.hg+kexec-20060616.tar.bz2

OK -- here's a proof-of-concept running the dom0 vmlinux against the
xen kdump:

  # crash vmlinux vmcore

  crash 4.0-2.31-rc1
  Copyright (C) 2002, 2003, 2004, 2005, 2006  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005  Fujitsu Limited
  Copyright (C) 2005  NEC Corporation
  Copyright (C) 1999, 2002  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 6.1
  Copyright 2004 Free Software Foundation, Inc.
  GDB 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.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for details.
  This GDB was configured as "i686-pc-linux-gnu"...

        KERNEL: vmlinux
      DUMPFILE: vmcore
          CPUS: 2
          DATE: Wed Jun 14 15:05:01 2006
        UPTIME: 00:04:40
  LOAD AVERAGE: 1.22, 0.39, 0.13
         TASKS: 94
      NODENAME: aiko.lab.ultramonkey.org
       RELEASE: 2.6.16.13-xen
       VERSION: #7 SMP Fri Jun 9 16:25:32 JST 2006
       MACHINE: i686  (866 Mhz)
        MEMORY: 887.4 MB
         PANIC: "SysRq : Trigger a crashdump"
           PID: 3949
       COMMAND: "do_kdump"
          TASK: f3e64030  [THREAD_INFO: f3dba000]
           CPU: 1
         STATE: TASK_RUNNING (SYSRQ)

  crash> bt -a
  PID: 0      TASK: c02ce460  CPU: 0   COMMAND: "swapper"
   #0 [c030ff34] schedule at c028e648
   #1 [c030ffb0] cpu_idle at c0103e9f

  PID: 3949   TASK: f3e64030  CPU: 1   COMMAND: "do_kdump"
   #0 [f3dbbed8] crash_kexec at c0140c45
   #1 [f3dbbf28] __handle_sysrq at c01f54e4
   #2 [f3dbbf54] write_sysrq_trigger at c019cbff
   #3 [f3dbbf6c] vfs_write at c0168dbf
   #4 [f3dbbf90] sys_write at c0169736
   #5 [f3dbbfb8] system_call at c0105542
      EAX: 00000004  EBX: 00000001  ECX: 080f8408  EDX: 00000002
      DS:  007b      ESI: 00000002  ES:  007b      EDI: b7f007c0
      SS:  007b      ESP: bfb5ffc8  EBP: bfb5ffe4
      CS:  0073      EIP: b7e93028  ERR: 00000004  EFLAGS: 00000246
  crash>

As I discussed earlier, given that this is a writable-page-table
kernel, having any legitimate CR3 (I just use the first one found
in the ELF header), I first get the value of "max_pfn" (x86),
and then the value of "phys_to_machine_mapping", which makes up
dom0's "phys_to_machine_mapping[max_pfn]" array.  From that, all
subsequent pseudo-physical address requests can be translated
into the physical address for the existing read_netdump() function
to access.  As we talked about before, this won't work for
shadow-page-table kernels; for those I would need to having the
"pfn_to_mfn_frame_list_list" mfn value from the shared,
per-domain, "arch_shared_info" structure(s).  With that single
value, the phys_to_machine_mapping[] array can be resurrected
for both writable- and shadow-page-table kernels.

Also, with either the cr3 or pfn_to_mfn_frame_list_list schemes,
if those values were made available for *all* of the other domains
instead of just dom0, then we could run a crash session against
any of the domains on the system.

In any case, this is pretty cool for starters...

BTW, I've created a new n_type value to handle this particular
invocation, which I understand will be subject to change.
Note that the spelling in your PT_NOTE is a bit strange:

  crash> help -n
  ...
  Elf32_Nhdr:
                 n_namesz: 18 ("Xen Domanin-0 CR3")
                 n_descsz: 4
                   n_type: 10000001 (NT_XEN_KDUMP_CR3)
                           00027227
  ...
  crash>

Anyway, I'll do the same thing for x86_64 (untested) and
update the crash release so you'll have something to work
with.

Thanks,
  Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20060623/fb83b162/attachment.htm>