[RFC PATCH v2 4/4] arm64: Export id_aar64fpr0 via sysfs

Marc Zyngier maz at kernel.org
Wed Oct 21 07:46:46 EDT 2020


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 at arm.com>
>> > ---
>> >
>> > 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...



More information about the linux-arm-kernel mailing list