Re: [PATCH 4/6] arm64: use hw_pte_t for fixmap HW PTEs

[Ryan Roberts]

On 18/09/2026 21:00, David Hildenbrand (Arm) wrote:
> On 9/18/26 18:03, Ryan Roberts wrote:
>> On 14/09/2026 14:51, Muhammad Usama Anjum wrote:
>>> fixmap_pte() returns a pointer into bm_pte, and early_fixmap_init_pte()
>>> installs those arrays as page tables. Their elements are therefore
>>> HW PTEs.
>>>
>>> Change the element type of bm_pte to hw_pte_t so it matches the HW PTE
>>> pointers returned and passed to the accessors. This is needed before
>>> ARCH_HAS_HW_PTE_T makes HW PTEs and SW PTE values distinct types; the
>>> array dimensions and placement are unchanged.
>>>
>>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@xxxxxxx>
>>> ---
>>>  arch/arm64/mm/fixmap.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
>>> index 237a9136bc73b..709a97fe327d8 100644
>>> --- a/arch/arm64/mm/fixmap.c
>>> +++ b/arch/arm64/mm/fixmap.c
>>> @@ -31,7 +31,7 @@ static_assert(NR_BM_PMD_TABLES == 1);
>>>  
>>>  #define BM_PTE_TABLE_IDX(addr)	__BM_TABLE_IDX(addr, PMD_SHIFT)
>>>  
>>> -static pte_t bm_pte[NR_BM_PTE_TABLES][PTRS_PER_PTE] __bss_pgtbl;
>>> +static hw_pte_t bm_pte[NR_BM_PTE_TABLES][PTRS_PER_PTE] __bss_pgtbl;
>>
>> I think in my original proposal it was impossible to have a hw_pte value; only a
>> hw_pte pointer was possible. Being able to create hw_pte values means that it is
>> possible that a hw_pte_t pointer is not actually pointing to an entry in a HW
>> pgtable. The main motivation for this is that we want to dereference neighbours
>> of a hw pte based on it's pointer and be confident that it is safe. I think this
>> removes some of the safety.
> 
> If you follow some of the related discussions on the core-mm series, there is a
> path forward to go further into that direction.

OK, as long as we have a path to the "full" solution if we ever need it, then
sounds good to me.

> 
> People instantiating a hw_pte_t on the stack are not really a concern right now.
>