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

[Dave Anderson <anderson@xxxxxxxxxx>]

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.

Dave



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