From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 60784385C335 for ; Tue, 30 Aug 2022 11:11:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 60784385C335 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27UAh3hG028396; Tue, 30 Aug 2022 11:11:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pp1; bh=h6YfZ8h7LeQzmtZMul57dmCuSZPQ1N3ol4w3fWsZqAk=; b=fcR2PT5cHhFB6HYw21lPc30j04qZX30gqa1OtgPK4K4Z0PYJnwWo87SGtnUyzDX6ppAB cmekZHSE1d/GIsVNao9SLZ3eMaSI/oFokfIofgL7fuFMK0fCXaejoO2TWAId4Lmc2FpH EEywa2fjDL2MwMdghBT76nNb6uHh4wfKSQKMqE6lo55/CRRAp4qMyt4/X5H3H5cvRdSk rch4W2nTcMfAjICnWWlEh1SFrQ5ouR7JWvsxJOHaRojcnsvJVoI86B1exslXVTZBO9ut 378r66mLOK/AAew/0gwjp3Qtflqk6rwAcQx44TOfXRwQ4Qs6XhOJ4qo1IMeHYfkoWWbh Gg== Received: from ppma03fra.de.ibm.com (6b.4a.5195.ip4.static.sl-reverse.com [149.81.74.107]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3j9h1q0sx7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Aug 2022 11:11:12 +0000 Received: from pps.filterd (ppma03fra.de.ibm.com [127.0.0.1]) by ppma03fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 27UBANR0013835; Tue, 30 Aug 2022 11:11:10 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma03fra.de.ibm.com with ESMTP id 3j7aw8tn85-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Aug 2022 11:11:10 +0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 27UBB8Ba37093660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 30 Aug 2022 11:11:08 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F3669A4062; Tue, 30 Aug 2022 11:11:07 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D30DCA405C; Tue, 30 Aug 2022 11:11:07 +0000 (GMT) Received: from [9.152.222.232] (unknown [9.152.222.232]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 30 Aug 2022 11:11:07 +0000 (GMT) Message-ID: Date: Tue, 30 Aug 2022 13:11:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: Questions regarding manipulation of IFUNC selection and tunables like glibc.cpu.hwcap_mask Content-Language: en-US To: Szabolcs Nagy Cc: GNU C Library References: <90fa41e3-8d9b-d5c2-916a-3d54fc047e27@linux.ibm.com> From: Stefan Liebler In-Reply-To: Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: FXnW-G9jV9Ldc3cNPf9k7lejUdlBbmwO X-Proofpoint-ORIG-GUID: FXnW-G9jV9Ldc3cNPf9k7lejUdlBbmwO Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-30_06,2022-08-30_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 spamscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 suspectscore=0 phishscore=0 impostorscore=0 lowpriorityscore=0 clxscore=1011 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208300054 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 25/08/2022 12:47, Szabolcs Nagy wrote: > The 08/25/2022 11:54, Stefan Liebler via Libc-alpha wrote: >> on s390x, the IFUNC'ed functions or other hw-dependent code-paths are >> usually selected by either the HWCAPs or the facility-list retrieved via >> stfle-instruction. >> >> Now we need a possibility to manipulate the IFUNC selection. As the >> current IFUNC-resolvers always select the functions for the newest >> features, we only need a possibility to disable features. >> >> According to /manual/tunables.texi: >> @deftp Tunable glibc.cpu.hwcap_mask >> This tunable supersedes the @env{LD_HWCAP_MASK} environment variable and is >> identical in features. >> >> The @code{AT_HWCAP} key in the Auxiliary Vector specifies instruction set >> extensions available in the processor at runtime for some architectures. >> The >> @code{glibc.cpu.hwcap_mask} tunable allows the user to mask out those >> capabilities at runtime, thus disabling use of those extensions. >> @end deftp > > iirc LD_HWCAP_MASK was purely for the old hwcap based > lib path lookup. Okay. Thanks for clarification. This also fits to what I've seen in the sources. > >> But a small testprogram (see attached tst-ifunc-manipulation.c) shows >> that neither setting the environment variable >> GLIBC_TUNABLES="glibc.cpu.hwcap_mask=0" nor LD_HWCAP_MASK="0x0 >> influences the HWCAPs. >> >> On s390x, the IFUNC-resolvers get the HWCAPs as argument (the most other >> architectures don't have this argument). Other code-paths can get the >> HWCAPs via getauxval(AT_HWCAP). In both cases the HWCAPs are loaded from >> "GLRO(dl_hwcap)". See: > > i think hwcap_mask was not for completely hiding hwcaps > like that. Then at least for me, the description of glibc.cpu.hwcap_mask-tunables is misleading. > > maybe we need a mechanism for hiding too (can be useful > for testing), however since it is in userspace, the kernel > and hw will behave as if HWCAP is present which may be > observable even if the libc tries to hide it. Yes, you are right, the kernel/hw will not know anything about it. Somebody could just read the flags from /proc/cpuinfo, or other details from architecture-specific instructions. And even glibc would use at least the features which comes indirectly from the used architecture-level-set even if you mask out older ones. Thus you think just masking bits in GLRO(dl_hwcap) which would also influence getauxval(AT_HWCAP) is a bad idea? > > also if this is useful then we need hwcap2 mask too, Makes sense. > and allow using hwcap names like "glibc.cpu.hwcaps" does > on x86. For my purpose of manipulating the s390-glibc-internal IFUNCs/code-paths, I could implement a s390 version of "glibc.cpu.hwcaps" which allows to influence the selectors based on AT_HWCAP and stfle-bits in one tunable. As soon as AT_HWCAP2 is used on s390x, this tunables can also influence those features. For s390 it would also make sense to be able to set a baseline architecture-level and then enable further features like: GLIBC_TUNABLES="glibc.cpu.hwcaps=z14,vxe2" Of course the s390 version of "glibc.cpu.hwcaps" would not influence other libs/applications which are using getauxval(AT_HWCAP). What do you think about adding such a s390 version of "glibc.cpu.hwcaps" and reworking the s390-specific-selectors to use a special features-struct instead of GLRO(dl_hwcap)? > > > >> - >> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/s390/dl-irel.h;h=20e4887467d80a1b3f95da00bb98386e3eadfe47;hb=HEAD#l33 >> - >> https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/getauxval.c;h=714ce5bd62ec33c38356b187e6ec067b72b77afb;hb=HEAD#l32 >> >> >> Is it a bug or the intention that the HWCAP values are not influenced by >> glibc.cpu.hwcap_mask tunable? >> >> If it is a bug, would it be possible to apply the mask after >> __tunables_init() like this: >> GLRO(dl_hwcap) &= GET_HWCAP_MASK(); >> This would affect the IFUNC-resolver, getauxval(AT_HWCAP) and more (e.g. >> if lock-elision is available or not) on all architectures. This would >> also change the behavior of programs/libraries using getauxval(AT_HWCAP). >> >> As alternative, we could also introduce a new s390-specific tunable >> like: glibc.cpu.s390.hwcap_mask which influences only the s390-IFUNCS / >> s390-code-pathes within glibc. The behaviour of programs/libraries using >> getauxval(AT_HWCAP) is not changed. >> >> Independent of the HWCAPs, we need to introduce a new s390-specific >> tunable like glibc.cpu.s390.stfle_mask in order to influence the >> s390-IFUNCs within glibc which are dependent on the facility-list. >> >> Are there other hints? >> >> Thanks in advance, >> Stefan > >> #include >> #include >> #include >> >> /* Run with/without environment variables does not influence HWCAPs: >> >> GLIBC_TUNABLES="" >> LD_HWCAP_MASK="" >> HWCAPs passed as argument to ifunc-resolver: 0x67ffff >> HWCAPs from getauxval (AT_HWCAP): 0x67ffff >> >> GLIBC_TUNABLES="glibc.cpu.hwcap_mask=0" >> LD_HWCAP_MASK="" >> HWCAPs passed as argument to ifunc-resolver: 0x67ffff >> HWCAPs from getauxval (AT_HWCAP): 0x67ffff >> >> GLIBC_TUNABLES="" >> LD_HWCAP_MASK="0x0" >> HWCAPs passed as argument to ifunc-resolver: 0x67ffff >> HWCAPs from getauxval (AT_HWCAP): 0x67ffff >> */ >> >> static unsigned long global_hwcaps = 0; >> >> static int impl(void) >> { >> printf ("HWCAPs passed as argument to ifunc-resolver: 0x%lx\n", >> global_hwcaps); >> return 42; >> } >> static void *resolver(unsigned long hwcap) >> { >> global_hwcaps = hwcap; >> return impl; >> } >> int ifunc(void) __attribute__((ifunc("resolver"))); >> >> int >> main (void) >> { >> printf ("GLIBC_TUNABLES=\"%s\"\n", getenv ("GLIBC_TUNABLES") ? : ""); >> printf ("LD_HWCAP_MASK=\"%s\"\n", getenv ("LD_HWCAP_MASK") ? : ""); >> >> ifunc (); >> printf ("HWCAPs from getauxval (AT_HWCAP): 0x%lx\n", getauxval (AT_HWCAP)); >> >> return EXIT_SUCCESS; >> } >