lkml.org 
[lkml]   [2012]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: kexec and struct boot_params
From
On Wed, Dec 12, 2012 at 8:23 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> 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;

thanks for the instruction. please check if you are ok with update patch

> 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.)

ok, add one patch for kexec-tools

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

do you mean, in some file, like bzImage_entry_64.txt
1. kernel 16 bit code length is defined by setup_sects in setup_header.
2. after that there are kernel code
a. 32bit entry is 0,
b. 64bit entry is 0x200
3. when using 32bit entry, kernel should under 1G, initrd should be
under 2G, zero_page, command_line should be under 1G.
when using 64bit entry, kernel, initrd, zero_page, command_line could
be above 4G.

Thanks

Yinghai
[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2012-12-13 09:01    [W:0.043 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site