Re: Slow(er) loading of Grub starting after commit 887f98f0d

On Wed, Sep 07, 2022 at 06:21:07PM +0200, Daniel Kiper wrote: > Adding folks who may be interested in this... > > Sorry for delay but I was on vacation... > > Somehow related issue was reported here [1]... > > On Fri, Sep 02, 2022 at 01:45:28PM +0800, Gary Lin via Grub-devel wrote: > > On Thu, S

Re: [PATCH resend 8/9] efi: implement LoadFile2 initrd loading protocol for Linux

Hi Ard, On Thu, Aug 18, 2022 at 10:55:38AM +0200, Ard Biesheuvel wrote: > Recent Linux kernels will invoke the LoadFile2 protocol installed on > a well-known vendor media path to load the initrd if it is exposed by > the firmware. Using this method is preferred for two reasons: > - the Linux kerne

[PATCH v4 0/6] linux: implement LoadFile2 initrd loading

This implements the LoadFile2 initrd loading protocol, which is essentially a callback interface into the bootloader to load the initrd data into a caller provided buffer. This means the bootloader no longer has to contain any policy regarding where to load the initrd (which differs between archite

[PATCH v4 3/6] linux/arm: account for COFF headers appearing at unexpected offsets

The way we load the Linux and PE/COFF image headers depends on a fixed placement of the COFF header at offset 0x40 into the file. This is a reasonable default, given that this is where Linux emits it today. However, in order to comply with the PE/COFF spec, which allows this header to appear anywhe

[PATCH v4 1/6] efi: move MS-DOS stub out of generic PE header definition

The PE/COFF spec permits the COFF signature and file header to appear anywhere in the file, and the actual offset is recorded in 4 byte little endian field at offset 0x3c of the image. When GRUB is emitted as a PE/COFF binary, we reuse the 128 byte MS-DOS stub (even for non-x86 architectures), put

[PATCH v4 4/6] efi/efinet: Don't close connections at fini_hw() time

When GRUB runs on top of EFI firmware, it only has access to block and network device abstractions exposed by the firmware, and it is up to the firmware to quiesce the underlying hardware when exiting boot services and handing over to the OS. This is especially important for network devices, to pr

[PATCH v4 6/6] linux: ignore FDT unless we need to modify it

Now that we implemented support for the LoadFile2 protocol for initrd loading, there is no longer a need to pass the initrd parameters via the device tree. This means that when the LoadFile2 protocol is being used, there is no reason to update the device tree in the first place, and so we can ignor

[PATCH v4 5/6] efi: implement LoadFile2 initrd loading protocol for Linux

Recent Linux kernels will invoke the LoadFile2 protocol installed on a well-known vendor media path to load the initrd if it is exposed by the firmware. Using this method is preferred for two reasons: - the Linux kernel is in charge of allocating the memory, and so it can implement any placement

[PATCH v4 2/6] linux/arm: unify ARM/arm64 vs Xen PE/COFF header handling

Xen has its own version of the image header, to account for the additional PE/COFF header fields. Since we are adding references to those in the shared EFI loader code, update the common definitions and drop the Xen specific one which no longer has a purpose. Signed-off-by: Ard Biesheuvel --- gr

Re: Slow(er) loading of Grub starting after commit 887f98f0d

On Thu, Sep 08, 2022 at 03:49:03PM +0800, Gary Lin wrote: > On Wed, Sep 07, 2022 at 06:21:07PM +0200, Daniel Kiper wrote: > > Adding folks who may be interested in this... > > > > Sorry for delay but I was on vacation... > > > > Somehow related issue was reported here [1]... > > > > On Fri, Sep 02,