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

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

[Yu Peng]

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

Re: [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

Re: [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

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

[Lorenzo Pieralisi]

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