Messages in this thread | | | Date | Wed, 12 Dec 2012 20:23:14 -0800 | From | "H. Peter Anvin" <> | Subject | Re: 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.
| |