Re: [Fastboot] [CFT] ELF Relocatable x86 and x86_64 bzImages

[ebiederm@xmission.com (Eric W. Biederman)]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Vivek Goyal wrote:
>> On Thu, Aug 10, 2006 at 02:09:58PM -0600, Eric W. Biederman wrote:
>>>> I just reserved memory at non 2MB aligned location 65MB@15MB so that
>>>> kernel is loaded at 16MB and other smaller segments below the compressed
>>>> image, then I can successfully booted into the kdump kernel.
>>> :)
>>>
>>>> So basically kexec on panic path seems to be clean except stomping issue.
>>>> May be bzImage program header should reflect right "MemSize" which
>>>> takes into account extra memory space calculations.
>>> Yes.  That sounds like the right thing to do.
>>>
>>> I remember trying to compute a good memsize when I created the bzImage
>>> header but it is completely possible I missed some part of the
>>> calculation or assumed that the kernels .bss section would always be
>>> larger than what I needed for decompression.
>>>
>
> Could someone please describe the intended semantics of this MemSize header,
> *and* its intended usage?

I think Vivek did a decent job.  But here is my take.

Currently the ELF header we prepend to the linux kernel have
exactly one segment.

A segment has several file offset, fields alignment, type, physical
address, virtual address, file size, and memory size.

The file size parameter describes how much data to pull off of the
disk.  The memory size describes how much room the segment will
consume in memory.  The difference between file size and memory size
is treated as bss data.  Memory size must always be bigger than
file size.

In the case of the kernel there is a certain amount of memory that
the kernel uses before it starts reserving things and using the
memory map.  The memory that the kernel unconditionally uses should
be described with the memsize parameter.

An accurate description allows your initrd and your parameter segment
to be placed right up next to your kernel without worry about them
being stomped, we already do this on a couple of other architectures,
or it allows you to detect that there is not enough room to hold your
kernel, initrd and parameters.

So since we now have the possibility of describing this accurately I
would like to.  Although the traditional x86 work around of pushing
everything up as far in memory as we can and the kernel can address
is potentially still an option.

For the kexec on panic case we have a very small reserved chunk of
memory (16MB I think is typical right now).  The smaller that we can
successfully run out of the better.  Which makes it easy to hit these
kinds of things if we don't have an accurate description of the
kernel.

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