WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] xm dump-core and analyzing
From: Dave Anderson <anderson@xxxxxxxxxx>
Date: Mon, 11 Dec 2006 11:47:25 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 11 Dec 2006 08:46:31 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C1A33376.5DC4%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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