Re: [PATCH v3] PowerPC: Influence cpu/arch hwcap features via GLIBC_TUNABLES.

[Peter Bergner <bergner@linux.ibm.com>]

On 7/7/23 5:52 AM, MAHESH BODAPATI wrote:
> On 07/07/23 2:35 am, Peter Bergner wrote:
>> 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.

What I meant was that if you look at the bits in cpu_features->hwcap and
cpu_features->hwcap2 before this code is executed and their bits after,
you will not see any bits that are set that were not already set before.
That's what I mean by your code can only ever remove bits, not add new bits.
Your example above is just cleaning up dumb user usage, since that is
exactly equivalent (because our original mask is full-featured) to the user
instead saying "-arch_3_1,-vsx".  Ie, we only remove bits in the end.

Adhemerval confirmed that this code is only run once, so my concern that
your code can't add new bits to the hwcap masks isn't a problem, since
our hwcap masks start out full-featured and there is no way for them to
have hwcap bits removed before your code is executed. 

Peter