[PATCH 0/2] Kexec jump: The first step to kexec base hibernation
Huang, Ying
ying.huang at intel.com
Sat Jul 14 01:48:49 EDT 2007
On Fri, 2007-07-13 at 10:43 -0600, Eric W. Biederman wrote:
> > Why a assembly stub is necessary? Is it not sufficient that just
> > continue to complete a normal boot (hot add the reset of memory) or load
> > the hibernated kernel (hibernated image) and jump to it?
>
> I was thinking the assembly stub would be the small piece that jumps
> to loaded hibernated kernel. Quite possibly we could just get away
> with providing no memory and just an entry point to kexec but it
> makes sense to me to plan on running a couple of instructions.
Oh, I got it. In my patch, there is such assembly stub in
arch/i386/kernel/kexec_jump.S. I think it is needed to restore basic CPU
state and accommodate some position independent restore code (such as
memory restore code).
> Actually the way the kexec infrastructure it might be reasonable to
> just use sys_kexec_load to load the entire hibernated image. Except
> for the fact that sys_kexec_load requires the source pages to be
> in the processes memory image the code shouldn't have the 50% of
> memory limitation already.
>
> If we can get that going we don't even need to restrict the first
> kernels memory. So it might just require teaching sys_kexec_load
> how to steal process pages. Anyway something to think about.
As for memory backupping and restoring during hibernating and resuming,
I think a possible picture can be as follow:
Memory:
Total memory: 512M
Memory used by hibernating/resuming kernel: 0~16M
Hibernating process:
1. Normal kernel running
2. Hibernating is triggered, sys_kexec_load is used to load
hibernating kernel and initramfs into memory. Then
sys_reboot(LINUX_REBOOT_CMD_KSPAWN) is invoked.
3. In sys_reboot, kexec_jump is called to save device/CPU state,
then relocate_kernel is called. kexec_jump and relocate_kernel
reside in individual page in 16M~512M.
4. In relocate_kernel, 0~16M is backupped firstly, then the
hibernating kernel and initramfs is copied to 0~16M, after that,
the hibernating kernel is booted.
5. In hibernating kernel, the memory of normal kernel (it is in
16M~512M) is saved into a hibernation image through /dev/mem
and ELF header.
Resume process:
1. Resuming kernel is booted as a normal kernel, but the memory is
restricted to 0~16M.
2. Checking whether there is a effective hibernation image. If
there isn't, the memory of 16M~512M is hot added, and the normal
boot up process continues; If there is, a resuming process is
triggered.
3. sys_kexec_load is used to restore the memory state of hibernated
kernel. The sys_kexec_load works in crashdump way, that is, the
hibernation image is copied to destination location in 16M~512M
in sys_kexec_load instead of relocate_kernel. There is no half
of memory size restriction.
4. sys_reboot is called to trigger jumping back, which will jump back
to kexec_jump of hibernated kernel.
5. In kexec_jump of hibernated kernel, the memory of 0~16M is copied
back from the backup area in 16M~512M. The memory state of
hibernated kernel is restored totally. The CPU and device state
can be restored after that.
If there is too much difficulty to hot add memory in step 2. A more
conservative method can be used as step 1 and step 2.
1. A normal kernel is booted.
2. Checking whether there is a effective hibernation image. If there
isn't, continue the normal boot process; otherwise, a resuming
kernel is kexeced in memory 0~16M. The resuming process will
continue in kexeced resuming kernel.
Best Regards,
Huang Ying
More information about the kexec
mailing list