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

[H. Peter Anvin]

Yes.

Yinghai Lu <yinghai at kernel.org> wrote:

>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?

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.