From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id C87C53B1B4DD for ; Fri, 7 Jul 2023 10:52:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C87C53B1B4DD 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 (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 367AfgOF022841 for ; Fri, 7 Jul 2023 10:52:58 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=1z7LS8KhGBB1qLUKhGZyu7Vp9ZAdyrxkbUB/OU8JEi0=; b=hJY+u/zsi8sO/8CAxTy6i4milZt89bXWuODiQ4Etyx1+UotutudS8m4Oct4iXce70Vu6 ckB6+xqJXer1LDR5yeTrbHhGUWZIm68LQ5p433ERUCSIPK/9N0MxRIDdH6H5q41xwJu2 7ObSp7Np7zqzu7bqSZ5plCtFljyVNGpZoepEnU4fx1wW99hnYtRtz6XRvgNO7c5pdsRX 5Td7PjSlvo3AN4KwIF5KdXvaTjWHZI1Q8nXTUojDe3oI0pmrRFrGjU7nKGXOdKvqE8p5 CfMZH6M/JNtEFpekFkUXHJFLsrWa9fDQaGLlcqaEb4CmAKIRRatQPMUVAt0dxLNL6Y54 wg== Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rpgu3rktm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 07 Jul 2023 10:52:58 +0000 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 367AK6l7030173 for ; Fri, 7 Jul 2023 10:52:57 GMT Received: from smtprelay03.wdc07v.mail.ibm.com ([9.208.129.113]) by ppma04dal.us.ibm.com (PPS) with ESMTPS id 3rjbs6d263-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 07 Jul 2023 10:52:57 +0000 Received: from smtpav06.dal12v.mail.ibm.com (smtpav06.dal12v.mail.ibm.com [10.241.53.105]) by smtprelay03.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 367AqsnH59441436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 7 Jul 2023 10:52:54 GMT Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 310E658055; Fri, 7 Jul 2023 10:52:54 +0000 (GMT) Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3CC8F58059; Fri, 7 Jul 2023 10:52:52 +0000 (GMT) Received: from [9.43.13.78] (unknown [9.43.13.78]) by smtpav06.dal12v.mail.ibm.com (Postfix) with ESMTP; Fri, 7 Jul 2023 10:52:51 +0000 (GMT) Message-ID: <2877a1be-84e2-00c1-1dff-c00d290a0af9@linux.ibm.com> Date: Fri, 7 Jul 2023 16:22:50 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v3] PowerPC: Influence cpu/arch hwcap features via GLIBC_TUNABLES. Content-Language: en-US To: Peter Bergner , libc-alpha@sourceware.org Cc: rajis@linux.ibm.com, Mahesh Bodapati References: <20230706122544.175643-1-bmahi496@linux.ibm.com> <67b984d4-211f-3116-828f-6b62700bb5b3@linux.ibm.com> From: MAHESH BODAPATI In-Reply-To: <67b984d4-211f-3116-828f-6b62700bb5b3@linux.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: vy9a2cT91xZAHEERHrJbKId74GAf_eax X-Proofpoint-GUID: vy9a2cT91xZAHEERHrJbKId74GAf_eax X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-07_06,2023-07-06_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 priorityscore=1501 malwarescore=0 clxscore=1015 phishscore=0 adultscore=0 spamscore=0 impostorscore=0 mlxlogscore=999 mlxscore=0 bulkscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2307070097 X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,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 07/07/23 2:35 am, Peter Bergner wrote: > On 7/6/23 7:25 AM, bmahi496@linux.ibm.com wrote: >> + /* Copy the features from dl_powerpc_cpu_features, which contains the >> + features provided by AT_HWCAP and AT_HWCAP2. */ >> + struct cpu_features *cpu_features = &GLRO(dl_powerpc_cpu_features); >> + unsigned long int tcbv_hwcap = cpu_features->hwcap; >> + unsigned long int tcbv_hwcap2 = cpu_features->hwcap2; > [snip] >> + else >> + { >> + /* Enable the features and also checking that no unsupported >> + features were enabled by user. */ >> + if (hwcap_tunables[i].id) >> + cpu_features->hwcap2 |= (tcbv_hwcap2 & hwcap_tunables[i].mask); >> + else >> + cpu_features->hwcap |= (tcbv_hwcap & hwcap_tunables[i].mask); >> + } > I don't see how this code can ever "add" new bits to cpu_features->hwcap > or cpu_features->hwcap2. We cache their values at the top of the loop > and then OR in the tunable mask, but only if they're not already set > in the cached values. If the tunable mask has a bit that isn't already > present in cpu_features->hwcap/cpu_features->hwcap2, we'll never set > them. It seems your code as is, can only ever remove bits from hwcap/hwcap2. > > Question for you or anyone else, is there a scenario where we can execute > our set_hwcaps tunable callback function where the set of HWCAP/2 feature > bits is a subset of the HWCAP/2 bits that the kernel passed to us? I don't see any scenario like that. It will be helpful when user set multiple entries of tunable. For example "-arch_3_1,-arch_3_00,-vsx,arch_3_00" here we have 2 entries of arch_3_00 where it's disabling at first place and enabling at second place. > > For example, could our set_hwcaps tunable callback function be called multiple > times in some scenario like via a fork or ??? If yes, then tcbv_hwcap and > tcbv_hwcap2 really should be set to the HWCAP/2 values the kernel gives us > and not some possibly modified version in cpu_features->hwcap/2. If no, then > I think we probably don't even need to support trying to enable/add bits to > the cpu_features->hwcap/2 masks at all, since we'd only try setting bits > that are already set or bits we're not supposed to set since they aren't > in the kernel's version of the hwcaps. > > > Peter > >