efi: Clarify Kconfig help for EFI_MIXED
PATCH 1/1 efi: Clarify Kconfig help for EFI_MIXED
EFI stub support is only missing for a 64 bit kernel on 32-bit firmware, on 64-bit kernels, EFI stub works as usual.
---
Matt, I don't know if this help was intentionally discouraging, however, out of curiosity, I tested this with ovmf, and the kernel boots fine on 64-bit firmware bit with EFI stub, and on 32-bit firmware using efilinux.
Documenting this properly is important for distribution kernels. We would want to support this on Arch, but not if it means introducing a regression for EFI stub users.
arch/x86/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/Kconfig +2 -2
@@ -1529,8 +1529,8 @@ config EFI_MIXED mode. Note that it is not possible to boot a mixed-mode enabled - kernel via the EFI boot stub - a bootloader that supports - the EFI handover protocol must be used. + kernel via the EFI boot stub on 32-bit firmware - a bootloader + that supports the EFI handover protocol must be used. If unsure, say N.
Signature · 1 line
1.9.2
H. Peter Anvin
reviewerQuoted 21 lines · Thomas Bächler
EFI stub support is only missing for a 64 bit kernel on 32-bit firmware, on 64-bit kernels, EFI stub works as usual.
---Matt, I don't know if this help was intentionally discouraging, however, out of curiosity, I tested this with ovmf, and the kernel boots fine on 64-bit firmware bit with EFI stub, and on 32-bit firmware using efilinux.
Documenting this properly is important for distribution kernels. We would want to support this on Arch, but not if it means introducing a regression for EFI stub users.
arch/x86/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)arch/x86/Kconfig +0
-0
arch/x86/Kconfig config EFI_MIXED · line 1536
Quoted 10 lines
arch/x86/Kconfig +2
-2@@ -1529,8 +1529,8 @@ config EFI_MIXED mode. Note that it is not possible to boot a mixed-mode enabled - kernel via the EFI boot stub - a bootloader that supports - the EFI handover protocol must be used. + kernel via the EFI boot stub on 32-bit firmware - a bootloader + that supports the EFI handover protocol must be used. If unsure, say N.
Right, it is really that it is not possible to boot a mixed-mode kernel on its non-native firmware using the stub, since the stub itself can only be one way or the other.
-hpa
Quoted 30 lines · H. Peter Anvin
Quoted 29 lines · Thomas Bächler
EFI stub support is only missing for a 64 bit kernel on 32-bit firmware, on 64-bit kernels, EFI stub works as usual.
---Matt, I don't know if this help was intentionally discouraging, however, out of curiosity, I tested this with ovmf, and the kernel boots fine on 64-bit firmware bit with EFI stub, and on 32-bit firmware using efilinux.
Documenting this properly is important for distribution kernels. We would want to support this on Arch, but not if it means introducing a regression for EFI stub users.
arch/x86/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)arch/x86/Kconfig +2
-2@@ -1529,8 +1529,8 @@ config EFI_MIXED mode. Note that it is not possible to boot a mixed-mode enabled - kernel via the EFI boot stub - a bootloader that supports - the EFI handover protocol must be used. + kernel via the EFI boot stub on 32-bit firmware - a bootloader + that supports the EFI handover protocol must be used.
Quoted 6 lines
arch/x86/Kconfig config EFI_MIXED · line 1536
Quoted 2 lines
arch/x86/Kconfig +0
-0If unsure, say N.Right, it is really that it is not possible to boot a mixed-mode kernel on its non-native firmware using the stub, since the stub itself can only be one way or the other.
Yeah, my help text was a bit... unhelpful.
CONFIG_EFI_MIXED does not introduce a regression of any sort, you can enable it without worrying about that.
All the boot configurations that used to work will continue to work.
What I meant to say was that it isn't possible to use the EFI mixed *feature* (booting a 64-bit kernel with 32-bit firmware) with the EFI boot stub - so you can build support into your kernel but there's no way to make the CPU actually execute those code paths.
Signature · 1 line
Matt Fleming, Intel Open Source Technology Center
Quoted 43 lines · Matt Fleming
Quoted 30 lines · H. Peter Anvin
Quoted 29 lines · Thomas Bächler
EFI stub support is only missing for a 64 bit kernel on 32-bit firmware, on 64-bit kernels, EFI stub works as usual.
---Matt, I don't know if this help was intentionally discouraging, however, out of curiosity, I tested this with ovmf, and the kernel boots fine on 64-bit firmware bit with EFI stub, and on 32-bit firmware using efilinux.
Documenting this properly is important for distribution kernels. We would want to support this on Arch, but not if it means introducing a regression for EFI stub users.
arch/x86/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)arch/x86/Kconfig +2
-2@@ -1529,8 +1529,8 @@ config EFI_MIXED mode. Note that it is not possible to boot a mixed-mode enabled - kernel via the EFI boot stub - a bootloader that supports - the EFI handover protocol must be used. + kernel via the EFI boot stub on 32-bit firmware - a bootloader + that supports the EFI handover protocol must be used.Quoted 6 lines
arch/x86/Kconfig config EFI_MIXED · line 1536
Quoted 2 lines
arch/x86/Kconfig +0
-0If unsure, say N.Right, it is really that it is not possible to boot a mixed-mode kernel on its non-native firmware using the stub, since the stub itself can only be one way or the other.
Yeah, my help text was a bit... unhelpful.
CONFIG_EFI_MIXEDdoes not introduce a regression of any sort, you can enable it without worrying about that.
Quoted 6 lines
All the boot configurations that used to work will continue to work.
What I meant to say was that it isn't possible to use the EFI mixed *feature* (booting a 64-bit kernel with 32-bit firmware) with the EFI boot stub - so you can build support into your kernel but there's no way to make the CPU actually execute those code paths.
Same goes for booting a 32-bit kernel on 64-bit firmware, right?
Thanks,
Ingo
Am 14.04.2014 09:15, schrieb Ingo Molnar:
Quoted 9 lines
Quoted 9 lines
Quoted 3 lines
Right, it is really that it is not possible to boot a mixed-mode kernel on its non-native firmware using the stub, since the stub itself can only be one way or the other.
Yeah, my help text was a bit... unhelpful.
CONFIG_EFI_MIXEDdoes not introduce a regression of any sort, you can enable it without worrying about that.
Quoted 9 lines
Quoted 6 lines
All the boot configurations that used to work will continue to work.
What I meant to say was that it isn't possible to use the EFI mixed *feature* (booting a 64-bit kernel with 32-bit firmware) with the EFI boot stub - so you can build support into your kernel but there's no way to make the CPU actually execute those code paths.
Same goes for booting a 32-bit kernel on 64-bit firmware, right?
It seems that isn't implemented:
config EFI_MIXED
bool "EFI mixed-mode support"
depends on EFI_STUB && X86_64
Quoted 17 lines · Thomas Bächler
Am 14.04.2014 09:15, schrieb Ingo Molnar:
Quoted 16 lines
Quoted 15 lines
Quoted 3 lines
Right, it is really that it is not possible to boot a mixed-mode kernel on its non-native firmware using the stub, since the stub itself can only be one way or the other.
Yeah, my help text was a bit... unhelpful.
CONFIG_EFI_MIXEDdoes not introduce a regression of any sort, you can enable it without worrying about that.All the boot configurations that used to work will continue to work.
What I meant to say was that it isn't possible to use the EFI mixed *feature* (booting a 64-bit kernel with 32-bit firmware) with the EFI boot stub - so you can build support into your kernel but there's no way to make the CPU actually execute those code paths.
Quoted 9 lines
Quoted 2 lines
Same goes for booting a 32-bit kernel on 64-bit firmware, right?
It seems that isn't implemented:
config
EFI_MIXED
bool "EFI mixed-mode support"
depends onEFI_STUB&&X86_64
Correct, since that would require translating 64-bit pointers from the firmware into 32-bit pointers for the kernel, which isn't as straight forward as the 32-bit firmware / 64-bit kernel case, i.e. ensure all allocations are < 4GB and truncate 64-bit pointers when they're passed to the firmware.
That and the fact that no one has said "We really need support".
Signature · 1 line
Matt Fleming, Intel Open Source Technology Center
Borislav Petkov
maintainerQuoted 1 line · Matt Fleming
That and the fact that no one has said "We really need support".
Don't be putting words in people's mouths :-)
Signature · 5 lines
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--