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

From: Andrew Murray <andrew.murray@arm.com>
To: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>, nd <nd@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	Dave P Martin <Dave.Martin@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: Wed, 27 Mar 2019 15:02:25 +0000	[thread overview]
Message-ID: <20190327150224.GE43527@e119886-lin.cambridge.arm.com> (raw)
In-Reply-To: <a3b8a7f1-983a-6d39-8100-88424dc05d6a@arm.com>

On Fri, Feb 22, 2019 at 10:35:01AM +0000, Szabolcs Nagy wrote:
> 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.

I'll add documentation to Documentation/arm64 to indicate that the upper 32bits
of AT_HWCAP will always be 0. Is this correct? 

Thanks,

Andrew Murray

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