Ying Huang posted a new version of his hibernation patches that utilize kexec noting two changes, "1) the kexec jump implementation is put into the kexec/kdump framework instead of software suspend framework. The device and CPU state save/restore code of software suspend is called when needed; and 2) the same code path is used for both kexec a new kernel and jump back to original kernel." Andrew Morton noted that he was still interested however didn't intend to merge the patches right away, "I like the idea but I think I'll let people chat about it a bit more before looking at merging the patches, OK?" TuxOnIce maintainer Nigel Cunningham expressed some strong reservations:

"Please wait until you see a complete implementation that actually works. I'm sitting here quietly, following (and now breaking) the 'If you can't say anything positive, don't say anything at all' line because I think that the more into the implementation details people get, the uglier this is going to show itself to be. I'm perfectly willing to be proven wrong, but haven't seen anything so far that's even begun to convince me otherwise."

From:	Huang, Ying [email blocked]
Subject: [PATH 0/1] Kexec jump - v2 - the first step to kexec based hibernation
Date:	Sun, 15 Jul 2007 15:13:13 +0800

The changelog between v1 and v2

1. The kexec jump implementation is put into the kexec/kdump
   framework instead of software suspend framework. The device
   and CPU state save/restore code of software suspend is called
   when needed.

2. The same code path is used for both kexec a new kernel and jump
   back to original kernel.

The complete changelog of the patch is as follow:

---

Kexec base hibernation has some potential advantages over uswsusp and
TuxOnIce (suspend2). Some most obvious advantages are:

1. The hibernation image size can exceed half of memory size easily.
2. The hibernation image can be written to and read from almost
   anywhere, such as USB disk, NFS.

This patch implements the functionality of "jumping from kexeced
kernel to original kernel". That is, the following sequence is
possible:

1. Boot a kernel A
2. Work under kernel A
3. Kexec another kernel B in kernel A
4. Work under kernel B
5. Jump from kernel B to kernel A
6. Continue work under kernel A

This is the first step to implement kexec based hibernation. If the
memory image of kernel A is written to or read from a permanent media
in step 4, a preliminary version of kexec based hibernation can be
implemented.

The kernel B run as a crashdump kernel in reserved memory region. This
is the biggest constrains of the patch. It is planed to be eliminated
in the future version. That is, instead of reserving memory region
previously, the needed memory region is backupped before kexec and
restored after jumping back.

Another constrains of the patch is that the CONFIG_ACPI must be turned
off to make kexec jump work. Because ACPI will put devices into low
power state, the kexeced kernel can not be booted properly under
it. This constrains can be eliminated by separating the suspend method
and hibernate method of the devices as proposed earlier in the LKML.

The kexec jump is implemented in the framework of kexec/kdump. In
sys_reboot, a new command named LINUX_REBOOT_CMD_KJUMP is defined to
trigger the jumping to (executing) the new kernel or jump back to the
original kernel.

Now, only the i386 architecture is supported. The patch is based on
Linux kernel 2.6.22, and has been tested on my IBM T42.

Usage:

1. Compile kernel with following options selected:

CONFIG_X86_32=y
CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it
CONFIG_KEXEC=y
CONFIG_PM=y
CONFIG_KEXEC_JUMP=y

2. Compile the kexec-tools with kdump and kjump patches, the
   kdump patch can be found at:

http://lse.sourceforge.net/kdump/patches/kexec-tools-1.101-kdump10.patch

   While, the kexec-tools kjump patch is appended with the mail.

3. Boot kernel compiled for normal usage, the reserved crash kernel
   memory region must be added to kernel command line as following:

   crashkernel=<XX>M@<XX>M

   Where, <XX> should be replaced by the real memory size and position.

4. Load kernel compiled for hibernating usage as a crashdump kernel
   with kexec, the same kernel as that of 3 can be used if
   CONFIG_RELOCATABLE=y is selected. The kernel command line option as
   following must be appended to kernel command line.

   kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`

   For example, the shell command line can be as follow:

   kexec -p /boot/vmlinux --args-linux --append="root=/dev/hdb signal
       kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`"

5. Boot the hibernating kernel with following shell command line:

   kexec -j

6. In the kexec booted kernel, trigger the jumping back with following
   shell command.

   kexec -j

---

changelog of kexec-tools

A new command line option -j/--jump is added to support
jumping/executing the currently loaded kernel or jumping back to the
original kernel. The implementation of -j/--jump is to call
corresponding syscall.

For i386 architecture, the address of backup of 0~640k is passed to
kexeced kernel as a kernel command line option. This is used by
kexeced kernel to restore the backup.

---


From:	Nigel Cunningham [email blocked]
To:	Huang, Ying [email blocked]
Subject: Re: [PATH 0/1] Kexec jump - v2 - the first step to kexec based hibernation
Date:	Sun, 15 Jul 2007 19:08:04 +1000

Hi.

On Sunday 15 July 2007 17:13:13 Huang, Ying wrote:
> The complete changelog of the patch is as follow:
> 
> ---
> 
> Kexec base hibernation has some potential advantages over uswsusp and
> TuxOnIce (suspend2). Some most obvious advantages are:
> 
> 1. The hibernation image size can exceed half of memory size easily.
> 2. The hibernation image can be written to and read from almost
>    anywhere, such as USB disk, NFS.

This isn't right. TuxOnIce has no problem with image sizes exceeding half the 
amount of memory, and both uswsusp and TuxOnIce could write to a USB disk/key 
or NFS as well. Historically, the issue with writing to USB devices has been 
an issue with USB device drivers, not hibernation implementations. I haven't 
tried writing an image to USB, but with the work on the drivers, I wouldn't 
be surprised if it was usable now. NFS? Again, I haven't tried, but wouldn't 
expect it to be impossible. I did try writing an image to an NBD device a 
couple of years ago. It didn't quite work, but wasn't far away.
 
Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.



From: Andrew Morton [email blocked]
Subject: Re: [PATH 0/1] Kexec jump - v2 - the first step to kexec based hibernation
Date:	Wed, 18 Jul 2007 18:04:20 -0700

On Sun, 15 Jul 2007 15:13:13 +0800
"Huang, Ying" wrote:

> 
> The changelog between v1 and v2
> 
> 1. The kexec jump implementation is put into the kexec/kdump
>    framework instead of software suspend framework. The device
>    and CPU state save/restore code of software suspend is called
>    when needed.
> 
> 2. The same code path is used for both kexec a new kernel and jump
>    back to original kernel.

I like the idea but I think I'll let people chat about it a bit more
before looking at merging the patches, OK?



From:	Nigel Cunningham [email blocked]
To:	Andrew Morton [email blocked]
Subject: Re: [PATH 0/1] Kexec jump - v2 - the first step to kexec based hibernation
Date:	Thu, 19 Jul 2007 12:15:04 +1000

Hi.

On Thursday 19 July 2007 11:04:20 Andrew Morton wrote:
> On Sun, 15 Jul 2007 15:13:13 +0800
> "Huang, Ying" wrote:
> 
> > 
> > The changelog between v1 and v2
> > 
> > 1. The kexec jump implementation is put into the kexec/kdump
> >    framework instead of software suspend framework. The device
> >    and CPU state save/restore code of software suspend is called
> >    when needed.
> > 
> > 2. The same code path is used for both kexec a new kernel and jump
> >    back to original kernel.
> 
> I like the idea but I think I'll let people chat about it a bit more
> before looking at merging the patches, OK?

Please wait until you see a complete implementation that actually works. I'm 
sitting here quietly, following (and now breaking) the "If you can't say 
anything positive, don't say anything at all" line because I think that the 
more into the implementation details people get, the uglier this is going to 
show itself to be. I'm perfectly willing to be proven wrong, but haven't seen 
anything so far that's even begun to convince me otherwise.

Regards,

Nigel

• Archive of above thread
• KernelTrap interview with Andrew Morton