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

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

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

Actually, the mechanism is already practically the same: we already have a 
domain builder that could stick the kernel into memory and build a set of 
bootstrap page tables before kicking the domain into life.  Kexec support 
hooks into that by causing the domain builder to be invoked with the new 
kernel, etc.

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

Yep.  We've got a "patches" directory for things we're waiting on being pushed 
upstream.  I added the Linux generic / i386 kexec support into there for the 
time-being.  Possibly I should omit this from a "lite" version of the patch 
for easy reading, since it's a bit confusing if you're just reading...

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

I've thought a bit about this but there are various restrictions that stop Xen 
from building a new image into an existing domain.  Because of this, my patch 
destroys the domain and builds a completely new one with the new kernel.  
Obviously this precludes kdump for now...

The limitations in Xen could be fixed, however we already have a mechanism for 
core-dumping a domain from the "outside", so the motivation doesn't look that 
strong for now.  KDump might still be useful to people who want their 
standard distribution support for dumping to "just work", so it might still 
be worth looking into.

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

Indeed :-)  kdump could be more useful here for debugging whole-host issues.  
The more sensible way to do this would probably be to jump into a minimal 
(Xen-free) Linux, just as normal kdump does, in the event that either Xen or 
the dom0 Linux crashes.

kexec support here would be quite interesting: machine_kexec.c and 
relocate_kernel.S will have to be in Xen itself.  Code for shutting down PCI 
devices will have to be in dom0!  :-)

A neat trick would be avoid implementing the actual "loading" process in Xen - 
just use a kernel that's been loaded by dom0's kernel.  Then Xen only has to 
contain the machine-specific code.  I've designed the mechanism so that it 
can be used for this in future.

Cheers,
Mark

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel