[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