On Fri, Dec 21, 2007 at 03:33:19PM +0800, Huang, Ying wrote:
> This patchset provides an enhancement to kexec/kdump. It implements
> the following features:
>
> - Backup/restore memory used both by the original kernel and the
> kexeced kernel.
>
> - Jumping between the original kernel and the kexeced kernel.
>
> - Read/write memory image of the kexeced kernel in the original kernel
> and write memory image of the original kernel in the kexeced
> kernel. This can be used as a communication method between the
> kexeced kernel and the original kernel.
>
>
> The features of this patchset can be used as follow:
>
> - Kernel/system debug through making system snapshot. You can make
> system snapshot, jump back, do some thing and make another system
> snapshot.
>
How do you differentiate between whether a core is resumable or not.
IOW, how do you know the generated /proc/vmcore has been generated after
a real crash hence can't be resumed (using krestore) or it has been
generated because of hibernation/debug purposes and can be resumed?
I think you might have to add an extra ELF NOTE to vmcore which can help
decide whether kernel memory snapshot is resumable or not.
[..]
> 2. Build an initramfs image contains kexec-tool, or download the
> pre-built initramfs image, called rootfs.gz in following text.
>
> 3. Boot kernel compiled in step 1.
>
> 4. Load kernel compiled in step 1 with /sbin/kexec. If You want to use
> "krestore" tool, the --elf64-core-headers should be specified in
> command line of /sbin/kexec. The shell command line can be as
> follow:
>
> /sbin/kexec --load-jump-back /boot/bzImage --mem-min=0x100000
> --mem-max=0xffffff --elf64-core-headers --initrd=rootfs.gz
>
How about a different name like "--load-preserve-context". This will
just mean that kexec need to preserve the context while kexeing to
image being loaded. Combination of --load-jump-back and
--load-jump-back-helper is becoming little confusing.
> 5. Boot the kexeced kernel with following shell command line:
>
> /sbin/kexec -e
>
> 6. The kexeced kernel will boot as normal kexec. In kexeced kernel the
> memory image of original kernel can read via /proc/vmcore or
> /dev/oldmem, and can be written via /dev/oldmem. You can
> save/restore/modify it as you want to.
>
Restoring a hibernated image using /dev/oldmem should be easy and I
think one should be able to launch it back using --load-jump-back-helper.
How do you restore already kexeced kernel? For example if I got two
kernels A and B. A is the one which will hibernate and B will be used
to store the hibernated kernel. I think as per the procedure one needs
to first boot into kernel B and then jump back to kernel A. This will
make image of B available in /proc/kimgcore. If I save /proc/kimgcore
to disk and want to jump back to it, how do I do it? I guess I need
to kexec again using --load-jump-back and not restore using krestore?
> 7. Prepare jumping back from kexeced kernel with following shell
> command lines:
>
> jump_back_entry=`cat /proc/cmdline | tr ' ' '\n' | grep kexec_jump_back_entry | cut -d '='`
> /sbin/kexec --load-jump-back-helper=$jump_back_entry
>
How about decoupling entry point from --load-jump-back-helper. We can
introduce a separate option for entry point. Something like.
kexec --load-jump-back-helper --entry=$jump_back_entry
May be we can generalize the --entry so that a user can override the
entry point of the normal kexec image using above.
> 8. Jump back to the original kernel with following shell command line:
>
> /sbin/kexec -e
>
> 9. Now, you are in the original kernel again. You can read/write the
> memory image of kexeced kernel via /proc/kimgcore.
>
> 10. You can jump between the original kernel and kexeced kernel as you
> want to via the following shell command line:
>
> /sbin/kexec -e
>
>
> Known issues:
>
> - The suspend/resume callback of device drivers are used to put
> devices into quiescent state. This will unnecessarily (possibly
> harmfully) put devices into low power state. This is intended to be
> solved by separating device quiesce/unquiesce callback from the
> device suspend/resume callback.
>
>
> ChangeLog:
>
> v8:
>
> - Split kexec jump patchset from kexec based hibernation patchset.
>
> - Add writing support to kimgcore. This can be used as a communication
> method between kexeced kernel and original kernel.
>
What are we communicating between two kernels using kimgcore?
I am setting up a system to test out the patches. More later...
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
