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 C137EC43381 for ; Wed, 27 Mar 2019 15:02:37 +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 909952082F for ; Wed, 27 Mar 2019 15:02:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="N21U+rBV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 909952082F 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=jcGkYYvuDbVVNg4XRIcHHVYoDwKLCjxgmxWEVwDjD0E=; b=N21U+rBVGasQbm uO9a76AawZXqttGD0EMCp555YFhqKtybOpgjQwOhmWZDpW16c2uAqEiURkyFo+i3HBiZlYRUWTZNl cmDXjwDux7OFnpiMZZtxRw185ej7n2lDoA91nAKjdZySaPcM0M5ILiQhBeLH+X+HVrnq4nhoiGMbF ZjHgsxNS191MtS8fYz3vh8A+uLwm3OzyU6M0i+McToDBgPRDOrEXA6sGkd3qJquJQQZchmVpgv+a9 lBbBZdJrtZoxdS4e+UCDlbutEvOeLOajhQE9XE5IZplrzZS1ZFWG6qkaZ/cPx+kI7qOwhd9Spd63v ofdjx1CyGKE6L5hf5shQ==; 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 1h9A4W-0000RM-7r; Wed, 27 Mar 2019 15:02:32 +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 1h9A4S-0000QH-Jq for linux-arm-kernel@lists.infradead.org; Wed, 27 Mar 2019 15:02:30 +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 935DC1596; Wed, 27 Mar 2019 08:02:27 -0700 (PDT) Received: from localhost (unknown [10.37.6.20]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 274D13F575; Wed, 27 Mar 2019 08:02:26 -0700 (PDT) Date: Wed, 27 Mar 2019 15:02:25 +0000 From: Andrew Murray To: Szabolcs Nagy Subject: Re: [PATCH v2 2/6] arm64: HWCAP: add support for AT_HWCAP2 Message-ID: <20190327150224.GE43527@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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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_080228_667299_2F05CA86 X-CRM114-Status: GOOD ( 24.94 ) 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 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? Thanks, Andrew Murray _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel