kexec is a set of systems call that allows you to load another kernel from the currently executing Linux kernel. The current implementation has only been tested, and had the kinks worked out on x86, but the generic code should work on any architecture.
Could I get some feed back on where this work and where this breaks. With the maturation of kexec-tools to skip attempting bios calls, I expect a new the linux kernel to load for most people. Though I also expect some device drivers will not reinitialize after the reboot.
The patch is archived at: http://www.xmission.com/~ebiederm/files/kexec/
And is currently kept in two pieces. The pure system call. http://www.xmission.com/~ebiederm/files/kexec/linux-2.5.48.x86kexec.diff
And the set of hardware fixes known to help kexec. http://www.xmission.com/~ebiederm/files/kexec/linux-2.5.48.x86kexec-hwfixes....
A compatible user space is at: http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.7.tar.gz This code boots either a static ELF executable or a bzImage.
As of version 1.6 /sbin/kexec now works much more like /sbin/reboot. It is recommend you place /sbin/kexec -e in /etc/init.d/reboot just before the the call to /sbin/reboot. If you haven't called /sbin/kexec previously it will fail, and you can then call /sbin/reboot. Given the similiarity it is now the plan to merge in reboot via kexec into /sbin/reboot.
One bug was fixed in the move to 2.5.48. Previously I had failed to clear PAE and PSE in the kernel. This caused reboot failures when CONFIG_HIGHMEM_64G was enabled, as the new kernel would fail when enabling paging, as these bits remained set. Is %cr4 present on all 386+ intel cpus, or do I need to conditionalize the code that accesses it?
As of version 1.6 /sbin/kexec when presented with a bzImage by default avoids all BIOS calls and jumps directly to the kernels 32 bit entry point. The information it would usually get from the BIOS is instead collected from the current kernel. Accurately getting things like the BIOS memory map from the current kernel is a challenge, still needs to be addressed. Safe defaults have been provided for the cases I do not currently have good code to gather the information from the running kernel.
In bug reports please include the serial console output of kexec kexec_test. kexec_test exercises most of the interesting code paths that are needed to load a kernel (mainly BIOS calls) with lots of debugging print statements, so hangs can easily be detected.
Eric
-
ebiederman＠lnxi.com