diff options
author | Matt Fleming <matt.fleming@intel.com> | 2014-01-10 18:52:06 +0000 |
---|---|---|
committer | Matt Fleming <matt.fleming@intel.com> | 2014-03-04 21:43:57 +0000 |
commit | 7d453eee36ae4cf30fc2f2faae54f634c4f863b7 (patch) | |
tree | ccfb0d45555281eba81bab3548e541570da99ee2 /crypto/vmac.c | |
parent | 4f9dbcfc40299ddaa780fe8c1cd74998c1be3af5 (diff) | |
download | linux-7d453eee36ae4cf30fc2f2faae54f634c4f863b7.tar.gz linux-7d453eee36ae4cf30fc2f2faae54f634c4f863b7.tar.bz2 linux-7d453eee36ae4cf30fc2f2faae54f634c4f863b7.zip |
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.
Note that no boot loaders should be using the bits set in xloadflags to
decide which entry point to jump to. The entire scheme is based on the
concept that 32-bit bootloaders always jump to ->handover_offset and
64-bit loaders always jump to ->handover_offset + 512. We set both bits
merely to inform the boot loader that it's safe to use the native
handover offset even if the machine type in the PE/COFF header claims
otherwise.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Diffstat (limited to 'crypto/vmac.c')
0 files changed, 0 insertions, 0 deletions