[lkml]   [2012]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kexec and struct boot_params
On 12/12/2012 06:49 PM, Yinghai Lu wrote:
>> Hi, Peter,
>> What's your decision about this?
>> Do you mean have one boot_params mask in initdata and AND that with
>> boot_params from bootloader
>> to clean not used bytes?
>> So later will not need to check
>> if (boot_params.hdr.xloadflags & USE_EXT_BOOT_PARAMS)
>> ?
>> I worked out other patches that remove kdump 896M limitation.
>> would like to post those patches to get more testing.
>> those are needed for bigger system with lots of pcie devices.
> ping!

I still want to do what I mentioned before, because we need to not rely
on the initialized/16-bit portion so much:

1. add a field in the uninitialized portion, call it "sentinel";
2. make sure the byte position corresponding to the "sentinel" field is
nonzero in the bzImage file;
3. if the kernel boots up and sentinel is nonzero, erase those fields
that you identified as uninitialized;
4. assign a proper boot loader ID to kexec, so we have a way of dealing
with this kind of debacles in the future (that is what the
bootloader ID is for: it gives us a way to work around
bootloader-specific problems.)

We also need to formalize the 64-bit entry point properly, including all
the entry conditions and so forth. That needs to be documented.

Eric, any thoughts or additional opinions?


H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

 \ /
  Last update: 2012-12-13 06:01    [W:0.082 / U:1.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site