From: Ryan Roberts <ryan.roberts@arm.com>

When CONFIG_ARM64_PA_BITS_52 is enabled, page table helpers __pte_to_phys()
and __phys_to_pte_val() are functions which return phys_addr_t and pteval_t
respectively as expected. But otherwise without this config being enabled,
they are defined as macros and their return types are implicit.

Until now this has worked out correctly as both pte_t and phys_addr_t data
types have been 64 bits. But with the introduction of 128 bit page tables,
pte_t becomes 128 bits. Hence this ends up with incorrect widths after the
conversions, which leads to compiler warnings.

Fix the warnings by explicitly casting to the correct type after doing the
conversion.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
This patch applies on v6.14-rc3

 arch/arm64/include/asm/pgtable.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 0b2a2ad1b9e8..1da2421c9a15 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -84,8 +84,8 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
 	return (phys | (phys >> PTE_ADDR_HIGH_SHIFT)) & PHYS_TO_PTE_ADDR_MASK;
 }
 #else
-#define __pte_to_phys(pte)	(pte_val(pte) & PTE_ADDR_LOW)
-#define __phys_to_pte_val(phys)	(phys)
+#define __pte_to_phys(pte)	((phys_addr_t)(pte_val(pte) & PTE_ADDR_LOW))
+#define __phys_to_pte_val(phys)	((pteval_t)(phys))
 #endif
 
 #define pte_pfn(pte)		(__pte_to_phys(pte) >> PAGE_SHIFT)
-- 
2.25.1

On Wed, Feb 19, 2025 at 09:26:46AM +0530, Anshuman Khandual wrote:
> From: Ryan Roberts <ryan.roberts@arm.com>
> 
> When CONFIG_ARM64_PA_BITS_52 is enabled, page table helpers __pte_to_phys()
> and __phys_to_pte_val() are functions which return phys_addr_t and pteval_t
> respectively as expected. But otherwise without this config being enabled,
> they are defined as macros and their return types are implicit.
> 
> Until now this has worked out correctly as both pte_t and phys_addr_t data
> types have been 64 bits. But with the introduction of 128 bit page tables,
> pte_t becomes 128 bits. Hence this ends up with incorrect widths after the
> conversions, which leads to compiler warnings.

Does 128-bit page table not imply 52-bit PAs?

> Fix the warnings by explicitly casting to the correct type after doing the
> conversion.

I think it would be simpler and clearer if we replaced the macros with
functions, such that __pte_to_phys() and __phys_to_pte_val() are
*always* functions.

That way it's easier to compar the CONFIG_ARM64_PA_BITS_52=y and
CONFIG_ARM64_PA_BITS_52=n versions, and the types are always explciit
for inputs and outputs, so there'd be less room for error and the
compiler can warn us of type safety issues in any configuration.

That and we can delete the comment block immediately above at the same
time.

Mark.

> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> This patch applies on v6.14-rc3
> 
>  arch/arm64/include/asm/pgtable.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 0b2a2ad1b9e8..1da2421c9a15 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -84,8 +84,8 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
>  	return (phys | (phys >> PTE_ADDR_HIGH_SHIFT)) & PHYS_TO_PTE_ADDR_MASK;
>  }
>  #else
> -#define __pte_to_phys(pte)	(pte_val(pte) & PTE_ADDR_LOW)
> -#define __phys_to_pte_val(phys)	(phys)
> +#define __pte_to_phys(pte)	((phys_addr_t)(pte_val(pte) & PTE_ADDR_LOW))
> +#define __phys_to_pte_val(phys)	((pteval_t)(phys))
>  #endif
>  
>  #define pte_pfn(pte)		(__pte_to_phys(pte) >> PAGE_SHIFT)
> -- 
> 2.25.1
> 
>

On 25/02/2025 12:32, Mark Rutland wrote:
> On Wed, Feb 19, 2025 at 09:26:46AM +0530, Anshuman Khandual wrote:
>> From: Ryan Roberts <ryan.roberts@arm.com>
>>
>> When CONFIG_ARM64_PA_BITS_52 is enabled, page table helpers __pte_to_phys()
>> and __phys_to_pte_val() are functions which return phys_addr_t and pteval_t
>> respectively as expected. But otherwise without this config being enabled,
>> they are defined as macros and their return types are implicit.
>>
>> Until now this has worked out correctly as both pte_t and phys_addr_t data
>> types have been 64 bits. But with the introduction of 128 bit page tables,
>> pte_t becomes 128 bits. Hence this ends up with incorrect widths after the
>> conversions, which leads to compiler warnings.
> 
> Does 128-bit page table not imply 52-bit PAs?

Not to my knowledge. For now the prototype code base is explicitly sticking to
48-bit PA and 44-bit VA (for initial simplicitly because that's the limit for 4
levels).

> 
>> Fix the warnings by explicitly casting to the correct type after doing the
>> conversion.
> 
> I think it would be simpler and clearer if we replaced the macros with
> functions, such that __pte_to_phys() and __phys_to_pte_val() are
> *always* functions.

Yeah, agreed. This was initially just a hack I did to get things working.

> 
> That way it's easier to compar the CONFIG_ARM64_PA_BITS_52=y and
> CONFIG_ARM64_PA_BITS_52=n versions, and the types are always explciit
> for inputs and outputs, so there'd be less room for error and the
> compiler can warn us of type safety issues in any configuration.
> 
> That and we can delete the comment block immediately above at the same
> time.
> 
> Mark.
> 
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> This patch applies on v6.14-rc3
>>
>>  arch/arm64/include/asm/pgtable.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index 0b2a2ad1b9e8..1da2421c9a15 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -84,8 +84,8 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
>>  	return (phys | (phys >> PTE_ADDR_HIGH_SHIFT)) & PHYS_TO_PTE_ADDR_MASK;
>>  }
>>  #else
>> -#define __pte_to_phys(pte)	(pte_val(pte) & PTE_ADDR_LOW)
>> -#define __phys_to_pte_val(phys)	(phys)
>> +#define __pte_to_phys(pte)	((phys_addr_t)(pte_val(pte) & PTE_ADDR_LOW))
>> +#define __phys_to_pte_val(phys)	((pteval_t)(phys))
>>  #endif
>>  
>>  #define pte_pfn(pte)		(__pte_to_phys(pte) >> PAGE_SHIFT)
>> -- 
>> 2.25.1
>>
>>

On Tue, Feb 25, 2025 at 01:00:40PM +0000, Ryan Roberts wrote:
> On 25/02/2025 12:32, Mark Rutland wrote:
> > On Wed, Feb 19, 2025 at 09:26:46AM +0530, Anshuman Khandual wrote:
> >> From: Ryan Roberts <ryan.roberts@arm.com>
> >>
> >> When CONFIG_ARM64_PA_BITS_52 is enabled, page table helpers __pte_to_phys()
> >> and __phys_to_pte_val() are functions which return phys_addr_t and pteval_t
> >> respectively as expected. But otherwise without this config being enabled,
> >> they are defined as macros and their return types are implicit.
> >>
> >> Until now this has worked out correctly as both pte_t and phys_addr_t data
> >> types have been 64 bits. But with the introduction of 128 bit page tables,
> >> pte_t becomes 128 bits. Hence this ends up with incorrect widths after the
> >> conversions, which leads to compiler warnings.
> > 
> > Does 128-bit page table not imply 52-bit PAs?
> 
> Not to my knowledge. For now the prototype code base is explicitly sticking to
> 48-bit PA and 44-bit VA (for initial simplicitly because that's the limit for 4
> levels).

Fair enough; info dump below, but hopefully nothing of consequence.

I assume that you're relying on the VMSAv9-128 PA bits [48:12] being in the
same place as in the VMSAv8-64 descriptors, and being handled by the same
PTE_ADDR_LOW mask that we use for CONFIG_ARM64_PA_BITS_52=n.

From a quick scan of ARM DDI 0487 L.a, the VMSAv9-128 translation table
descriptor format always contains a 56-bit PA (though PARange could be
smaller than that). Bits [51:49] are packed differently than in
VMSAv8-64 descriptors, and bits [55:52] are obviously new.

> >> Fix the warnings by explicitly casting to the correct type after doing the
> >> conversion.
> > 
> > I think it would be simpler and clearer if we replaced the macros with
> > functions, such that __pte_to_phys() and __phys_to_pte_val() are
> > *always* functions.
> 
> Yeah, agreed. This was initially just a hack I did to get things working.

Cool; sounds like we're aligned.

Mark.

On 25/02/2025 13:52, Mark Rutland wrote:
> On Tue, Feb 25, 2025 at 01:00:40PM +0000, Ryan Roberts wrote:
>> On 25/02/2025 12:32, Mark Rutland wrote:
>>> On Wed, Feb 19, 2025 at 09:26:46AM +0530, Anshuman Khandual wrote:
>>>> From: Ryan Roberts <ryan.roberts@arm.com>
>>>>
>>>> When CONFIG_ARM64_PA_BITS_52 is enabled, page table helpers __pte_to_phys()
>>>> and __phys_to_pte_val() are functions which return phys_addr_t and pteval_t
>>>> respectively as expected. But otherwise without this config being enabled,
>>>> they are defined as macros and their return types are implicit.
>>>>
>>>> Until now this has worked out correctly as both pte_t and phys_addr_t data
>>>> types have been 64 bits. But with the introduction of 128 bit page tables,
>>>> pte_t becomes 128 bits. Hence this ends up with incorrect widths after the
>>>> conversions, which leads to compiler warnings.
>>>
>>> Does 128-bit page table not imply 52-bit PAs?
>>
>> Not to my knowledge. For now the prototype code base is explicitly sticking to
>> 48-bit PA and 44-bit VA (for initial simplicitly because that's the limit for 4
>> levels).
> 
> Fair enough; info dump below, but hopefully nothing of consequence.
> 
> I assume that you're relying on the VMSAv9-128 PA bits [48:12] being in the
> same place as in the VMSAv8-64 descriptors, and being handled by the same
> PTE_ADDR_LOW mask that we use for CONFIG_ARM64_PA_BITS_52=n.

Yes that's what the prototype is doing for now.

> 
> From a quick scan of ARM DDI 0487 L.a, the VMSAv9-128 translation table
> descriptor format always contains a 56-bit PA (though PARange could be
> smaller than that). Bits [51:49] are packed differently than in
> VMSAv8-64 descriptors, and bits [55:52] are obviously new.

Indeed. But given we are running on a platform with 48 bit PA, the prototype
always treating [55:52] as 0 is not getting in the way of anything.

> 
>>>> Fix the warnings by explicitly casting to the correct type after doing the
>>>> conversion.
>>>
>>> I think it would be simpler and clearer if we replaced the macros with
>>> functions, such that __pte_to_phys() and __phys_to_pte_val() are
>>> *always* functions.
>>
>> Yeah, agreed. This was initially just a hack I did to get things working.
> 
> Cool; sounds like we're aligned.
> 
> Mark.

On 2/25/25 19:22, Mark Rutland wrote:
> On Tue, Feb 25, 2025 at 01:00:40PM +0000, Ryan Roberts wrote:
>> On 25/02/2025 12:32, Mark Rutland wrote:
>>> On Wed, Feb 19, 2025 at 09:26:46AM +0530, Anshuman Khandual wrote:
>>>> From: Ryan Roberts <ryan.roberts@arm.com>
>>>>
>>>> When CONFIG_ARM64_PA_BITS_52 is enabled, page table helpers __pte_to_phys()
>>>> and __phys_to_pte_val() are functions which return phys_addr_t and pteval_t
>>>> respectively as expected. But otherwise without this config being enabled,
>>>> they are defined as macros and their return types are implicit.
>>>>
>>>> Until now this has worked out correctly as both pte_t and phys_addr_t data
>>>> types have been 64 bits. But with the introduction of 128 bit page tables,
>>>> pte_t becomes 128 bits. Hence this ends up with incorrect widths after the
>>>> conversions, which leads to compiler warnings.
>>>
>>> Does 128-bit page table not imply 52-bit PAs?
>>
>> Not to my knowledge. For now the prototype code base is explicitly sticking to
>> 48-bit PA and 44-bit VA (for initial simplicitly because that's the limit for 4
>> levels).
> 
> Fair enough; info dump below, but hopefully nothing of consequence.
> 
> I assume that you're relying on the VMSAv9-128 PA bits [48:12] being in the
> same place as in the VMSAv8-64 descriptors, and being handled by the same
> PTE_ADDR_LOW mask that we use for CONFIG_ARM64_PA_BITS_52=n.
> 
>>From a quick scan of ARM DDI 0487 L.a, the VMSAv9-128 translation table
> descriptor format always contains a 56-bit PA (though PARange could be
> smaller than that). Bits [51:49] are packed differently than in
> VMSAv8-64 descriptors, and bits [55:52] are obviously new.
> 
>>>> Fix the warnings by explicitly casting to the correct type after doing the
>>>> conversion.
>>>
>>> I think it would be simpler and clearer if we replaced the macros with
>>> functions, such that __pte_to_phys() and __phys_to_pte_val() are
>>> *always* functions.
>>
>> Yeah, agreed. This was initially just a hack I did to get things working.
> 
> Cool; sounds like we're aligned.

Planning for the following respin instead.

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 0b2a2ad1b9e8..4ebfa60ea5c6 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -68,10 +68,6 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
 #define pte_ERROR(e)	\
 	pr_err("%s:%d: bad pte %016llx.\n", __FILE__, __LINE__, pte_val(e))
 
-/*
- * Macros to convert between a physical address and its placement in a
- * page table entry, taking care of 52-bit addresses.
- */
 #ifdef CONFIG_ARM64_PA_BITS_52
 static inline phys_addr_t __pte_to_phys(pte_t pte)
 {
@@ -84,8 +80,15 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
 	return (phys | (phys >> PTE_ADDR_HIGH_SHIFT)) & PHYS_TO_PTE_ADDR_MASK;
 }
 #else
-#define __pte_to_phys(pte)	(pte_val(pte) & PTE_ADDR_LOW)
-#define __phys_to_pte_val(phys)	(phys)
+static inline phys_addr_t __pte_to_phys(pte_t pte)
+{
+	return pte_val(pte) & PTE_ADDR_LOW;
+}
+
+static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
+{
+	return phys;
+}
 #endif
 
 #define pte_pfn(pte)		(__pte_to_phys(pte) >> PAGE_SHIFT)
-- 
2.30.2