I'd mentioned it a few times in the context of mcore, but probably
didn't explain myself clearly enough then.
>
> > Note that the two-phase boot means that you can load the new kernel early,
> > which allows you to later on use it for oops handling (it's a bit late to
> > try to set up the kernel to be loaded at that time ;)
>
> Given that it is definitely a good idea to split the patch up into two
> pieces. And a kernel for oops handling should work once all of other
> problems are resolved.
Yes, this fits the model we need.
>
> The question is how much of that do we need.
>
> Thinking out loud, and hopefully answering your question.
> - We need a working stack when the new kernel is jumped to so PIC code
> can exist at the entry point.
>
> - An oops processing kernel needs to load at an address other than 1MB,
> or at the very least it's boot sequence needs to squirrel away the
> old contents of the kernel text and data segments, which reside at
> 1MB, before it moves down to 1MB.
Yes, that bit of memory save logic exists in the mcore mechanism. These
pages are saved away in compressed form in memory and written out
later after dump.
Now to avoid these pages from being used by the new kernel until
the dump is safetly written out to disk, mcore patches some of
the initialization code to mark these pages (containing saved
dump) as reserved.
> O.k. In the next couple of days I will split the loading, and
> executing phase of my kexec code into parts, and resubmit the code.
Great !
> The we can dig in on what it takes to make kexec run stably.
>
Regards
Suparna
-- Suparna Bhattacharya (suparna@in.ibm.com) Linux Technology Center IBM Software Labs, India- 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/