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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 21, 2020 at 12:46:46PM +0100, Marc Zyngier wrote:
> 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).

Ah, missed the '*' in the middle of that path, my fault.

But without documentation, it's impossible to know...

thanks,

greg k-h



[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux