[RFC] arm64: early_ioremap fails to map ACPI MADT on 64K pages

[Will Deacon]

+arm64 ACPI maintainers

On Wed, Jun 17, 2026 at 02:01:10PM +0800, Yu Peng wrote:
> I hit an early boot failure on an arm64 system built with 64K pages while
> parsing the ACPI MADT.
> 
> The failing system reports:
> 
>   PAGE_SIZE: 64K
>   MADT physical address: 0x5a7ae018
>   MADT length: 0x32094

The MADT isn't even 4k aligned, so why does the page size matter in this
case?

> The failure happens when acpi_table_parse_madt() calls into early_memremap()
> via __acpi_map_table(). The MADT itself is smaller than 256K, but its
> placement causes the early mapping to require 5 64K pages:
> 
>   offset within 64K page = 0x5a7ae018 & 0xffff = 0xe018
>   mapped range           = PAGE_ALIGN(0xe018 + 0x32094)
>                          = PAGE_ALIGN(0x400ac)
>                          = 0x50000
>   nrpages                = 0x50000 / 0x10000 = 5
> 
> On arm64, NR_FIX_BTMAPS is currently derived from a 256K per-slot budget:
> 
>   #define NR_FIX_BTMAPS        (SZ_256K / PAGE_SIZE)
> 
> So for 64K pages, NR_FIX_BTMAPS is 4. The mapping therefore fails the
> early_ioremap() check:
> 
>   if (WARN_ON(nrpages > NR_FIX_BTMAPS))
>           return NULL;
> 
> After that, MADT parsing fails and the boot continues with symptoms such as:
> 
>   ACPI: APIC not present
>   missing boot CPU MPIDR, not enabling secondaries
>   Kernel panic - not syncing: No interrupt controller found.
> 
> A firmware change can avoid this by placing MADT so that:
> 
>   (madt_phys & 0xffff) + madt_length <= SZ_256K
> 
> However, I do not think ACPI requires such placement, so this looks like a
> kernel-side robustness issue as well, especially on large arm64 systems where
> MADT can grow with CPU topology.
> 
> One possible kernel-side change is to increase the boot-time mapping budget for
> CONFIG_ARM64_64K_PAGES, for example using a 512K per-slot budget only in that
> configuration. I do not think this should be applied unconditionally to all
> page sizes, since the arm64 early fixmap code expects the boot-ioremap range
> to stay within one PMD.
> 
> Has anyone seen similar failures on arm64 64K systems?
> 
> Would maintainers prefer treating this as a firmware layout issue, or would
> increasing the early_ioremap budget for 64K pages be acceptable?

It think it boils down to what ACPI says about the alignment of the MADT.

Lorenzo?

Will