WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [PATCH] Xen Guest Kexec

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Re: [PATCH] Xen Guest Kexec
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Thu, 23 Feb 2006 11:32:53 +0000
Cc: Gerd Hoffmann <kraxel@xxxxxxx>, Horms <horms@xxxxxxxxxxxx>
Delivery-date: Thu, 23 Feb 2006 11:37:26 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43FD9AE9.8040209@xxxxxxx>
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>
References: <200507071816.28830.mark.williamson@xxxxxxxxxxxx> <dtk467$g2e$1@xxxxxxxxxxxxx> <43FD9AE9.8040209@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.1
> For crash-dumping you'll can simply ask xend to write out an dump on
> domain crash, then inspect it using gdbserver-xen ;)
>
> For kexec I'm looking into getting kexec work right now.  For domU's it
> shouldn't be that hard I think.  dom0 likely is much harder given how
> xen and dom0 work hand-in-hand to drive the hardware ...

How are you planning to do domU kexec?

For domUs the major problem I found was:
a) the existing kexec code doesn't understand pseudophysical memory
b) we had no way (at the time) of resetting virtual devices - disconnecting 
cleanly and then reconnecting again
c) creating a start-of-day environment for the reboot kernel duplicates a load 
of code that's already in the domain builder

Because of this, I used a technique I called "assisted kexec" where the guest 
would write out a descriptor which could be used by Xend to (safely, without 
trusting the guest) extract the reboot kernel from guest memory, and rebuild 
the domain with that kernel, using the standard domain builder.  This worked 
quite well actually resulted in less code overall.

For dom0 kexec, I thought the best approach would be to port the existing 
Linux kexec machinery to Xen (should be quite straightforward - just the part 
which copies the kernel image to the correct place, switches off paging, 
jumps into the new kernel).  Then the dom0 kexec code would make a hypercall 
after closing its devices, rather than trying to execute that code itself.

What do you think?

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel