[Crash-utility] kdump format may be updated

[Magnus Damm]

Hi Dave,

Thanks for your comments!

On Wed, 2006-10-18 at 10:49 -0400, Dave Anderson wrote:
> Kazuo Moriwaka wrote:
> 
> > Hello,
> >
> > From: Dave Anderson <anderson at redhat.com>
> > Subject: Re: [Crash-utility] kdump format may be updated
> > Date: Tue, 17 Oct 2006 09:01:32 -0400
> >
> > > As we discussed before, it would have been preferable in my
> > > opinion to have the starting-point mfn value for all the domains,
> > > thereby making the dumpfile usable for all domains instead of
> > > just dom0.  But I will be happy with at least getting this change
> > > in place so that crash can be used directly on the xen dumpfile
> > > for dom0 analysis without having to run it through some other
> > > utility.
> >
> > Yes, I remember the discussion and I think it is possible to make headers.
> > Now, Magnus is cleaning the patch.  He and I discussed, but I'm not
> > enough to convince him that dom0 information is need for crash.
> 
> Just to clarify this discussion.  Magnus's patch *does* include the
> dom0 cr3 information for x86, and I am quite happy with that.  With that
> single, simple, dom0 cr3 value, the crash utility can use the common
> xen/dom0 vmcore file unmodified.

Yes, the patch includes that information today. But say that this value
wouldn't be provided as a crash note - isn't it possible for software to
locate the value anyhow?

Or maybe the CR3 value isn't saved at all? Shouldn't it be saved instead
when all the other registers are saved?

And why do we chose to save CR3 and not CR4? I know what CR3 is used
for, but I kind of dislike the ad-hoc approach of how these things are
added. Also, maybe more registers are needed under Xen compared to the
Linux kernel.

I'm especially thinking about segment registers and descriptor tables.

> What I don't understand is whether the same thing is going to be done
> for x86_64?
> 
> NT_XEN_DOM0_CR3 is #define'd in xen/include/xen/elfcore.h in
> this patch:
> 
>   [Xen-devel] [PATCH 02/04] Kexec / Kdump: Code shared between x86_32 and x86_64
> 
> NT_XEN_DOM0_CR3 is used by the find_dom0_cr3() function in
> xen/arch/x86/crash.c, in this patch:
> 
>   [Xen-devel] [PATCH 03/04] Kexec / Kdump: x86_32 specific code
> 
> But there is no analogous x86_64 usage in this patch:
> 
>   [Xen-devel] [PATCH 04/04] Kexec / Kdump: x86_64 specific code
> 
> Is NT_XEN_DOM0_CR3 not being used by x86_64 by mistake,
> or on purpose?  Or perhaps you're saying that it's going to be
> pulled out completely?

Yes and maybe. It was a mistake to put it into that patch, but I think
the patch ends up in the common code anyway. Next version will be
improved.

Ripping it out? Well, I'm tempted. But nothing is decided. Feel free to
argue. =)

The main reason behind it is that we need to make kexec-tools xen-aware.
And this awareness may lead to that we don't need any crash notes at all
in the Xen case. Mostly because kexec-tools only knows about dom0, but
the crash dump is about the entire system. 

Today we have some code that stores the elf notes in the hypervisor in
the same format as the kernel, and to pass these notes we need to hook
in hypercalls in the kernel so that the user-space tool can find the
address of the crash notes.

I think it would make sense to let dom0 save it's registers within dom0
using the good old crash note format, but to use a simpler format for
registers for the hypervisor. And the let the tools locate the registers
by looking up global symbols.

> > I know you don't want to treat xen binary file with crash, but I'm
> > not clear why.  Please discuss with him directly to make up xen kdump
> > file formats.  The patch will be merged into xen-3.0.4.
> > I hope we can find solution before merge.
> >
> 
> The crash utility is wholly based upon the internal structure
> of the Linux kernel.

So why can't you just require that Xen dumps needs to be cut out with
dom0 cut?

Thanks,

/ magnus