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 = ¤t_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
