|   | 
      | 
  
  
      | 
      | 
  
 
     | 
    | 
  
  
     | 
    | 
  
  
    |   | 
      | 
  
  
    | 
         
xen-devel
[Xen-devel] Re: [Fastboot] [PATCH] Xen Guest Kexec
 
Mark Williamson <mark.williamson@xxxxxxxxxxxx> writes:
> All,
>
> I'm posting to the Xen-devel list and the OSDL fastboot list.  There are a 
> number of Xen folks who'll want to look at the code.  For the fastboot folks, 
> this is mostly intended as an announcement of the port.  Please limit your 
> replies to the list(s) that they applies to, thanks :-)
>
> A number of people have expressed interest in kexec support for Xen guests.  
> In particular, it's mainly useful for purposes of implementing an in-guest 
> bootloader app and avoiding the need for dom0 to access the guest filesystem.
Is kexec at all useful for generating the initial image as well?
I believe all it would require would be defining an extra kexec type,
to load an image into the new domain.
> It's a largish patch, so I stuck it online: 
> http://www.cl.cam.ac.uk/~maw48/xenguest_kexec.patch
> Tested on i386.  I suspect it'll have build issues on x86_64 but those should 
> be easy to fix - actually the code is probably generic enough to work on 
> both.
Part of that patch is that you have another patch file showing up
in your diff.
> You'll also need a modified version of the kexec tools, which I'll post 
> details of later.
>
> Notes on the implementation:
> Kexec in a Xen guest doesn't work like on a real machine.  The guest relies 
> on 
> outside assistance to complete the job.  The guest communicates details of 
> the kexec to Xend.  Xend extracts the data from the guest's memory image and 
> uses it to rebuild the domain with a new kernel, etc.  This approach 
> simplifies the changes needed to support kexec and minimises code duplication 
> between Linux and the domain builder itself.
How useful will you your kexec implementation handle the kexec on panic
case?  In that case we kexec a kernel at an alternative address and
then read from the memory what the previous kernel had left in it's
physical memory, and generate a crash dump of it.
> Kexec-ing the whole host is a separate issue, I think it's best addressed 
> with 
> a port of kexec to Xen itself.
Sounds fun. :)
Eric
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
 
 |   
 
 | 
    | 
  
  
    |   | 
    |