On 2020-10-21 12:25, Greg Kroah-Hartman wrote:
On Wed, Oct 21, 2020 at 12:09:58PM +0100, Marc Zyngier wrote:
On 2020-10-21 11:46, Qais Yousef wrote:
> So that userspace can detect if the cpu has aarch32 support at EL0.
>
> CPUREGS_ATTR_RO() was renamed to CPUREGS_RAW_ATTR_RO() to better reflect
> what it does. And fixed to accept both u64 and u32 without causing the
> printf to print out a warning about mismatched type. This was caught
> while testing to check the new CPUREGS_USER_ATTR_RO().
>
> The new CPUREGS_USER_ATTR_RO() exports a Sanitised or RAW sys_reg based
> on a @cond to user space. The exported fields match the definition in
> arm64_ftr_reg so that the content of a register exported via MRS and
> sysfs are kept cohesive.
>
> The @cond in our case is that the system is asymmetric aarch32 and the
> controlling sysctl.enable_asym_32bit is enabled.
>
> Update Documentation/arm64/cpu-feature-registers.rst to reflect the
> newly visible EL0 field in ID_AA64FPR0_EL1.
>
> Note that the MRS interface will still return the sanitized content
> _only_.
>
> Signed-off-by: Qais Yousef <qais.yousef@xxxxxxx>
> ---
>
> Example output. I was surprised that the 2nd field (bits[7:4]) is
> printed out
> although it's set as FTR_HIDDEN.
>
> # cat /sys/devices/system/cpu/cpu*/regs/identification/id_aa64pfr0
> 0x0000000000000011
> 0x0000000000000011
> 0x0000000000000011
> 0x0000000000000011
> 0x0000000000000011
> 0x0000000000000011
>
> # echo 1 > /proc/sys/kernel/enable_asym_32bit
>
> # cat /sys/devices/system/cpu/cpu*/regs/identification/id_aa64pfr0
> 0x0000000000000011
> 0x0000000000000011
> 0x0000000000000012
> 0x0000000000000012
> 0x0000000000000011
> 0x0000000000000011
This looks like a terrible userspace interface.
It's also not allowed, sorry. sysfs is "one value per file", which is
NOT what is happening at all.
I *think* Qais got that part right, though it is hard to tell without
knowing how many CPUs this system has (cpu/cpu* is ambiguous).
M.
--
Jazz is not dead. It just smells funny...
