Re: [Xen-devel] Re: [PATCH]: kexec: framework and i386

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> > The reserved region is the memory space for the "dump
> > kernel".  I believe the base address has to correspond to the
> > base address compiled into the dump kernel - since we don't
> > want the dump kernel to try to own all of memory.
> > It's native Linux, so it likes to run in contiguous memory.
>
> This approach is rather wasteful of memory, though maybe burning 64MB
> isn't a big deal these days.

Yep, although for a dump kernel's userspace you probably don't need that much.  
Using a minimalised userland, you'd be able to get this substantially less 
but I'm not sure to what extent they bother in modern distros...  I'm not 
sure the distros are fully leveraging kdump yet, since it's still fairly new.

It depends a bit on how much you want to run - you could use gdb interactively 
from the dump kernel's console, for instance.

> Strictly speaking, we only really need to reserve a couple of MB for the
> kernel text.
> It's unlikely that you'd want to dump pages belonging to unpriv guests,
> so there's actually quite a lot of opportunity for shuffling things
> around to get the dump kernel to where it expects to be in the machine
> address space, zeroing the data/bss segments.

Yep, also true.

> > When a panic occurs, Linux kexec jumps into the preloaded
> > kdump kernel (if any).  This kernel then reinitiases the
> > hardware, using its own device drivers and uses these to
> > write out the dump to disk.  ISTR that the dump format is
> > currently ELF, although I remember some talk on the Fastboot
> > ML about adding some extra headers to make OS debugging easier.
>
> Is Xen and the dom0 kernel dumped as as separate ELF cores?

I'm not sure how Horms has done this, if he has yet...  I'm more familiar with 
native Linux kdump.  I can't really see it'd be that much harder to do this, 
though.

Cheers,
Mark

> Ian
>
> > It's a nice solution because you don't rely on the hosed
> > kernel to do the dump for you, and you don't disturb its
> > state in the process.  It also makes it easy to do things
> > like dumping to network devices, etc.
> >
> > In our case it has the added bonus that on dom0 *or* a Xen
> > crash it ought to be possible to kexec into a native Linux
> > kernel which could dump (possibly some configurable
> > combination of) Xen itself, dom0, and all the other domains.
> > Admittedly hypervisor crashes / hangs are rare, but it might
> > aid debugging to be able to get a reliable dump of a crashed
> > / hung Xen.
> >
> > This would also integrate with the Linux dump infrastructure,
> > which would be useful to have.
> >
> > > Tim Deegan submitted a patch to add support for multiboot
> >
> > images (such
> >
> > > as Xen) to kexec a couple of years ago, and I believe it
> >
> > has been part
> >
> > > of the standard package for some time.
> >
> > It was in there last time I looked at the source code...
> > I've never actually used it though, so in principle I guess
> > it could have rotted.  Or there could just be something weird
> > happenning.
> >
> > Cheers,
> > Mark
> >
> > --
> > Dave: Just a question. What use is a unicyle with no seat?
> > And no pedals!
> > Mark: To answer a question with a question: What use is a skateboard?
> > Dave: Skateboards have wheels.
> > Mark: My wheel has a wheel!

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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