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

[Alejandro Vallejo]

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?
>
> Jan

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?

Cheers,
Alejandro