[RFC PATCH] arm64: Expose physical/virtual address bits through cpuinfo

[RFC PATCH] arm64: Expose physical/virtual address bits through cpuinfo

[Kefeng Wang]

AArch64 support six types Physical Address range, permitted values
in ID_AA64MMFR0_EL1 are:
0000  32 bits, 4GB.
0001  36 bits, 64GB.
0010  40 bits, 1TB.
0011  42 bits, 4TB.
0100  44 bits, 16TB.
0101  48 bits, 256TB.
All other values are reserved.

Meanwhile, AArch64 allows 36-bit, 39-bit, 42-bit, 47-bit and 48-bit
virtual addresses.

Exposing the physical and virtual address bits to userspace through
procfs like x86, then it is easy to check them from cpuinfo.

Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
 arch/arm64/include/asm/cpufeature.h | 11 +++++++++++
 arch/arm64/kernel/cpuinfo.c         |  4 +++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index a5c769b..33a9dc5 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -188,6 +188,17 @@ static inline bool system_supports_mixed_endian_el0(void)
 	return id_aa64mmfr0_mixed_endian_el0(read_system_reg(SYS_ID_AA64MMFR0_EL1));
 }
 
+static inline int id_aa64mmfr0_parange_bits(void)
+{
+	/*
+	 * PARange[3:0] allows 0~5, other values are reserved,
+	 * convert to physical address bits with a simple formula.
+	 */
+	u32 parange = read_system_reg(SYS_ID_AA64MMFR0_EL1) & 0xf;
+
+	return parange < 3 ? 32 + parange * 4 : 42 + (parange - 3) * (parange - 2);
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 212ae63..f6b49db 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -146,7 +146,9 @@ static int c_show(struct seq_file *m, void *v)
 		seq_printf(m, "CPU architecture: 8\n");
 		seq_printf(m, "CPU variant\t: 0x%x\n", MIDR_VARIANT(midr));
 		seq_printf(m, "CPU part\t: 0x%03x\n", MIDR_PARTNUM(midr));
-		seq_printf(m, "CPU revision\t: %d\n\n", MIDR_REVISION(midr));
+		seq_printf(m, "CPU revision\t: %d\n", MIDR_REVISION(midr));
+		seq_printf(m, "address sizes\t: %d bits physical, %d bits virtual\n\n",
+			   id_aa64mmfr0_parange_bits(), VA_BITS);
 	}
 
 	return 0;
-- 
1.7.12.4

[RFC PATCH] arm64: Expose physical/virtual address bits through cpuinfo

[Suzuki K. Poulose]

On 17/03/16 10:08, Kefeng Wang wrote:
> AArch64 support six types Physical Address range, permitted values
> in ID_AA64MMFR0_EL1 are:
> 0000  32 bits, 4GB.
> 0001  36 bits, 64GB.
> 0010  40 bits, 1TB.
> 0011  42 bits, 4TB.
> 0100  44 bits, 16TB.
> 0101  48 bits, 256TB.
> All other values are reserved.
>
> Meanwhile, AArch64 allows 36-bit, 39-bit, 42-bit, 47-bit and 48-bit
> virtual addresses.

See below..

>
> +static inline int id_aa64mmfr0_parange_bits(void)
> +{
> +	/*
> +	 * PARange[3:0] allows 0~5, other values are reserved,
> +	 * convert to physical address bits with a simple formula.
> +	 */
> +	u32 parange = read_system_reg(SYS_ID_AA64MMFR0_EL1) & 0xf;
> +
> +	return parange < 3 ? 32 + parange * 4 : 42 + (parange - 3) * (parange - 2);

This breaks for 52bit PA support added in ARMv8.2 [1]. It may be a good idea
to use an array here.

> +}
> +
>   #endif /* __ASSEMBLY__ */
>
>   #endif
> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index 212ae63..f6b49db 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -146,7 +146,9 @@ static int c_show(struct seq_file *m, void *v)
>   		seq_printf(m, "CPU architecture: 8\n");
>   		seq_printf(m, "CPU variant\t: 0x%x\n", MIDR_VARIANT(midr));
>   		seq_printf(m, "CPU part\t: 0x%03x\n", MIDR_PARTNUM(midr));
> -		seq_printf(m, "CPU revision\t: %d\n\n", MIDR_REVISION(midr));
> +		seq_printf(m, "CPU revision\t: %d\n", MIDR_REVISION(midr));
> +		seq_printf(m, "address sizes\t: %d bits physical, %d bits virtual\n\n",
> +			   id_aa64mmfr0_parange_bits(), VA_BITS);

VA_BITS is an attribute of your running kernel and doesn't have anything to do with what
the CPU can support. (e.g, it is 48bit on 8.0, 8.1, but could go upto 52 in 8.2)

[1] https://community.arm.com/groups/processors/blog/2016/01/05/armv8-a-architecture-evolution

Also, I am not sure if the change above would break userspace parsing the info. Ideally
it shouldn't , but...

Thanks
Suzuki

[RFC PATCH] arm64: Expose physical/virtual address bits through cpuinfo

[Kefeng Wang]

On 2016/3/17 19:31, Suzuki K. Poulose wrote:
> On 17/03/16 10:08, Kefeng Wang wrote:
>> AArch64 support six types Physical Address range, permitted values
[...]
>> +static inline int id_aa64mmfr0_parange_bits(void)
>> +{
>> +    /*
>> +     * PARange[3:0] allows 0~5, other values are reserved,
>> +     * convert to physical address bits with a simple formula.
>> +     */
>> +    u32 parange = read_system_reg(SYS_ID_AA64MMFR0_EL1) & 0xf;
>> +
>> +    return parange < 3 ? 32 + parange * 4 : 42 + (parange - 3) * (parange - 2);
> 
> This breaks for 52bit PA support added in ARMv8.2 [1]. It may be a good idea
> to use an array here.

Thanks for your reminder, will use array.

> 
>> +}
>> +
>>   #endif /* __ASSEMBLY__ */
>>
>>   #endif
>> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
>> index 212ae63..f6b49db 100644
>> --- a/arch/arm64/kernel/cpuinfo.c
>> +++ b/arch/arm64/kernel/cpuinfo.c
>> @@ -146,7 +146,9 @@ static int c_show(struct seq_file *m, void *v)
>>           seq_printf(m, "CPU architecture: 8\n");
>>           seq_printf(m, "CPU variant\t: 0x%x\n", MIDR_VARIANT(midr));
>>           seq_printf(m, "CPU part\t: 0x%03x\n", MIDR_PARTNUM(midr));
>> -        seq_printf(m, "CPU revision\t: %d\n\n", MIDR_REVISION(midr));
>> +        seq_printf(m, "CPU revision\t: %d\n", MIDR_REVISION(midr));
>> +        seq_printf(m, "address sizes\t: %d bits physical, %d bits virtual\n\n",
>> +               id_aa64mmfr0_parange_bits(), VA_BITS);
> 
> VA_BITS is an attribute of your running kernel and doesn't have anything to do with what
> the CPU can support. (e.g, it is 48bit on 8.0, 8.1, but could go upto 52 in 8.2)

After check the new id register id_aa64mmfr2 in armv8.2, I think we can use the LVA(larger
virtual address) bit of id_aa64mmfr2 to get virtual address bits supported by cpu, what's
opinion?

BTW, is it allowed to post patch by me to add more field of id_aa64mmfr2, if not, please let
me know, thanks.

BRs,
Kefeng

> 
> [1] https://community.arm.com/groups/processors/blog/2016/01/05/armv8-a-architecture-evolution
> 
> Also, I am not sure if the change above would break userspace parsing the info. Ideally
> it shouldn't , but...
> 
> Thanks
> Suzuki
> 
> .
> 

[RFC PATCH] arm64: Expose physical/virtual address bits through cpuinfo

[Suzuki K. Poulose]

On 18/03/16 05:47, Kefeng Wang wrote:
>
>
> On 2016/3/17 19:31, Suzuki K. Poulose wrote:
>> On 17/03/16 10:08, Kefeng Wang wrote:
>>> AArch64 support six types Physical Address range, permitted values
> [...]
>>> +static inline int id_aa64mmfr0_parange_bits(void)
>>
>> VA_BITS is an attribute of your running kernel and doesn't have anything to do with what
>> the CPU can support. (e.g, it is 48bit on 8.0, 8.1, but could go upto 52 in 8.2)
>
> After check the new id register id_aa64mmfr2 in armv8.2, I think we can use the LVA(larger
> virtual address) bit of id_aa64mmfr2 to get virtual address bits supported by cpu, what's
> opinion?

Thats the only way to do it.

>
> BTW, is it allowed to post patch by me to add more field of id_aa64mmfr2,

Of course. Also, since we use read_system_reg(), the values (pa and va width) won't change
across the CPUs. Hence, you may avoid multiple extraction routines and reuse the
results for one iteration.

Cheers
Suzuki

[RFC PATCH] arm64: Expose physical/virtual address bits through cpuinfo

[Catalin Marinas]

On Thu, Mar 17, 2016 at 06:08:03PM +0800, Kefeng Wang wrote:
> AArch64 support six types Physical Address range, permitted values
> in ID_AA64MMFR0_EL1 are:
> 0000  32 bits, 4GB.
> 0001  36 bits, 64GB.
> 0010  40 bits, 1TB.
> 0011  42 bits, 4TB.
> 0100  44 bits, 16TB.
> 0101  48 bits, 256TB.
> All other values are reserved.
> 
> Meanwhile, AArch64 allows 36-bit, 39-bit, 42-bit, 47-bit and 48-bit
> virtual addresses.
> 
> Exposing the physical and virtual address bits to userspace through
> procfs like x86, then it is easy to check them from cpuinfo.

So, what does user space need such information for?

-- 
Catalin

[RFC PATCH] arm64: Expose physical/virtual address bits through cpuinfo

[Kefeng Wang]

On 2016/3/18 20:13, Catalin Marinas wrote:
> On Thu, Mar 17, 2016 at 06:08:03PM +0800, Kefeng Wang wrote:
>> AArch64 support six types Physical Address range, permitted values
>> in ID_AA64MMFR0_EL1 are:
>> 0000  32 bits, 4GB.
>> 0001  36 bits, 64GB.
>> 0010  40 bits, 1TB.
>> 0011  42 bits, 4TB.
>> 0100  44 bits, 16TB.
>> 0101  48 bits, 256TB.
>> All other values are reserved.
>>
>> Meanwhile, AArch64 allows 36-bit, 39-bit, 42-bit, 47-bit and 48-bit
>> virtual addresses.
>>
>> Exposing the physical and virtual address bits to userspace through
>> procfs like x86, then it is easy to check them from cpuinfo.
> 
> So, what does user space need such information for?

For now, no user app use this, it just shows the physical/virtual address size
that is supported by cpu.

AArch64 supports several different types of physical/virtual address bits(up to 52bit
in ARMv8.2 especially), I think it's better to expose it, and cpuinfo is proper space.