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

[Dave Anderson <anderson@xxxxxxxxxx>]

John Levon wrote:

> On Mon, Dec 11, 2006 at 11:47:25AM -0500, Dave Anderson wrote:
>
> > 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.
>
> Seconded (thirded?). ELF is a perfect format for this since it's
> extendable and naturally understood by the debuggers we all have.
>
> > 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.
>
> How do you know what address that symbol is at? It's a requirement for
> us that the dump is completely stand-alone. Ideally we would get this
> issue fixed for 3.0.4, but I haven't found time to work on the full fix
> that Keir suggested :/

>From the vmlinux file -- the crash utility is invoked similarly to gdb:

  $ crash vmlinux dumpfile

Dave



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