<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <tt>Kazuo Moriwaka wrote:</tt> <blockquote TYPE=CITE> <pre>> No surprise here -- there's absolutely no crash utility support for > xendumps of fully-virtualized kernels. > > Much of the information that crash uses to find its way > around a xendump currently depends upon information > *inside* the para-virtualized kernel. In your attempt above, > it needs data structure information for the vcpu_guest_context > structure, in order to get a cr3 value -- which it uses to find the > phys_to_machine_mapping[] array built into the kernel. This headers' vcpu_guest_context.ctrlreg points just a dummy pagetable. (in that file, mfn 12122.) > But obviously there is no phys_to_machine_mapping[] > array in fully-virtualized kernels, so no pseudo-to-physical > address translations can be made. Yes. I read some of code, and now I think this xendump image header doesn't have enough information to find shadow page table. Shadow page table pointed by vcpu.arch.shadow.* in hypervisor, but xendump doesn't have them. If threre is whole-machine dump, converting can be one solution.</pre> </blockquote> <tt>Hi Kazuo,</tt><tt></tt> <tt>Yeah -- I finally got around to tinkering with your example</tt> <tt>FV xendump, and I agree, the cr3 value points to a page of</tt> <tt>zeroes.</tt> <tt>Complicating matters even more, is that you can run x86 FV</tt> <tt>guests on x86_64 xen hosts -- which is what you did. That being</tt> <tt>the case, the xendump header, purportedly of a 32-bit guest,</tt> <tt>uses the x86_64 version of things like the vcpu_guest_context</tt> <tt>structure, and all of the mfn's in the array are 64-bit values</tt> <tt>instead of 32-bit. So when attempting to run crash against</tt> <tt>an x86 kernel with essentially an x86_64 xendump, its bookkeeping</tt> <tt>gets screwed up.</tt> <blockquote TYPE=CITE> <pre><tt>Xen's roadmap says that it will support full-virtualized domain's save/restore in a few months; while supporting them, xendump format will be changed to contain enough info to re-build domain's pseudo-physical memory area. Just waiting for them is one way.</tt></pre> </blockquote> <tt>Doesn't their roadmap call for transitioning from their current</tt> <tt>xendump format to an ELF vmcore format? That certainly would</tt> <tt>be best...</tt><tt></tt> <tt>Thanks,</tt> <tt> Dave</tt> <tt></tt> <tt></tt> </html>