Re: [Xen-devel] xm dump-core and analyzing

[Dave Anderson <anderson@xxxxxxxxxx>]

Keir Fraser wrote:

> On 11/12/06 15:59, "Dave Anderson" <anderson@xxxxxxxxxx> wrote:
>
> > It does -- at least for para-virtualized x86 and x86_64 xenU kernels that
> > have writeable page tables.  It's not clear to me whether it works on
> > those xenU kernels with shadow page tables -- I have not personally
> > seen it do so since we (Red Hat) ship x86/x86_64 xenU kernels
> > with writeable page tables.
> >
> > With respect to fully-virtualized kernels, it does not work due to the
> > skipping of uninstantiated pseudo-pages in the xendump page list,
> > the issue that John Levon reported here:
>
> Cool! :-)  We'd like to work on this in the Xen-3.0.5 timeframe so the xenU
> dumps use a less brain-dead format (in fact, using Elf would be a good
> idea!). The current format is an ancient, non-extensible and largely
> unmaintained hack; since format compatibility has to be broken we may as
> well fix it properly. I already discussed this a bit with John Levon in the
> email thread you referenced: we should emit an Elf section for each
> contiguous region of (pseudo-physical) address space and then also we will
> need Elf notes for non-shadow-pagetable guests to provide the phys-machine
> relationship.
>

Cool right back at you!

Nothing would make me happier than to see the xendump format
replaced by an ELF format vmcore -- as long as I can make the
p2m translations.

I "get by" now with paravirtualized x86/x86_64 writeable page table kernels
because even though there are holes in the array of mfn's with respect
to their associated pfn's in the xendump file, I can:

(1) take the machine address of the cr3 from the xendump header,
(2) walk the (writeable) page tables to find the "phys_to_machine_mapping" 
symbol,
(3) read what's there, and then re-create the phys_to_machine_mapping[] array 
of the
     dumped kernel.

And from that point on, all p2m translations can be made by looking at that
re-created table for the mfn associated with any pfn, and then looking up
the mfn in the xendump corefile.

But ELF would be a hell of lot nicer...

Note that with Magnus Damm's latest hypervisor/xen0 kexec/kdump "combination"
vmcore format -- which has the additional XEN_ELFNOTE_CRASH_INFO ELF
note containing the dom0 pfn_to_mfn_frame_list_list value-- I can run a crash
session on the vmcore from the xen0 kernel perspective, as in:

 $ crash xen0-vmlinux vmcore

Additionally, Itsuro Oda from VAlinux has also provided a patch so that a crash
session can be run on the xen-syms binary as well, as in:

 $ crash xen-syms vmcore

When that occurs, the crash utility veers off and offers up a different
set of commands appropriate to the hypervisor, i.e., instead of commands
relevant to the vmlinux kernel.

And lastly, from the the xen-syms crash session I can easily find the
pfn_to_mfn_frame_list_list value for any other xenU guest domain,
and then be able to run a crash session on any guest that was
running at the time of the dom0/hypervisor crash:

  $ crash --p2m_mfn <mfn-value> xenU-vmlinux vmcore

Pretty nifty...

Dave




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel