Re: kexec and struct boot_params

["H. Peter Anvin" <hpa@zytor.com>]

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.