Re: [PATCH v3 4/4] kexec, x86_64: Load bzImage64 above 4G

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

Vivek Goyal <vgoyal@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@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




_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec