On Mon, Aug 21, 2023 at 09:51:13PM +0200, Vladimir 'phcoder' Serbinenko wrote: > I think we need to start having options to specify which entry to use. E.g > linux --no-efi-stub /vmlinuz > This is probably needed to support other users of Linux protocol
If somebody needs that thing they can add it later. For now Reviewed-by: Daniel Kiper <daniel.ki...@oracle.com>... Though... > Le lun. 21 août 2023, 20:12, Ard Biesheuvel <a...@kernel.org> a écrit : > On Thu, 3 Aug 2023 at 15:24, Ard Biesheuvel <a...@kernel.org> wrote: > > > > The x86_64 Linux kernel can be booted in 32-bit mode, in which case > the > > startup code creates a set of preliminary page tables that map the > first > > 1GiB of physical memory 1:1, and enables paging. This is a > prerequisite > > for 64-bit execution, and can therefore only be implemented in 32- > bit > > code. > > > > The x86_64 Linux kernel can also be booted in 64-bit mode directly: > this > > implies that paging is already enabled, and it is the > responsibility of > > the bootloader to ensure that the the active page tables cover the > > entire loaded image, including its BSS space, the size of which is > > described in the image's setup header. > > > > Given that the EFI spec mandates execution in long mode for x86_64, > and > > stipulates that all system memory is mapped 1:1, the Linux/x86 > > requirements for 64-bit entry can be met trivially when booting on > > x86_64 via EFI. So enter via the 64-bit entrypoint in this case. > > > > This involves inspecting the xloadflags field in the setup header > to > > check whether the 64-bit entrypoint is supported. This field was > > introduced in Linux version v3.8 (early 2013) > > > > This change ensures that all EFI firmware tables and other assets > passed > > by the firmware or bootloader in memory remain mapped and > accessible > > throughout the early startup code. (Note that Linux's 32-bit > startup > > code creates multiple shadow mappings of the first 1GiB of physical > > memory up to the 4 GiB mark so anything that resides there becomes > > inaccessible until the 64-bit startup code replaces the preliminary > > mappings with more accurate ones) > > > > Avoiding the drop out of long mode will also be needed to support > > upcoming CPU designs that no longer implement 32-bit mode at all > (as > > recently announced by Intel [0]) > > > > [0] https://www.intel.com/content/www/us/en/developer/articles/ > technical/envisioning-future-simplified-architecture.html > > > > Cc: Daniel Kiper <daniel.ki...@oracle.com> > > Cc: Julian Andres Klode <julian.kl...@canonical.com> > > Signed-off-by: Ard Biesheuvel <a...@kernel.org> > > Ping? > > > --- > > grub-core/loader/i386/linux.c | 12 ++++++++++++ > > include/grub/i386/linux.h | 15 +++++++++++++-- > > 2 files changed, 25 insertions(+), 2 deletions(-) > > > > diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/ > linux.c > > index 997647a33326eeb8..a83cc52a656d587b 100644 > > --- a/grub-core/loader/i386/linux.c > > +++ b/grub-core/loader/i386/linux.c > > @@ -624,6 +624,18 @@ grub_linux_boot (void) > > } > > #endif > > > > +#if defined (GRUB_MACHINE_EFI) && defined (__x86_64__) ... I would put "defined (__x86_64__)" first in the condition. I can make it for you before push. Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
