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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

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.

Ian.



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