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