lkml.org 
[lkml]   [2007]   [Jul]   [14]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
    From"Huang, Ying" <>
    DateSat, 14 Jul 2007 13:48:49 +0800
    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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    
    
    \
     
     \ /
      Last update: 2007-07-14 07:53    [from the cache]
    ©2003-2008