On 11/01/13 13:22, Daniel Kiper wrote: > On Thu, Jan 10, 2013 at 02:19:55PM +0000, David Vrabel wrote: >> On 04/01/13 17:01, Daniel Kiper wrote: >>> My .5 cents: >>> - We should focus on KEXEC_CMD_kexec_load and KEXEC_CMD_kexec_unload; >>> probably we should introduce KEXEC_CMD_kexec_load2 and KEXEC_CMD_kexec_unload2; >>> load should __LOAD__ kernel image and other things into hypervisor memory; >> >> Yes, but I don't see how we can easily support both ABIs easily. I'd be >> in favour of replacing the existing hypercalls and requiring updated >> kexec tools in dom0 (this isn't that different to requiring the correct >> libxc in dom0). > > Why? Just define new strutures for new functions of kexec hypercall. > That should suffice. The current hypervisor ABI depends on an internal kernel ABI (i.e., the ABI provided by relocate_kernel). We do not want hypervisor internals to be constrained by having to be compatible with kernel internals. >>> - Hmmm... Now I think that we should still use kexec syscall to load image >>> into Xen memory (with new KEXEC_CMD_kexec_load2) because it establishes >>> all things which are needed to call kdump if dom0 crashes; however, >>> I could be wrong... >> >> I don't think we need the kexec syscall. The kernel can unconditionally >> do the crash hypercall, which will return if the kdump kernel isn't >> loaded and the kernel can fall back to the regular non-kexec panic. > > No, please do not do that. When you call HYPERVISOR_kexec_op(KEXEC_CMD_kexec) > system is completly shutdown. Return form HYPERVISOR_kexec_op(KEXEC_CMD_kexec) > would require to restore some kernel functionalities. It maybe impossible > in some cases. Additionally, it means that some changes should be made > in generic kexec code path. As I know kexec maintainers are very reluctant > to make such things. Huh? There only needs to be a call to a new hypervisor_crash_kexec() function (which would then call the Xen specific crash hypercall) at the very beginning of crash_kexec(). If this returns the normal crash/shutdown path is done (which could even include a guest kexec!). David