Re: kexec and struct boot_params

[H. Peter Anvin]

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/