Re: [RFC PATCH 00/11] x86 vendor check optimisations

[Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>]

On Thu Nov 27, 2025 at 11:11 PM CET, Andrew Cooper wrote:
> On 26/11/2025 4:44 pm, Alejandro Vallejo wrote:
>> Just knowing x86_vendor_is() is "good to have" is good enough as it enables 
>> our
>> downstream to customise it with whatever optimisations we need.
>>
>> I also suspect other areas of the hypervisor could benefit from this meld of
>> runtime+compiletime sort of checking, allowing transparent code removal.
>>
>> I'm thinking DOM0LESS_BOOT vs DOM0_BOOT vs PVSHIM_BOOT, or AMD_SVM vs 
>> INTEL_VMX
>> in HVM-only builds, or family checks to have (i.e) a explicit 
>> "older-than-zen"
>> Kconfig option with a similar approach on a family range check.
>>
>> This is maybe one of several such uses.
>>
>> So... thoughts? I'm definitely fond of the single-vendor bloat-o-meter 
>> output.
>
> Having looked through the whole series, I'm not a massive fan of
> converting the switch() statements, but it's the only way to do the
> DCE.  So be it.
>
> I think x86_vendor_is(var, MASK) wants to become boot_vendor(MASK).
>
> Most cases want the boot vendor, and those that appear to want something
> else don't actually.  When you disable the cross-vendor case (patch 2
> pulled out ahead), then cp->vendor == boot_vendor and then you don't
> need a variable to pass in.
>
> This also reduces the verbosity of the new lines which is an improvement.
>
>
> That said, this series also collides substantially with the Intel Fam
> 18/19 work, which is more urgent and needs backporting to 4.21.  More
> specifically, there are a bunch of changes which interfere with VFM
> conversion, and for which I can't see an obvious DCE reason to have, so
> I'm wondering if they were just part of "convert everything".
>
> ~Andrew

I converted everything under the sun because it's easier to find all of them
than the strict subset the will give me gains. It's also easier to have new
commits using the function when there are no seemingly random instances where
it's not used.

What's exactly the area you need to touch for the Fam 18/19 work? I can leave
that conversion for last in the series so you have time to push and backport.

It's quite likely not in an area of the tree I care deeply about.

Cheers,
Alejandro