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

From: Yu Peng

Date: Wed Jun 17 2026 - 02:48:28 EST


Hi all,

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 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?

Thanks,
Yu Peng