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

[Lorenzo Pieralisi <lpieralisi@kernel.org>]

On Mon, Jun 22, 2026 at 04:55:29PM +0800, Hanjun Guo wrote:
> On 2026/6/19 22:43, Will Deacon wrote:
> > +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?

First bug report I am aware of, perhaps this was papered over in FW,
MADT parsing failure is the first thing you would notice in bootstrapping
an ACPI system (FADT is not that big).

> > > 
> > > 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.
> 
> I checked the ACPI spec and it didn't require the alignment for ACPI
> tables, but in UEFI spec, it says (for aarch64):
> 
> ACPI Tables loaded at boot time can be contained in memory of type
> EfiACPIReclaimMemory (recommended) or EfiACPIMemoryNVS.
> 
> EFI memory descriptors of type EfiACPIReclaimMemory and EfiACPIMemoryNVS
> must be aligned on a 4 KiB boundary and must be a multiple of 4 KiB in
> size.
> 
> It only requires EfiACPIReclaimMemory type to be 4K aligned, not
> for each ACPI table, because ACPI tables can be packed into the
> allocated EfiACPIReclaimMemory type, correct me if I'm wrong!

I am afraid you are not wrong - we can't blame firmware (yet), this
has to be addressed.

Lorenzo