| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] xm dump-core and analyzing
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
|
|
|
| |
|
Home