<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body>
Horms wrote:<br>
<blockquote type="cite" cite="mid20060624055741.GD11138@verge.net.au">
<pre wrap="">On Fri, Jun 23, 2006 at 12:11:50PM -0400, Dave Anderson wrote:<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I added some code to kdump to have it record CR3 for dom0. This is<br>done using a second note in the per-cpu notes area, which for now<br>just stores a single 4byte entity, the mfn of that CPU in dom0<br>if it was present in dom0.<br><br>I have made a dump available that includes this. The tarball<br>also includes the kernels, xen, symbol files, and patches to xen.<br>If you want to find the cr3 saving code its in ./arch/x86/crash.c<br><br>I plan to post this update to xen-devel shortly, hopefully tomorrow,<br>after upporting to the latest xen tree (I'm still working off about<br>3 weeks ago's tree).<br><br><a class="moz-txt-link-freetext" href="http://packages.vergenet.net/tmp/xen-unstable.hg+kexec-20060616.tar.bz2">http://packages.vergenet.net/tmp/xen-unstable.hg+kexec-20060616.tar.bz2</a><br></pre>
</blockquote>
<pre wrap="">OK -- here's a proof-of-concept running the dom0 vmlinux against the<br>xen kdump:<br><br> # crash vmlinux vmcore<br><br> crash 4.0-2.31-rc1<br> Copyright (C) 2002, 2003, 2004, 2005, 2006 Red Hat, Inc.<br> Copyright (C) 2004, 2005, 2006 IBM Corporation<br> Copyright (C) 1999-2006 Hewlett-Packard Co<br> Copyright (C) 2005 Fujitsu Limited<br> Copyright (C) 2005 NEC Corporation<br> Copyright (C) 1999, 2002 Silicon Graphics, Inc.<br> Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.<br> This program is free software, covered by the GNU General Public License,<br> and you are welcome to change it and/or distribute copies of it under<br> certain conditions. Enter "help copying" to see the conditions.<br> This program has absolutely no warranty. Enter "help warranty" for details.<br><br> GNU gdb 6.1<br> Copyright 2004 Free Software Foundation, Inc.<br> GDB is free software, covered by the GNU General Public License, and you a
re<br> welcome to change it and/or distribute copies of it under certain conditions.<br> Type "show copying" to see the conditions.<br> There is absolutely no warranty for GDB. Type "show warranty" for details.<br> This GDB was configured as "i686-pc-linux-gnu"...<br><br> KERNEL: vmlinux<br> DUMPFILE: vmcore<br> CPUS: 2<br> DATE: Wed Jun 14 15:05:01 2006<br> UPTIME: 00:04:40<br> LOAD AVERAGE: 1.22, 0.39, 0.13<br> TASKS: 94<br> NODENAME: aiko.lab.ultramonkey.org<br> RELEASE: 2.6.16.13-xen<br> VERSION: #7 SMP Fri Jun 9 16:25:32 JST 2006<br> MACHINE: i686 (866 Mhz)<br> MEMORY: 887.4 MB<br> PANIC: "SysRq : Trigger a crashdump"<br> PID: 3949<br> COMMAND: "do_kdump"<br> TASK: f3e64030 [THREAD_INFO: f3dba000]<br> CPU: 1<br> STATE: TASK_RUNNING (SYSRQ)<br><br> crash> bt -a<br> PID: 0 TASK: c02ce460 CPU: 0 COMMAND: "swapper"<br> #0 [c030f
f34] schedule at c028e648<br> #1 [c030ffb0] cpu_idle at c0103e9f<br><br> PID: 3949 TASK: f3e64030 CPU: 1 COMMAND: "do_kdump"<br> #0 [f3dbbed8] crash_kexec at c0140c45<br> #1 [f3dbbf28] __handle_sysrq at c01f54e4<br> #2 [f3dbbf54] write_sysrq_trigger at c019cbff<br> #3 [f3dbbf6c] vfs_write at c0168dbf<br> #4 [f3dbbf90] sys_write at c0169736<br> #5 [f3dbbfb8] system_call at c0105542<br> EAX: 00000004 EBX: 00000001 ECX: 080f8408 EDX: 00000002<br> DS: 007b ESI: 00000002 ES: 007b EDI: b7f007c0<br> SS: 007b ESP: bfb5ffc8 EBP: bfb5ffe4<br> CS: 0073 EIP: b7e93028 ERR: 00000004 EFLAGS: 00000246<br> crash><br><br>As I discussed earlier, given that this is a writable-page-table<br>kernel, having any legitimate CR3 (I just use the first one found<br>in the ELF header), I first get the value of "max_pfn" (x86),<br>and then the value of "phys_to_machine_mapping", which makes up<br>dom0's "phys_to_machine_mapping[max
_pfn]" array. From that, all<br>subsequent pseudo-physical address requests can be translated<br>into the physical address for the existing read_netdump() function<br>to access. As we talked about before, this won't work for<br>shadow-page-table kernels; for those I would need to having the<br>"pfn_to_mfn_frame_list_list" mfn value from the shared,<br>per-domain, "arch_shared_info" structure(s). With that single<br>value, the phys_to_machine_mapping[] array can be resurrected<br>for both writable- and shadow-page-table kernels.<br><br>Also, with either the cr3 or pfn_to_mfn_frame_list_list schemes,<br>if those values were made available for *all* of the other domains<br>instead of just dom0, then we could run a crash session against<br>any of the domains on the system.<br></pre>
</blockquote>
<pre wrap=""><!----><br>As we now have a whole extra crash note devoted to storing cr3 and only<br>cr3 it would be trivial to put pfn_to_mfn_frame_list_list in there as<br>well. Would that be sufficient? Would you need information about what<br>paging scheme was in effect in there as well. We have roughly 800 bytes<br>of unused crash note space, so adding a few extra values should be no<br>problem whatsoever.</pre>
</blockquote>
<br>
<tt>I don't have a strong opinion either way. You could leave the 0x10000001
note<br>
definition to mean this is a "writable-page-table cr3", and perhaps 0x10000002<br>
to pass a "writable-page-table pfn_to_mfn_frame_list_list" and 0x10000003
to<br>
pass a "shadow-page-table pfn_to_mfn_frame_list_list". Or whatever, I don't<br>
really care one way or another, just that the information gets passed in
one <br>
manner or another. Given that I've got the cr3 support in place, it would
be<br>
nice to leave it as one option for bootstrapping the whole deal. But also,
<br>
in the meantime, I can start work on the "pfn_to_mfn_frame_list_list" option<br>
by simply kludging its mfn value in place of the cr3 mfn with the vmcore
I've been<br>
working with. (I think...)<br>
<br>
But we will need to know whether the kernel is writable- or shadow-page-table<br>
enabled, and I suppose that would be helpful in the ELF header if there is
no<br>
way to tell by simply looking at the vmcore's symbols for clues. At this
point,<br>
I'm just defaulting to writable-page-table support, and to get shadow-page-table<br>
support I've added a command line switch. But I would think there should
be some<br>
kind of clue in the vmcore, for example, a symbol that does or doesn't exist
depending<br>
upon which scheme is being used, that should make its detection automatic.<br>
We (Red Hat) are only using writable-page-table kernels at the moment, so<br>
I really haven't looked into it. With your vmcores, we do have the liberty
of being<br>
able to pass that information in the ELF header. On the other hand, that
info<br>
is probably not readily available in guest xendump or guest "xm save" output<br>
files, so again, I'd like to be able to figure it out some other way.</tt><br>
<blockquote type="cite" cite="mid20060624055741.GD11138@verge.net.au">
<pre wrap=""><br><br></pre>
<blockquote type="cite">
<pre wrap="">In any case, this is pretty cool for starters...<br></pre>
</blockquote>
<pre wrap=""><!----><br>Indeed it is, and the info you have above does seem to be correct.<br>Off the top of my head anyway.<br><br></pre>
<blockquote type="cite">
<pre wrap="">BTW, I've created a new n_type value to handle this particular<br>invocation, which I understand will be subject to change.<br>Note that the spelling in your PT_NOTE is a bit strange:<br><br> crash> help -n<br> ...<br> Elf32_Nhdr:<br> n_namesz: 18 ("Xen Domanin-0 CR3")<br> n_descsz: 4<br> n_type: 10000001 (NT_XEN_KDUMP_CR3)<br> 00027227<br> ...<br> crash><br><br>Anyway, I'll do the same thing for x86_64 (untested) and<br>update the crash release so you'll have something to work<br>with.<br></pre>
</blockquote>
<pre wrap=""><!----><br>Cool. I'd offer you an x86_64 vmcore, but we actually haven't<br>sucessfully kdumped x86_64 xen yet. The code should work, but...<br>This may well relate to linux x86_64 kdump being generally flakey<br>and highly cpu rev dependant. We are hoping to investigate this<br>in the not to distant future.<br><br>In any case, I can give you a vmlinux, xen and the works if you like.<br>And the x86_64 are included in the the tarball you already have<br>with the vmcore you used above. Mmm, actually, they might be slightly<br>old, let me know if you want the lastest and greatest. But at any<br>rate, it doesn't quite work :(<br><br></pre>
</blockquote>
<br>
<tt>No, I'll wait for you to get it to work...<br>
<br>
Thanks,<br>
Dave<br>
</tt><br>
<br>
<br>
</body>
</html>