Re: [PATCH 08/12] x86/acpi: Migrate vendor checks to cpu_vendor()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.02.2026 16:34, Alejandro Vallejo wrote:
> On Thu Feb 12, 2026 at 12:52 PM CET, Jan Beulich wrote:
>> On 06.02.2026 17:15, Alejandro Vallejo wrote:
>>> --- a/xen/arch/x86/acpi/cpu_idle.c
>>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>>> @@ -178,7 +178,7 @@ static void cf_check do_get_hw_residencies(void *arg)
>>>      struct cpuinfo_x86 *c = &current_cpu_data;
>>>      struct hw_residencies *hw_res = arg;
>>>  
>>> -    if ( c->x86_vendor != X86_VENDOR_INTEL || c->x86 != 6 )
>>> +    if ( !(cpu_vendor() & X86_VENDOR_INTEL) || c->x86 != 6 )
>>>          return;
>>>  
>>>      switch ( c->x86_model )
>>> @@ -915,8 +915,7 @@ void cf_check acpi_dead_idle(void)
>>>              mwait(cx->address, 0);
>>>          }
>>>      }
>>> -    else if ( (current_cpu_data.x86_vendor &
>>> -               (X86_VENDOR_AMD | X86_VENDOR_HYGON)) &&
>>> +    else if ( cpu_vendor() & (X86_VENDOR_AMD | X86_VENDOR_HYGON) &&
>>
>> While we certainly make that assumption, shouldn't you add explicit checks
>> that APs' vendors match the BSP's, in order to be able to also replace
>> current_cpu_data uses? Or do we have such a check, and I'm merely overlooking
>> it?
> 
> In generic_identify()
> 
>       c->x86_vendor = x86_cpuid_lookup_vendor(ebx, ecx, edx);
>       if (boot_cpu_data.x86_vendor != c->x86_vendor)
>               printk(XENLOG_ERR "CPU%u vendor %u mismatch against BSP %u\n",
>                      smp_processor_id(), c->x86_vendor,
>                      boot_cpu_data.x86_vendor);
> 
> But I'm not sure why this is not a panic() (I thought it was). Such check
> triggering can only mean a Hypervisor bug and a security hole.
> 
> Do you see a problem with s/printk/panic/ here?

Well, yes and no. If we settle on the other panic() to remain, maybe this one
would be okay-ish, too. Otoh anything in AP bringup would better not panic,
but simply fail onlining that particular CPU.

Jan