Re: [PATCH v2 01/29] x86: treewide: Introduce x86_vendor_amd_or_hygon()

[H. Peter Anvin]

On March 17, 2025 11:11:11 AM PDT, Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
>On 3/17/25 10:48, Peter Zijlstra wrote:
>> On Mon, Mar 17, 2025 at 06:32:16PM +0100, Borislav Petkov wrote:
>>> On Mon, Mar 17, 2025 at 05:47:17PM +0100, Ahmed S. Darwish wrote:
>>>> The pattern to check if an x86 vendor is AMD or HYGON (or not both) is
>>>> pretty common.  Introduce x86_vendor_amd_or_hygon() at <asm/processor.h>
>>> So if we need to check "intel too", we do
>>>
>>> x86_vendor_amd_or_hygon_or_intel?
>>>
>>> Nah, this is silly.
>> Would it make more sense to have a Zen1 feature and check that instead?
>> 
>> Because, IIRC Hygon is simply a Zen1 copy.
>
>Some of them can just go away, I think. This, for instance:
>
>        if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
>            boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
>                return false;
>
>        if (cpu_feature_enabled(X86_FEATURE_ZEN))
>                return false;
>
>Do we even need a vendor check if we're checking X86_FEATURE_ZEN? Is
>someone setting X86_FEATURE_ZEN on Intel? ;)

Maybe having a vendor bitmask instead of (or as an alternative to) an enumeration wouldn't be a horrible idea. That way multiple arbitrary vendors can be tested with a single test instruction. It would be pretty crazy to have 32 x86 vendors, never mind 64, without a *dramatic* shift in the ecosystem (there are currently fewer than 32 registered RISC-V G implementations; that doesn't include the myriad of microcontroller class implementations that don't implement the full G [general purpose] feature set – but those are irrelevant for Linux.)

    -hpa