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

[Will Deacon]

On Wed, Oct 21, 2020 at 01:15:59PM +0100, Catalin Marinas wrote:
> On Wed, Oct 21, 2020 at 12:09:58PM +0100, Marc Zyngier wrote:
> > On 2020-10-21 11:46, Qais Yousef wrote:
> > > 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 exposes unrelated
> > features,
> 
> Not sure why the EL1 field ended up in here, that's not relevant to the
> user.
> 
> > and doesn't expose the single useful information that the kernel has:
> > the cpumask describing the CPUs supporting  AArch32 at EL0. Why not expose
> > this synthetic piece of information which requires very little effort from
> > userspace and doesn't spit out unrelated stuff?
> 
> I thought the whole idea is to try and avoid the "very little effort"
> part ;).
> 
> > Not to mention the discrepancy with what userspace gets while reading
> > the same register via the MRS emulation.
> > 
> > Granted, the cpumask doesn't fit the cpu*/regs/identification hierarchy,
> > but I don't think this fits either.
> 
> We already expose MIDR and REVIDR via the current sysfs interface. We
> can expand it to include _all_ the other ID_* regs currently available
> to user via the MRS emulation and we won't have to debate what a new
> interface would look like. The MRS emulation and the sysfs info should
> probably match, though that means we need to expose the
> ID_AA64PFR0_EL1.EL0 field which we currently don't.
> 
> I do agree that an AArch32 cpumask is an easier option both from the
> kernel implementation perspective and from the application usability
> one, though not as easy as automatic task placement by the scheduler (my
> first preference, followed by the id_* regs and the aarch32 mask, though
> not a strong preference for any).

If a cpumask is easier to implement and easier to use, then I think that's
what we should do. It's also then dead easy to disable if necessary by
just returning 0. The only alternative I would prefer is not having to
expose this information altogether, but I'm not sure that figuring this
out from MIDR/REVIDR alone is reliable.

Will