From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27098C43381 for ; Wed, 27 Mar 2019 15:24:26 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E8F222082F for ; Wed, 27 Mar 2019 15:24:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="SRB10Lng" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E8F222082F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fxrODH2dEvhCAAS7lBZH+HO98G6LaNPyEugEo+Zh6H0=; b=SRB10Lng8agjfH tH/0sXtDgkukwCyxZ0H219TKbiz3LXyKpM6p45DxcjEEPfAmMynENGeZxVGCDGpfVoV6VKx7lhlAC 9YQRF7BHp3UK/Ibe2jZGi+KD1T8j9aIz0pbu/O/GXnFOBsurQBrPBP3rgXelRKKlgApT8iIC2joOH eGypffYH0gEGnMsa7zBGO8Ug5y5G1QROjK3eF3GVfNbgk9pL0MuSTZjvwqv2JjlKxfWpqO5ntvpVa W0PJEZgrr7vdhJ3tTHQdKKwqDpNTlmPlv3W/BBoDjZzuq0MzjKGuZry0LqqRPTKhA65mLs6yDDD5B WY9kCyR4PmEdjqmCdxcQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h9APd-0003Bx-4P; Wed, 27 Mar 2019 15:24:21 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h9APZ-0003BK-Vi for linux-arm-kernel@lists.infradead.org; Wed, 27 Mar 2019 15:24:19 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 67EB080D; Wed, 27 Mar 2019 08:24:17 -0700 (PDT) Received: from localhost (unknown [10.37.6.20]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C5FB13F575; Wed, 27 Mar 2019 08:24:16 -0700 (PDT) Date: Wed, 27 Mar 2019 15:24:15 +0000 From: Andrew Murray To: Szabolcs Nagy Subject: Re: [PATCH v2 2/6] arm64: HWCAP: add support for AT_HWCAP2 Message-ID: <20190327152414.GF43527@e119886-lin.cambridge.arm.com> References: <1550751657-30252-1-git-send-email-andrew.murray@arm.com> <1550751657-30252-3-git-send-email-andrew.murray@arm.com> <20190221184500.GO16031@e103592.cambridge.arm.com> <20190327150224.GE43527@e119886-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190327150224.GE43527@e119886-lin.cambridge.arm.com> User-Agent: Mutt/1.10.1+81 (426a6c1) (2018-08-26) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190327_082418_030141_70A54227 X-CRM114-Status: GOOD ( 29.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , nd , Will Deacon , Dave P Martin , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Mar 27, 2019 at 03:02:25PM +0000, Andrew Murray wrote: > 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 > > > 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? How about this (in Documentation/arm64/elf_hwcaps.txt)? + + +4. Unused AT_HWCAP bits +----------------------- + +Each AT_HWCAP and AT_HWCAP2 entry provides for up to 32 hwcaps contained +in bits [31:0]. For interoperation with userspace we guarantee that the +top bits [63:32] of AT_HWCAP will always be returned as 0. Thanks, Andrew Murray > > Thanks, > > Andrew Murray > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel