Re: [Xen-devel] [PATCH 00/04] Kexec / Kdump: Release 20061122 (xen-unstable-12502)

["Magnus Damm" <magnus.damm@xxxxxxxxx>]

On 11/29/06, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> On Wed, 2006-11-29 at 11:35 +0900, Magnus Damm wrote:
> > On 11/28/06, Dave Anderson <anderson@xxxxxxxxxx> wrote:
> > > Magnus Damm wrote:
> > >
> > > > On 11/28/06, Dave Anderson <anderson@xxxxxxxxxx> wrote:
> > > > > Magnus Damm wrote:
> > > > > > I thought that pointing out pfn_to_mfn_frame_list_list for dom0 was a
> > > > > > better, more portable way to provide Dave with this info than just
> > > > > > handing out CR3.
> > > > > >
> > > > >
> > > > > That's correct.  With this simple additional note, it will be possible
> > > > > to do any of the following:
> > > > >
> > > > >   $ crash vmlinux vmcore       (with the NT_XEN_KDUMP_CR3 note)
> > > > >   $ crash xen-syms vmcore    (with the new "xencrash" patch)
> > > > >   $ gdb xen-syms vmcore
> > > > >
> > > > > I had originally suggested an array of pfn_to_mfn_frame_list_list 
> values,
> > > > > one for each guest domain, in which case you could execute crash
> > > > > sessions for dom0 or any of the guest domains.
> > > > >
> > > > > And now with the new xencrash patch, the crash utility can also
> > > > > be run against the xen-syms binary, which means that the session
> > > > > will be run from the perspective of the hypervisor binary, i.e., with 
> its
> > > > > own set of hypervisor-specific commands.
> > > > >
> > > > > Anyway, we compromised on just the dom0 pfn_to_mfn_frame_list_list
> > > > > value, given that in the majority of dom0/hypervisor crashes, the cause
> > > > > of the crash will most likely be in the dom0 kernel code.
> > > >
> > > > Thanks for the comments! The value for NT_XEN_KDUMP_CR3, do you have
> > > > any strong feelings to keep that? We have an unique string now, so I'm
> > > > tempted to just set it to 0...
> > > >
> > >
> > > Obviously as long as it doesn't clash with the NT_XXX type #define's in 
> elf.h,
> > > it's OK.  For diskdump vmcores, they created an un-clashable NT_DISKDUMP
> > > type value of 0x70000001, and so the use of 0x10000001 for NT_XEN_KDUMP_CR3
> > > apparently followed that model.  But, since you're asking, I don't 
> particularly
> > > like the use of 0; it just seems too ambiguous.
> >
> > Hm... But doesn't both the string and the type together form an unique
> > identifier?
>
> That's correct. The type of a note only has to be unique vs notes with
> the same name field. So since the Xen notes have name "XEN CORE" they
> can't clash with the notes in elf.h which have name "CORE".
>
> If you wanted to you could use a bit of the existing "Xen" namespace. It
> is currently only used by notes which are consumed by the domain
> builder. They are defined in xen/include/public/elfnote.h.
Sounds like a good idea. What about:

#define XEN_ELFNOTE_CRASH_INFO 13 /* system information */
#define XEN_ELFNOTE_CRASH_REGS 14 /* per-cpu system registers */

The types will map to data structures instead of single numeric values
or strings though, but maybe that is ok.

Thanks,

/ magnus

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