| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [Fastboot] [PATCH] Xen Guest Kexec
> > 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
|
|
|
| |
|
Home