On 12.02.2026 13:02, Jan Beulich wrote:
> On 06.02.2026 17:15, Alejandro Vallejo wrote:
>> @@ -862,7 +861,7 @@ static void x86_mcinfo_apei_save(
>> memset(&m, 0, sizeof(struct mce));
>>
>> m.cpu = mc_global->mc_coreid;
>> - m.cpuvendor = boot_cpu_data.x86_vendor;
>> + m.cpuvendor = cpu_vendor();
>> m.cpuid = cpuid_eax(1);
>> m.socketid = mc_global->mc_socketid;
>> m.apicid = mc_global->mc_apicid;
>> @@ -964,7 +963,7 @@ static void cf_check __maybe_unused
>> do_mc_get_cpu_info(void *v)
>> &xcp->mc_ncores_active, &xcp->mc_nthreads);
>> xcp->mc_cpuid_level = c->cpuid_level;
>> xcp->mc_family = c->x86;
>> - xcp->mc_vendor = c->x86_vendor;
>> + xcp->mc_vendor = cpu_vendor();
>> xcp->mc_model = c->x86_model;
>> xcp->mc_step = c->x86_mask;
>> xcp->mc_cache_size = c->x86_cache_size;
>
> What we do internally is one thing. But what we report to the outside
> shouldn't
> be inaccurate, imo.
There may be an underlying issue here: For the former case, struct mce is an
entirely private definition, having in particular:
uint8_t cpuvendor; /* cpu vendor as encoded in system.h */
which pretty clearly was inherited from Linux, and hence was broken when we
disconnected our X86_VENDOR_* values from Linux'es (in 4.9).
For the latter case, xen_mc_logical_cpu_t is part of the Xen ABI, and hence
it got screwed not only as per above, but another time when we converted
X86_VENDOR_* values from enumeration-like to bitfield-like (in 4.13).
Question of course is - if there were any consumers, they may have followed
our breaking of things. So it's hard to tell whether fixing might do more
bad than good. (I'll make a fix nevertheless, just in case).
Jan
