Re: [RFC PATCH 00/13][V3] kexec: A new system call to allow in kernel loading
From: H. Peter Anvin
Date: Fri Jun 06 2014 - 17:01:44 EST
On 06/06/2014 01:58 PM, Matt Fleming wrote:
> On 6 June 2014 21:37, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>> OK... this is seriously problematic.
>> #if defined(CONFIG_RELOCATABLE) && defined(CONFIG_X86_64) && \
>> /* kernel/boot_param/ramdisk could be loaded above 4g */
>> # define XLF1 XLF_CAN_BE_LOADED_ABOVE_4G
>> # define XLF1 0
>> The fact that even compiling with CONFIG_EFI_MIXED disables
>> XLF_CAN_BE_LOADED_ABOVE_4G is really not going to fly. We should expect
>> CONFIG_EFI_MIXED to be the norm, but *also* should expect that there is
>> a legitimate need to load above 4G.
>> Matt, could you explain why this is necessary? We need to figure out a
>> way around this.
>> My thinking is that disabling this flag is unnecessary, since a 32-bit
>> EFI loader should not load above the 4G mark anyway, but if I'm confused
>> and there is a more fundamental requirement, then we need to consider
>> that more carefully.
> No, your comments are absolutely correct. I was the one who was
> confused. I found this in the git history,
> commit 7d453eee36ae
> Author: Matt Fleming <matt.fleming@xxxxxxxxx>
> Date: Fri Jan 10 18:52:06 2014 +0000
> x86/efi: Wire up CONFIG_EFI_MIXED
> Add the Kconfig option and bump the kernel header version so that boot
> loaders can check whether the handover code is available if they want.
> The xloadflags field in the bzImage header is also updated to reflect
> that the kernel supports both entry points by setting both of
> XLF_EFI_HANDOVER_32 and XLF_EFI_HANDOVER_64 when CONFIG_EFI_MIXED=y.
> XLF_CAN_BE_LOADED_ABOVE_4G is disabled so that the kernel text is
> guaranteed to be addressable with 32-bits.
> As you've pointed out above, a 32-bit loader is never going to load
> the kernel above 4G, so we don't need to disable it.
> What's the best way to fix this up? Just undo the change from the above commit?
Yes, presumably (as a separate patch since the actual commit is quite
large.) The patch needs to have a good description why the original
patch was wrong.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/