[Crash-utility] crash with Xen image from kdump

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