This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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


> > > In summary, for kdump "linux crashdump=64M@16M"
> > > becomes "xen kdump_megabytes=64 kdump_megabytes_base=16"
> >
> > Please can you explain a bit about how kdump works, and why a physically
> > contiguous region with known base address is required. What actually
> > gets written out in the crash dump and in what format?
> 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.

The current implementation of linux kernel for x86 requires:
  1. Memory for the kernel have to be physically contiguous.
  2. The physical memory have to be mapped to specific virtual space.
     It assumes:
         virtual address for the kernel == physical address | 0x80000000.

> 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.
> 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.

After the dump, I think you will be able to kexec a new Xen and dom0 to
restart the box automatically.

> > 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

Hirokazu Takahashi.

Xen-devel mailing list