Re: [PATCH 1/2] aarch64: Remove HWCAP_CPUID from HWCAP_IMPORTANT

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

On 29/06/18 08:18, Siddhesh Poyarekar wrote:
> On 06/28/2018 11:52 PM, Szabolcs Nagy wrote:
> > This partially reverts
> >
> > commit f82e9672ad89ea1ef40bbe1af71478e255e87c5e
> > Author:     Siddhesh Poyarekar <siddhesh@sourceware.org>
> >
> >      aarch64: Allow overriding HWCAP_CPUID feature check using HWCAP_MASK
> >
> > The idea was to make it possible to disable cpuid based ifunc resolution
> > in glibc by changing the hwcap mask which the user could already control.
> >
> > However the hwcap mask has an orthogonal role: it specifies additional
> > library search paths for the dynamic linker.  So "cpuid" got added to
>
> I don't think that is correct[1]; I understood hwcap_mask to be a general tool that allows you to mask out hardware capabilities as needed and 
> the library search paths feature happens to be a user of this. Another user is elf_machine_matches_host in sparc code for example, which uses to 
> match the binary with supported hardware capabilities.

searching libraries in ".../cpuid" path or allowing cpuid
based ifunc dispatch are quite different requirements, when
HWCAP_CPUID is available i think those two should be possible
to control independently (especially since searching "cpuid"
is almost never wanted and the ifunc dispatch is almost always
wanted).

the generic code currently only uses the mask to affect the
library search path, the intention may be different, but my
statement is defacto true and i don't see a good reason to
reuse the mask for something else that may have conflicting
requirement.

> > Meanwhile there is a tunable to set the cpu explicitly so it is possible
> > to disable the cpuid based dispatch without using a hwcap mask:
>
> However, I'm not too attached to the hwcap_mask way of disabling CPUID, so removing the aarch64 check is OK with me.  It was a good quick option 
> to implement back when the tune.cpu tunable was not in (and they eventually went in together IIRC, so it was a moot point) but I agree that it 
> is redundant now.
>
> That said, it would be nice to hear from others (especially distro folks) since it may have been advertised as a way to disable the ifunc 
> selection.

ok, i will wait for feedback for a while, but if you don't
have an objection i consider this change safe.

> Siddhesh
>
> [1] I don't have the historical reference to assert that it is definitely wrong, so if you have one I'll happily correct myself.