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

[Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>]

On Mon Feb 9, 2026 at 10:21 AM CET, Jan Beulich wrote:
> 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.

Isn't that the point of configuring out?

Besides the philosophical matter of whether or not a compiled-out vendor
should be allowed to run there's the more practical matter of what to do
with the x86_vendor field of boot_cpu_data. Because at that point our take
that cross-vendor support is forbidden is a lot weaker. If I can run an
AMD-hypervisor on an Intel host, what then? What policies would be allowed? If I
wipe x86_vendor then policies with some unknown vendor would be fine. Should the
leaves match too? If I do not wipe the field, should I do black magic to ensure
the behaviour is different depending on whether the vendor is compiled in or
not? What if I want to migrate a VM currently running in this hypothetical
hypervisor? The rules becomes seriously complex.

It's just a lot cleaner to take the stance that compiled out vendors can't run.
Then everything else is crystal clear and we avoid a universe's worth of corner
cases. I expect upstream Xen to support all cases (I'm skeptical about the
utility of the unknown vendor path, but oh well), but many downstreams might
benefit from killing off support for vendors they really will never touch.

>
>>   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:

There's no optimisation shortage for the emulator. For that patch I just
ensure I didn't make a tricky situation worse. It is much better in the 
single-vendor case.

>
> "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.

It sounds fairly orthogonal to this, unless I'm missing the point.

In principle that would be fine. the vCPU features whose emulation requires
special instructions are most definitely a subset of those of the host anyway.

I agree many cases could be simplified as you describe.

I do see a worrying danger of XSA should the max policy ever exceed the
capabilities of the host on a feature required for emulating some instruction
for that very feature. Then the guest could abuse the emulator to trigger #UD
inside the hypervisor's emulation path.

Cheers,
Alejandro