Re: [PATCH] kexec based hibernation: a prototype of kexecmulti-stage load

From: Vivek Goyal
Date: Fri May 16 2008 - 09:41:37 EST


On Thu, May 15, 2008 at 11:27:58PM -0400, Vivek Goyal wrote:
> On Fri, May 16, 2008 at 10:56:15AM +0800, Huang, Ying wrote:
> > On Thu, 2008-05-15 at 19:25 -0700, Eric W. Biederman wrote:
> > > "Huang, Ying" <ying.huang@xxxxxxxxx> writes:
> > >
> > > > On Thu, 2008-05-15 at 11:39 -0700, Eric W. Biederman wrote:
> > > > [...]
> > > >> 2) After we figure out our address read the stack pointer from
> > > >> a fixed location and simply set it. (This is my preference)
> > > >
> > > > Just for confirmation (My English is poor).
> > > >
> > > > Do you mean that kernel A just read the stack top as re-entry point,
> > > > regardless of whether it is return address or argument 1?
> > >
> > > What I was thinking was:
> > >
> > > In kernel A()
> > >
> > > relocate_new_kernel:
> > >
> > > ...
> > >
> > > call *%eax
> > >
> > > kexec_jump_back_entry:
> > > /* This code should be PIC so figure out where we are */
> > > call 1f
> > > 1:
> > > popl %edi
> > > subl $(1b - relocate_kernel), %edi
> > >
> > > /* Setup a safe stack */
> > > leal PAGE_SIZE(%edi), %esp
> > > ...
> > >
> > >
> > > Then in purgatory we can read the address of kexec_jump_back_entry
> > > by examining 0(%esp) and export it in whatever fashion is sane.
> > >
> > > However we reach kexec_jump_back_entry we should be fine.
> >
>
> Huang is making use of purgatory only for booting kernel B for the first
> time. Once the kernel B is booted, all the trasitions (A-->B and B<--A)
> happen without using purgatory. Just keep on jumping back and forth
> to "kexec_jump_back_entry".
>
> Probably not using purgatory for later transitions is justified as long as
> kernel code is simple and small. Otherwise we will shall have to teach
> purgatory also of special case of resuming kernel B or booting kernel B.
>
> > I think it is reasonable to enable jumping back and forth more than one
> > time. So the following should be possible:
> >
> > 1. Jump from A to B (actually jump to purgatory, trigger the boot of B)
> > 2. Jump from B to A
> > 3. Jump from A to B again (jump to the kexec_jump_back_entry of B)
> > 4. Jump from B to A
> > ...
> >
> > So it should be possible to get the re-entry point of kernel B in
> > kexec_jump_back_entry of kernel A too. So I think in
> > kexec_jump_back_entry, the caller's stack should be checked to get
> > re-entry point of peer. And the stack state is different depend on where
> > come from, from relocate_new_kernel() or return.
> >
>
> To me this idea also looks good. So control flow will look something
> as follows?
>
> relocate_new kernel:
>
> if (!preserve_context)
> set registers to known state.
> jump to purgatory.
> else
> goto jump-back-setup:
>
> jump-back-setup:
> - Color the stack.
> move $0xffffffff 0(%esp)
>
> - call %edx
>

Thinking more about it, probably we don't have to separate out preserve
context and normal kexec path. Both can transition to purgatory using
call %edx. Coloring the stack should not harm in normal kexec.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/