lkml.org 
[lkml]   [2012]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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?

-hpa


--
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.049 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site