[Crash-utility] Re: crash with Xen dom0 image from kdump

[Horms]

On Wed, Jun 14, 2006 at 09:29:10AM -0400, Dave Anderson wrote:
> Horms wrote:
> 
> > On Wed, Jun 14, 2006 at 10:46:45AM +0900, Simon Horman [Horms] wrote:
> > > On Mon, Jun 12, 2006 at 01:41:07PM +0900, Kazuo Moriwaka wrote:
> > > > Hi,
> > > >
> > > > I'm not clear about shadow mode; are vcpu->arch.shadow_table need for
> > > > shadow-mode domains?
> > >
> > > To be perfectly honest, I'm not clear about it either.
> > > The code below probably does not cover shadow mode, but
> > > it should be easy enough to fix, probably using vcpu->arch.shadow_table
> > > as you suggest. I'll look into it some more.
> >
> > After talking things over a little with Yamahata-san (who works on
> > xen-ia64), it seems that using vcpu->arch.guest_table is correct.
> > I guess we shall see.
> >
> > I added some code to kdump to have it record CR3 for dom0. This is
> > done using a second note in the per-cpu notes area, which for now
> > just stores a single 4byte entity, the mfn of that CPU in dom0
> > if it was present in dom0.
> >
> > I have made a dump available that includes this. The tarball
> > also includes the kernels, xen, symbol files, and patches to xen.
> > If you want to find the cr3 saving code its in ./arch/x86/crash.c
> >
> > I plan to post this update to xen-devel shortly, hopefully tomorrow,
> > after upporting to the latest xen tree (I'm still working off about
> > 3 weeks ago's tree).
> >
> > http://packages.vergenet.net/tmp/xen-unstable.hg+kexec-20060616.tar.bz2
> >
> 
> Thanks -- I'm downloading this, and will try to look at it soon.
> 
> I still think, though, that the cr3 value is useless as a starting
> point for shadow-pagetable kernels, and we'll end up revisiting
> this again later.

I expect so too. With a little bit of luck kexec will be merged into
xen in the not to distant future, hopefully that will bring more eyes
to the problem.

> Having the "pfn_to_mfn_frame_list_list" mfn value from the shared,
> per-domain, "arch_shared_info" structure(s) would cover both
> writable and shadow pagetable kernels.

I guess that should be easy enough to do. Now we have the separate note
we potentially can store quite a number of things.

> Also, I'm still curious, (I haven't looked at the patcheds in the tar.bz2 file),
> does your kexec/kdump kernel get kicked off
> 
> (1) when the hypervisor crashes,
> (2) when the dom0 kernel crashes, or
> (3) both?

3)

You can generate a domU crash using sysrq. I have a patch, which I think 
I included in the tarball, that allows you to generate a hypervisor panic
from the xen console, which is availble over serial.

enter xen console: ctrl-a ctrl-a
help:  h
panic: p

In a nutshell the it is the hypervisor not the dom0 kernel that performs
kexec/kdump. Or in other words, userspace asks dom0 to load a kernel, which
in turn just passes it on to the hypervisor. From there its just a matter
of activating the new kernel, and that can be triggered from within they
hypervisor, or from dom0 using a hypercall. The resulting dump should be
much the same, with the exception that if dom0 crashes then the crashing
CPU's registers are saved by dom0 and passed to the hypervisor, and in the
case where they hypervisor crashes, it saves the crashing CPU's regisers.
Regardless, the hypervisor saves the non-crashing CPU's registers.

Part of the motivation for allowing the hypervisor trigger perform kexec/kdump
without needing data from dom0 (other than what is passed at load time) is
to allow hypervisor panics to cause kdump. And part of it is becasuse only
the hypervisor has access to all of system memory, the mmu, and all of the
cpus. I don't think there were any other significant parts :)

-- 
Horms                                           http://www.vergenet.net/~horms/