[PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

[catalin.marinas@arm.com (Catalin Marinas)]

On Wed, Sep 02, 2015 at 05:21:24PM +0000, Pinski, Andrew wrote:
> On Sep 3, 2015, at 1:12 AM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Wed, Sep 02, 2015 at 10:52:05PM +0800, Andrew Pinski wrote:
> >> That is not a bad idea.  Put this array in the data section of the
> >> VDSO too.  It should be small enough though on systems with 96 or more
> >> cores (dual socket ThunderX has 96 cores total), it is slightly
> >> getting big.
> >> The struct would be something like:
> >> struct
> >> {
> >>  int32 numcores;
> >>  int32 midr[];
> >> };
> > 
> > First of all, I'm against hard-coding (VDSO) data as ABI. So far we used
> > VDSO to override some weak glibc functions but the VDSO-specific data is
> > parsed by the VDSO function implementation and not directly by glibc (or
> > user space). I prefer helper functions that read the VDSO-internal data
> > structures.
> 
> You don't like the idea of a fixed structure ABI that resides inside
> vdso data? Having a fixed struct ABI should be ok.  The location
> inside the data part was going to be passed via an aux vector entry.
> Userland does even need to know it is really located in the vdso at
> all. It just happens to reside in there. The data structure would be
> well defined for the aux vector. 

The problem is not necessarily the location of the data structure but
whether you are confident it has all the information you need and won't
require changing.

> > Secondly, you seem to be only interested in MIDR_EL1 but we also have
> > REVIDR_EL1 and AIDR_EL1 which may be relevant. Once we realise that more
> > information is needed, it's not always clear where the boundaries are
> > so I would rather have this exposed via /sys and/or MRS emulation (there
> > are patches for both).
> > 
> > Anyway, you need to involve the toolchain people in such discussions,
> > they may have different needs (like ifunc).
> 
> I am a toolchain person first and needed this in the first place for
> memset and memcpy on thunderx.

That's exactly my point. You only care about a micro-optimisation on
thunderx and a quick solution for this specific case. I care about the
wider ecosystem. I'm sure it won't be long before someone asks about
exposing AIDR_EL1 (REVIDR_EL1 was already requested), cache information,
big.LITTLE topology and so on.

We currently have patches to provide all the CPUID information we
_think_ is relevant to user space, though in different forms (/sys and
MRS emulation). As long as you cache such information in user space, the
overhead of a trapped MRS or /sys access is minimal.

-- 
Catalin