Hi,
> > > 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
Thanks,
Hirokazu Takahashi.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home