Saveoops: Making Kexec purgatory position-independent?
H. Peter Anvin
hpa at zytor.com
Sat Feb 26 20:15:50 EST 2011
On 02/26/2011 04:57 PM, Eric W. Biederman wrote:
>> I can't see any sane reason to *not* make kexec purgatory
>> position-independent. It is the obvious thing to do.
> This isn't a case of the code not being position independent. This is
> case of where the relocations are applied.
> I can see a couple of handling this with different tradeoffs.
> 1) We teach bootloaders how to load two kernels at once. This
> completely avoids the purgatory, as it is replaced by code in the
> bootloader that already exists to load the primary kernel and setup
> it's arguments.
> 2) We add minimal relocation processing to purgatory, allowing us to do
> the setup for the second kernel extremely early and allow it to be
> compiled into the first kernel.
> 3) We come up with a scheme where we don't share code and the first
> kernel copies the firmware information to place where the second
> kernel can get at it, and uses it's own home grown stub and not
> I think this whole thing can be prototyped easily with a getting /sbin/kexec
> to load to a fixed address and then baking that section into the primary
> kernel. I'm not convinced that directly using /sbin/kexec is the right
> way forward to handle the general case. This is something where the
> devil is in the details.
OK... I'm clearly missing something... what code is not being
position-independent and which code needs relocations applied?
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
More information about the kexec