Re: [PATCH v1 08/14] x86: make CONFIG_EFI_STUB unconditional

["H. Peter Anvin" <hpa@zytor.com>]

On January 29, 2026 2:13:13 PM PST, Simon Glass <sjg@chromium.org> wrote:
>Hi Peter,
>
>On Tue, 27 Jan 2026 at 16:22, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> On January 26, 2026 7:14:27 PM PST, Simon Glass <sjg@chromium.org> wrote:
>> >Hi Peter,
>> >
>> >On Tue, 27 Jan 2026 at 15:55, H. Peter Anvin <hpa@zytor.com> wrote:
>> >>
>> >> On January 26, 2026 5:44:43 PM PST, Simon Glass <sjg@chromium.org> wrote:
>> >> >Hi Peter,
>> >> >
>> >> >On Tue, 27 Jan 2026 at 11:21, H. Peter Anvin <hpa@zytor.com> wrote:
>> >> >>
>> >> >> On 2026-01-26 13:19, Simon Glass wrote:
>> >> >> >>
>> >> >> >> Including the EFI stub doesn't mean using EFI to boot is required.
>> >> >> >
>> >> >> > Yes, understood, but it adds bloat. More importantly it will lead to
>> >> >> > people assuming that the stub is always used and thus unwittingly blur
>> >> >> > the boundary between the stub and the kernel itself.
>> >> >> >
>> >> >> > What is the actual need for this?
>> >> >> >
>> >> >>
>> >> >> I would argue that the opposite is more likely: someone inadvertently builds a
>> >> >> kernel without the stub, the bootloader goes down a legacy support path and
>> >> >> things seems to work... except for some platform subtleties.
>> >> >>
>> >> >> The bloat is there, but it is small and is only in the on-disk kernel image;
>> >> >> it is zero at runtime.
>> >> >>
>> >> >> As such, I don't think this option is a particularly good idea anymore. If
>> >> >> necessary, it could be hidden behind an EXPERT option, but I first wanted to
>> >> >> see who if anyone actually cares in a meaningful way to maintain this option.
>> >> >> Every option, after all, adds maintenance burden.
>> >> >>
>> >> >> Note that the BIOS stub is unconditionally compiled and included, and that has
>> >> >> not been an issue.
>> >> >
>> >> >What is the maintenance burden here? I could potentially take that on,
>> >> >but I would first want to understand what is involved.
>> >> >
>> >> >The use of the word 'legacy' worries me too. Is this patch a step
>> >> >towards removing the non-EFI path?
>> >> >
>> >> >Regards,
>> >> >Simon
>> >
>> >(joining the threads)
>> >
>> >> Bypassing the firmware stub (BIOS or EFI) is really only appropriate for special user cases, like kexec, because it removes the ability for the kernel to deal with system issues at an early point.
>> >
>> >Does this dealing happen in the EFI stub, or later? Are you referring
>> >to ACPI fix-ups or something else?
>> >
>> >>
>> >> However, kexec needs it, and it's not going to go away. However, that doesn't mean we should encourage this in cases which doesn't need it (no matter what the Grub maintainers tell you.)
>> >>
>> >> Now, if you are using KVM without EFI you are probably doing BIOS boot (regardless of if you know it or not), entering via the BIOS firmware stub.
>> >
>> >I am thinking of the 64-bit entry point to the kernel. everything
>> >being laid out in memory ready to go.
>> >
>> >>
>> >> I just realized you are the U-boot maintainer, so I'm assuming you are thinking of the case where there is no UEFI or BIOS firmware. In that case, just like as for kexec, the current entry point will continue to work, of course.
>> >>
>> >> What we don't want is having to suffer being on a BIOS or EFI system but not being able to leverage it for the benefit of the kernel. The kernel image is much easier to upgrade.
>> >
>> >More generally I am thinking about a simple and clean API for the
>> >kernel that doesn't involve having to provide 30K lines of firmware
>> >code just to boot. The BIOS entry point (if that is what it is called)
>> >is quite close to this ideal, even though I know it has shortcomings.
>> >
>> >Regards,
>> >Simon
>>
>> Yes, I understand.
>>
>> The 32/64-bit entrypoints aren't going away; it would be impossible to do so.
>>
>
>OK, so 'depend on EXPORT' seems good to me.
>
>> The general rule is: do things as late in the boot process as possible, but no later.
>>
>
>Just on this point, I wonder how we should define 'late', in the
>context of EFI. For example, if the kernel stub reads a file, meaning
>it calls back into Tianocore, it is using both early and late code.
>
>Regards,
>Simon

"Early" in this context is before ExitBootServices().