Kazuo Moriwaka wrote: > > 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. >
Hi Kazuo, Yeah -- I finally got around to tinkering with your example FV xendump, and I agree, the cr3 value points to a page of zeroes. Complicating matters even more, is that you can run x86 FV guests on x86_64 xen hosts -- which is what you did. That being the case, the xendump header, purportedly of a 32-bit guest, uses the x86_64 version of things like the vcpu_guest_context structure, and all of the mfn's in the array are 64-bit values instead of 32-bit. So when attempting to run crash against an x86 kernel with essentially an x86_64 xendump, its bookkeeping gets screwed up. > 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. > Doesn't their roadmap call for transitioning from their current xendump format to an ELF vmcore format? That certainly would be best... Thanks, Dave
-- Crash-utility mailing list [email protected] https://www.redhat.com/mailman/listinfo/crash-utility
