David Vrabel <david.vrabel at citrix.com> writes: > On 17/01/13 11:27, Daniel Kiper wrote: >> On Wed, Jan 16, 2013 at 04:29:03PM +0000, David Vrabel wrote: >>> The kernel will require a kexec hypercall somewhere in the >>> crash_kexec() path to actually exec the loaded image. Any preferences >>> on how the hook for this should be implemented? Note that the kernel >> >> This should be implemented as stub which be called by machine_kexec() >> and later it would call relevant hypercall. > > That's a complicated way of making a simple function call. What's the > justification for doing it this way? Because there is no justification for a Xen to have a hack in the crash_kexec() path. crash_kexec comes as close as it can to doing a simple function call. > Because Linux doesn't allow images to be unloaded, it's not clear how we > can get sensible behavior if the image is unloaded from Xen. The stub > will remain loaded in Linux but will not be able to return (easily?). Linux allows images to be unloaded by loading an empty image. Aka an image with nr_segments == 0. >>> won't be aware that an image as been loaded as it is loaded directly >>> into the hypervisor and not via the kernel's kexec_load system call. >> >> Maybe we should have sepcial kexec hypercall function which allow us >> to ask hypervisor that image is loaded or not. > > It's not possible to check for an image atomically. I don't think this > is necessary anyway, KEXEC_CMD_exec will return if no image is loaded. If Xen supported something other than the kexec on panic path this could be interesting. The current linux userspace does things conditionally if you are in the reboot runlevel and kexec is coming up. Certainly for the kexec on panic path it is non-interesting. Eric
