> 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