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

Yinghai Lu yinghai at kernel.org
Wed Nov 21 15:47:03 EST 2012


On Wed, Nov 21, 2012 at 12:16 PM, H. Peter Anvin <hpa at zytor.com> wrote:
> On 11/21/2012 12:01 PM, Yinghai Lu wrote:
>> On Wed, Nov 21, 2012 at 11:56 AM, H. Peter Anvin <hpa at zytor.com> wrote:
>>> On 11/21/2012 11:54 AM, Yinghai Lu wrote:
>>>>
>>>> in kernel arch/x86/kernel/head_64.S
>>>>
>>>> it only set first 1G ident mapping. and if it find that code is above
>>>> 1G, it will set extra ident mapping
>>>> for new _text.._end.
>>>> To make checking and add extra mapping simple and also save two extra
>>>> pages for mapping.
>>>> Limit that _text.._end in them same GB range.
>>>>
>>>
>>> No, this is backwards.
>>
>> old one: it limited bzImage in [0,1G) aka the first 1G.
>>
>> Now we can put it in any aligned 1G range.
>>
>> So how could it be called backwards?
>>
>
> Because you're adding a more complicated hack.

not that complicated, and it only add 7 lines

        /* same GB ? */
        while ((addr >> 30) != ((addr + size - 1) >> 30)) {
                addr = locate_hole(info, size, align, 0x100000,
                                 round_down(addr + size - 1, (1UL<<30)), -1);
                if (addr == ULONG_MAX)
                        die("can not load bzImage64");
        }

>
>>>
>>> We should fix that limitation instead.
>>
>> sure, but that will make arch/x86/boot/compressed/head_64.S not need
>> complicated.

If that add cover cross GB boundary handling in head_64.S, may need
another 100 line code
for checking and etc.

Also will need another two spare pages for cross 512G boundary.

>
> But it makes the bootloaders more complicated, and the bootloaders are
> harder to fix.

current bootloader does not have this feature and will
add the feature. and looks like kexec is only one at this point.

BTW,  is there any 64bit boot loader?



More information about the kexec mailing list