Re: [PATCH 00/12] const-ify vendor checks

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.02.2026 17:15, Alejandro Vallejo wrote:
> Hi,
> 
> This series is a big revamp of vendor-checking to enable it to perform DCE.
> It improves all configurations useful in practice at minimal cost in the full
> build, and at a massive advantage for the single-vendor case. Many ifdefs can
> go away as a side effect of the series.
> 
> This series depends on cross-vendor removal:
>   
> https://lore.kernel.org/xen-devel/20260205170923.38425-1-alejandro.garciavallejo@xxxxxxx/T/#m4c3d318f37e4f24d0f8c62b104221aa5d428cebc
> 
> Patch 1 in this series matches that of cross-vendor removal. It's logically
> required, but that's the single requirement.
> 
> High level description
> ======================
> 
> When compared to the RFC this makes a different approach The series introduces
> cpu_vendor() which maps to a constant in the single vendor case and to
> (boot_cpu_data.vendor & X86_ENABLED_VENDORS), where X86_ENABLED_VENDORS is a
> mask of the compile-time chosen vendors. This enables the compiler to detect
> dead-code at the uses and remove all unreachable branches, including in
> switches.
> 
> When compared to the x86_vendor_is() macro introduced in the RFC, this is
> simpler. It achieves MOST of what the older macro did without touching the
> switches, with a few caveats:
> 
>   1. Compiled-out vendors cause a panic, they don't fallback onto the unknown
>      vendor case. In retrospect, this is a much saner thing to do.

I'm unconvinced here. Especially our Centaur and Shanghai support is at best
rudimentary. Treating those worse when configured-out than when configured-in
feels questionable.

>   2. equalities and inequalities have been replaced by equivalent 
> (cpu_vendor() & ...)
>      forms. This isn't stylistic preference. This form allows the compiler
>      to merge the compared-against constant with X86_ENABLED_VENDORS, yielding
>      much better codegen throughout the tree.
> 
> The effect of (2) triples the delta in the full build below.
> 
> Some differences might be attributable to the change from policy vendor checks
> to boot_cpu_data. In the case of the emulator it caused a 400 bytes increase
> due to the way it checks using LOTS of macro invocations, so I left that one
> piece using the policy vendor except for the single vendor case.

For the emulator I'd like to point out this question that I raised in the
AVX10 series:

"Since it'll be reducing code size, we may want to further convert
 host_and_vcpu_must_have() to just vcpu_must_have() where appropriate
 (should be [almost?] everywhere)."

Sadly there was no feedback an that (or really on almost all of that work) at
all so far.

Jan