Re: [PATCH 03/12] x86: Add cpu_vendor() as a wrapper for the host's CPU vendor

[Alejandro Vallejo <alejandro.garciavallejo@amd.com>]

On Wed Feb 11, 2026 at 6:35 PM CET, Alejandro Vallejo wrote:
> On Wed Feb 11, 2026 at 5:04 PM CET, Jan Beulich wrote:
>> On 06.02.2026 17:15, Alejandro Vallejo wrote:
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -328,7 +328,11 @@ void __init early_cpu_init(bool verbose)
>>>  	*(u32 *)&c->x86_vendor_id[4] = edx;
>>>  
>>>  	c->x86_vendor = x86_cpuid_lookup_vendor(ebx, ecx, edx);
>>> -	switch (c->x86_vendor) {
>>> +	if ( c->x86_vendor != cpu_vendor() )
>>
>> When we introduce new functions to Linux-style files, nowadays we take
>> the liberty and make them Xen-style right away. In entirely Linux-
>> style functions the style should remain consistently Linux'es, though.
>>
>
> Seeing how I added the tabs I did intend to do that.
>
> Muscle memory and all. Will correct on the next one.
>
>>> +		panic("CPU vendor not compiled-in: %s",
>>> +		      x86_cpuid_vendor_to_str(c->x86_vendor));
>>
>> This will be somewhat awkward when c->x86_vendor is UNKNOWN.
>
> Which only happens on virtualised or imaginary CPUs. In either case you know
> what you're running on and the information is not particularly useful. The
> important part is the "this hypervisor cannot run on your vendor. Enable it
> there".

Oh, wait. You meant when we run on an unknown CPU and the unknown path was
disabled? Yes, that's missing in the condition.

  if ((c->x86_vendor != cpu_vendor()) ||
      (!IS_ENABLED(CONFIG_UNKNOWN_CPU_VENDORS) && !c->x86_vendor))

A hunk got missed in refactors in the default case so that default_cpu got
dropped when the unknown vendor was missing. That was present originally in the
RFC.

Alejandro