[PATCH v3 4/4] kexec, x86_64: Load bzImage64 above 4G
Eric W. Biederman
ebiederm at xmission.com
Thu Nov 22 06:39:12 EST 2012
Vivek Goyal <vgoyal at redhat.com> writes:
> On Wed, Nov 21, 2012 at 11:50:56AM -0800, Yinghai Lu wrote:
>> On Wed, Nov 21, 2012 at 6:50 AM, Vivek Goyal <vgoyal at redhat.com> wrote:
>> >
>> > So how do I force a 16bit or 32bit entry using a bzImage64?
>>
>> kexec -t bzImage -l ....
>> will load low and use 32bit entry.
>>
>> kexec -t bzImage64 -l ...
>> kexec -l ...
>> will try to load high and use 64bit entry.
>
> Also bzImage64 is not really a new image format. It is just enhancement
> of bzImage format. We keep on doing extention of bzImage and don't call it
> a new image format. I am not sure how good an idea it is to export the
> notion of new image type bzImage64 to user.
For what the loader has to do bzImage64 is effectively a new format,
and one way or another needs to be handled by separate functions so that
the code remains readable.
I asked YH to add the code that way because it means only a 64bit kexec
has to carry that code and we don't have 64bit dependencies in in the
32bit build that will break. The code to prepare boot_params is still
shared.
Chaining to the 32bit loader if someone asks for --real-mode or
perhaps --entry32 seems quite reasonable and only a couple of lines
of code so I have not objections to that.
While development is on-going forcing the image type seems very
reasonable, but when the smoke clears I would like to see
the bzImage64 format chaining to bzImage for the cases it does not
handle.
But with respect to autodetection only having bzImage64 kick in when
loading a 64bit kernel is possible looks like the right way to go.
Eric
More information about the kexec
mailing list