[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <69E94BB8-256A-49BB-AEDF-E2B034496A40@zytor.com>
Date: Fri, 08 Nov 2024 16:31:11 +0100
From: "H. Peter Anvin" <hpa@...or.com>
To: Sohil Mehta <sohil.mehta@...el.com>, Dave Hansen <dave.hansen@...el.com>,
x86@...nel.org, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Sean Christopherson <seanjc@...gle.com>,
Tony Luck <tony.luck@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/cpufeatures: Free up unused feature bits
On November 8, 2024 3:17:24 AM GMT+01:00, Sohil Mehta <sohil.mehta@...el.com> wrote:
>On 11/7/2024 5:12 PM, Dave Hansen wrote:
>> Sohil, go look at:
>>
>> # cat /sys/devices/system/cpu/modalias
>> cpu:type:x86,ven0000fam0006mod008C:feature:,0000,0001,0002,0003,0004,0005,0006,...
>>
>
>Thanks for the explanation. Peter's comment makes sense to me now.
>
>>
>> I sure hope we haven't been using too many of these synthetic features
>> in MODULE_DEVICE_TABLE()s, because we tend to move them around, but I
>> guess it's possible.
>
>I found at least one recent usage that matches this pattern.
>Look at commit cbcddaa33d7e ("perf/x86/rapl: Use CPUID bit on AMD and
>Hygon parts"). It defines a synthetic feature bit X86_FEATURE_RAPL and
>adds it to the rapl_model_match[] table.
>
> MODULE_DEVICE_TABLE(x86cpu, rapl_model_match);
>
>It almost seems like some of these bits are now ABI. We probably need to
>mark them and keep these mappings pinned to avoid future issues.
>Recycling these bits seems to be very common.
It was a really unfortunate choice of ABI design, especially since there already were name strings available...
Powered by blists - more mailing lists