On 17/07/2025 8:35 am, Jan Beulich wrote:
> On 16.07.2025 19:31, Andrew Cooper wrote:
>> mwait-idle's ICPU() is the most convenient place to get started. Introduce
>> X86_MATCH_CPU() and X86_MATCH_VFM() following their Linux counterparts.
>>
>> This involves match-cpu.h including more headers, which in turn allows us to
>> drop a few.
> intel-cpu.h doesn't really need to move, does it? Conceivably there can be
> users
> of match-cpu.h which don't need the Intel constants. Hence no point in forcing
> them to see those.
There's no point not to. All users of x86_cpu_id want the Intel names.
I've already restricted it to only 5 TUs.
Even if we do get some AMD names (and I'm not entirely sure how that
would end up looking), it's just a few defines.
>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
>> ---
>> CC: Jan Beulich <jbeul...@suse.com>
>> CC: Roger Pau Monné <roger....@citrix.com>
>>
>> We now have X86_FEATURE_ANY and X86_FEATURE_ALWAYS as aliases of LM. Given
>> the contexts they're used in, I've left the naming as-is.
> What's wrong with sticking to ALWAYS, which we already have?
For alternatives, something like:
alternative("", "foo", X86_FEATURE_ALWAYS);
is correct in context. However:
X86_MATCH_?(..., X86_FEATURE_ALWAYS, ...);
is borderline grammatically wrong, and ANY is a better name to use.
~Andrew
