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

[Yu Peng]

On 6/23/2026 8:07 PM, Will Deacon wrote:
> On Tue, Jun 23, 2026 at 10:47:12AM +0800, Yu Peng wrote:
> > Hi Lorenzo, Hanjun, Will,
> >
> > Thanks for confirming.
> >
> > I will send a proper patch for this. The change I plan to post is along
> > these lines:
> >
> > diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
> > index ... .. ...
> > --- a/arch/arm64/include/asm/fixmap.h
> > +++ b/arch/arm64/include/asm/fixmap.h
> > @@ -79,7 +79,11 @@ enum fixed_addresses {
> >   	 * Temporary boot-time mappings, used by early_ioremap(),
> >   	 * before ioremap() is functional.
> >   	 */
> > +#ifdef CONFIG_ARM64_64K_PAGES
> > +#define NR_FIX_BTMAPS		(SZ_512K / PAGE_SIZE)
> > +#else
> >   #define NR_FIX_BTMAPS		(SZ_256K / PAGE_SIZE)
> > +#endif
> >   #define FIX_BTMAPS_SLOTS	7
> >   #define TOTAL_FIX_BTMAPS	(NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)
>
> I still don't understand why this issue is specific to 64k pages, though.
>
> In the example you gave, the thing wasn't even 4k aligned.
>
> Will

You're right, this is not specific to 64K pages.

I looked at 64K first because the current slot is only 4 pages there,
compared with 64 pages on 4K. Any initial offset therefore leaves much
less room in the page-aligned span.

A blanket SZ_512K slot does not look right either. On 4K pages it would
make the boot-ioremap area 512K * 7 = 3.5M, while arm64 requires it to
stay within one PMD:

  /*
   * The boot-ioremap range spans multiple pmds, for which
   * we are not prepared:
   */
  BUILD_BUG_ON((__fix_to_virt(FIX_BTMAP_BEGIN) >> PMD_SHIFT)
	       != (__fix_to_virt(FIX_BTMAP_END) >> PMD_SHIFT));

So I think the better fix is to preserve the 256K payload budget and add
one page for the possible initial offset:

#define NR_FIX_BTMAPS		((SZ_256K / PAGE_SIZE) + 1)

That should allow any table up to 256K to be mapped regardless of its
initial offset, without exceeding the single-PMD constraint.

Does this direction sound reasonable?

Thanks,
Yu Peng