Recent platforms require more slack slots than the current value of
EFI_MMAP_NR_SLACK_SLOTS, otherwise they fail to boot. The current
workaround is to append `efi=disable_early_pci_dma` to the kernel's
cmdline. So, bump up EFI_MMAP_NR_SLACK_SLOTS to 32 to allow those
platforms to boot with the aforementioned workaround.

Cc: stable@kernel.org
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Allen Pais <apais@linux.microsoft.com>
Cc: Tyler Hicks <code@tyhicks.com>
Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
---
 drivers/firmware/efi/libstub/efistub.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 76e44c185f29..e95ce6ae5c26 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -171,7 +171,7 @@ void efi_set_u64_split(u64 data, u32 *lo, u32 *hi)
  * the EFI memory map. Other related structures, e.g. x86 e820ext, need
  * to factor in this headroom requirement as well.
  */
-#define EFI_MMAP_NR_SLACK_SLOTS	8
+#define EFI_MMAP_NR_SLACK_SLOTS	32
 
 typedef struct efi_generic_dev_path efi_device_path_protocol_t;
 
-- 
2.47.1

On Mon, 9 Dec 2024 at 19:20, Hamza Mahfooz
<hamzamahfooz@linux.microsoft.com> wrote:
>
> Recent platforms require more slack slots than the current value of
> EFI_MMAP_NR_SLACK_SLOTS, otherwise they fail to boot. The current
> workaround is to append `efi=disable_early_pci_dma` to the kernel's
> cmdline. So, bump up EFI_MMAP_NR_SLACK_SLOTS to 32 to allow those
> platforms to boot with the aforementioned workaround.
>
> Cc: stable@kernel.org
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Allen Pais <apais@linux.microsoft.com>
> Cc: Tyler Hicks <code@tyhicks.com>
> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
> ---
>  drivers/firmware/efi/libstub/efistub.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
> index 76e44c185f29..e95ce6ae5c26 100644
> --- a/drivers/firmware/efi/libstub/efistub.h
> +++ b/drivers/firmware/efi/libstub/efistub.h
> @@ -171,7 +171,7 @@ void efi_set_u64_split(u64 data, u32 *lo, u32 *hi)
>   * the EFI memory map. Other related structures, e.g. x86 e820ext, need
>   * to factor in this headroom requirement as well.
>   */
> -#define EFI_MMAP_NR_SLACK_SLOTS        8
> +#define EFI_MMAP_NR_SLACK_SLOTS        32
>
>  typedef struct efi_generic_dev_path efi_device_path_protocol_t;
>

Acked-by: Ard Biesheuvel <ardb@kernel.org>

On Tue, 10 Dec 2024 at 10:59, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Mon, 9 Dec 2024 at 19:20, Hamza Mahfooz
> <hamzamahfooz@linux.microsoft.com> wrote:
> >
> > Recent platforms require more slack slots than the current value of
> > EFI_MMAP_NR_SLACK_SLOTS, otherwise they fail to boot. The current
> > workaround is to append `efi=disable_early_pci_dma` to the kernel's
> > cmdline. So, bump up EFI_MMAP_NR_SLACK_SLOTS to 32 to allow those
> > platforms to boot with the aforementioned workaround.
> >
> > Cc: stable@kernel.org
> > Cc: Ard Biesheuvel <ardb@kernel.org>
> > Cc: Allen Pais <apais@linux.microsoft.com>
> > Cc: Tyler Hicks <code@tyhicks.com>
> > Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
> > ---
> >  drivers/firmware/efi/libstub/efistub.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
> > index 76e44c185f29..e95ce6ae5c26 100644
> > --- a/drivers/firmware/efi/libstub/efistub.h
> > +++ b/drivers/firmware/efi/libstub/efistub.h
> > @@ -171,7 +171,7 @@ void efi_set_u64_split(u64 data, u32 *lo, u32 *hi)
> >   * the EFI memory map. Other related structures, e.g. x86 e820ext, need
> >   * to factor in this headroom requirement as well.
> >   */
> > -#define EFI_MMAP_NR_SLACK_SLOTS        8
> > +#define EFI_MMAP_NR_SLACK_SLOTS        32
> >
> >  typedef struct efi_generic_dev_path efi_device_path_protocol_t;
> >
>
> Acked-by: Ard Biesheuvel <ardb@kernel.org>

I've queued this up for v6.14 now - once we are confident it does not
cause any regressions, we can backport it to stable branches too.