On Thu, 14 Sept 2023 at 18:31, Daniel Kiper <dki...@net-space.pl> wrote: > > 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. >
That's fine. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
