[Crash-utility] xendump image with full-vitualized domain
Dave Anderson
anderson at redhat.com
Thu Nov 16 20:24:27 UTC 2006
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20061116/3367c432/attachment.htm>
More information about the Crash-utility
mailing list