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

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> 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