On 17/01/13 11:27, Daniel Kiper wrote: > On Wed, Jan 16, 2013 at 04:29:03PM +0000, David Vrabel wrote: >> This series of patches improves the kexec hypercall in the Xen >> hypervisor. It is an incomplete prototype but I posting it early for >> comments on the proposed ABI/API. >> >> This allows a privileged Xen guest to load kexec images into the >> hypervisor from a userspace tool without using the Linux kernel's >> kexec subsystem. It is the first step to supporting kexec of crash >> kernels from a pv-ops dom0 kernel (the required kernel and kexec-tools >> patches will be posted later). >> >> 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 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?). >> 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. David
