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 at intel.com> 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
