Re: [PATCH v2 2/6] arm64: HWCAP: add support for AT_HWCAP2

From: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
To: Dave P Martin <Dave.Martin@arm.com>,
	Andrew Murray <Andrew.Murray@arm.com>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>, nd <nd@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 2/6] arm64: HWCAP: add support for AT_HWCAP2
Date: Fri, 22 Feb 2019 10:35:01 +0000	[thread overview]
Message-ID: <a3b8a7f1-983a-6d39-8100-88424dc05d6a@arm.com> (raw)
In-Reply-To: <20190221184500.GO16031@e103592.cambridge.arm.com>

On 21/02/2019 18:45, Dave P Martin wrote:
> For ABI purposes, we should take the opportunity to document the status
> of the currently unused bits.
> 
> For interoperation with the glibc ifunc resolver ABI, we may want to
> reserve a bit among AT_HWCAP [63:32] or AT_HWCAP2 [31:0] that will
> never be used by the kernel and always passed to userspace as 0.

if hwcap2 is introduced at bit 32, i'd expect the top 32 bits
of hwcap1 to be 0 on lp64 (and thus libc may use those bits
for something internally or in the ifunc abi).

> I'm envisaging code such as
> 
> 	foo resolver(unsigned long hwcaps, unsigned int num_at_hwcaps,
> 			unsigned long const *at_hwcaps)
> 	{
> 		if ((hwcaps & _GLIBC_EXTRA_HWCAPS) &&
> 				num_at_hwcaps >= 2 &&
> 				at_hwcaps[1] && HWCAP2_FOO)
> 			/* feature present */
> 	}
> 
> We would need that _GLIBC_EXTRA_HWCAPS to distinguish the second and
> third arguments from uninitialised junk that would be passed by older
> glibc versions.

yes, i plan to do such a change.

> Glibc might or might not choose to try and wegde AT_HWCAP2 in the top
> bits of the first argument instead of bits [63:32] of AT_HWCAP (which
> we expect to be zero for now, but could still be made reachable via the
> at_hwcaps pointer).

the public api via getauxval and hwcap macro defines
will not do tricks that break lp64 vs ilp32 portability.
(that would defeat the purpose of hwcap2)

> Coordination would be needed if glibc carries on using the
> <uapi/asm/hwcap.h> HWCAP{,2}_foo defines for here while doing tricks
> of this sort.
> 
> Szabolcs may have a view on whether this is needed / useful.

for now coordination is not needed, glibc does not
use uapi hwcap.h directly, but copies it and it won't
do tricks that change hwcap values anyway, only adds
one new flag for ifunc resolvers.

> If so, we should document any required guarantees now so that we don't
> accidentally violate them during future maintenance.  For the benefit
> of userspace folks, it may be a good idea to have some clear statement
> in Documentation/arm64/ also.

on lp64 glibc will expect hwcap top 32bit to be 0.
this can be changed in the future if we no longer
care about ilp32 and at that point we may need
some coordination between linux and glibc so
the ifunc resolver abi does not break.

> Because of the ABI implications here, if would also be good idea to copy
> the libc-alpha mailing list, and possibly also linux-api.

yes.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel