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

To: "Mark Williamson" <mark.williamson@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [PATCH]: kexec: framework and i386
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Sun, 23 Apr 2006 23:03:30 +0100
Cc: Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>, Magnus Damm <magnus@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, horms-home@xxxxxxxxxxxx
Delivery-date: Sun, 23 Apr 2006 15:03:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZm5d8c6zp3ALSEQ+uIb+16E6t8+gANLPoQ
Thread-topic: [Xen-devel] Re: [PATCH]: kexec: framework and i386
> 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.

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.

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


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

Xen-devel mailing list