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

[Yu Peng <pengyu@kylinos.cn>]

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