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

[Hanjun Guo]

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

Thanks
Hanjun