[Crash-utility] xendump image with full-vitualized domain
Kazuo Moriwaka
moriwaka at valinux.co.jp
Tue Nov 14 06:33:12 UTC 2006
From: Dave Anderson <anderson at redhat.com>
Subject: Re: [Crash-utility] xendump image with full-vitualized domain
Date: Mon, 13 Nov 2006 09:36:38 -0500
> Kazuo Moriwaka wrote:
>
> > Hi,
> >
> > I tried to analise full-virtualized domain's dump image with crash.
> > It abortes with following message.
> >
> > $ crash System.map-2.6.8-2-386 vmlinux-2.6.8-2-386 2006-1110-1141.38-guest2.4.core
> > (snip)
> > crash: cannot determine vcpu_guest_context.ctrlreg offset
> >
> > Full-virtualized domain's kernel doeesn't have any information about
> > xen-hypervisor, it also doesn't have struct vcpu_guest_context.
> > I'll put kernels and xendump core files at following for reference.
> >
> > http://people.valinux.co.jp/~moriwaka/domUcore/
> > host.tar.gz - xen hypervisor and dom0 kernel(for amd64)
> > full-virtualized-guest.tar.gz - domU kernel(for i386) and dump image
> > taken by 'xm dump-core' command.
> >
> > any ideas?
>
> 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.
> I'm not sure what the best solution is for fully-virtualized
> kernels.
>
> Perhaps what is needed is yet another tool that takes
> a xendump of a fully-virtualized kernel, and turns it into
> a recognizable vmcore?
>
> Whatever it is, an alternative manner of translating the
> "physical" addresses in the fully-virtualized kernel (which
> become pseudo-physical addresses in the xen environment)
> and find them in the xendump.
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.
--
Kazuo Moriwaka <moriwaka at valinux.co.jp>
More information about the Crash-utility
mailing list