Re: [PATCH] x86/cpuid: Deal with broken firmware once more

[Charles (Chas) Williams]

On 11/10/2016 09:02 AM, Boris Ostrovsky wrote:
> On 11/10/2016 06:13 AM, Thomas Gleixner wrote:
> > On Thu, 10 Nov 2016, M. Vefa Bicakci wrote:
> >
> > > I have found that your patch unfortunately does not improve the situation
> > > for me. Here is an excerpt obtained from the dmesg of a kernel compiled
> > > with this patch *as well as* Sebastian's patch:
> > > [    0.002561] CPU: Physical Processor ID: 0
> > > [    0.002566] CPU: Processor Core ID: 0
> > > [    0.002572] [Firmware Bug]: CPU0: APIC id mismatch. Firmware: ffff CPUID: 2
> > So apic->cpu_present_to_apicid() gives us a completely bogus APIC id which
> > translates to a bogus package id. And looking at the XEN code:
> >
> >    xen_pv_apic.cpu_present_to_apicid = xen_cpu_present_to_apicid,
> >
> > and xen_cpu_present_to_apicid does:
> >
> > static int xen_cpu_present_to_apicid(int cpu)
> > {
> >         if (cpu_present(cpu))
> >                 return xen_get_apic_id(xen_apic_read(APIC_ID));
> >         else
> >                 return BAD_APICID;
> > }
> >
> > So independent of which present CPU we query we get just some random
> > information, in the above case we get BAD_APICID from xen_apic_read() not
> > from the else path as this CPU _IS_ present.
> >
> > What's so wrong with storing the fricking firmware supplied APICid as
> > everybody else does and report it back when queried?
>
> By firmware you mean ACPI? It is most likely not available to PV guests.
> How about returning cpu_data(cpu).initial_apicid?
>
> And what was the original problem?

The original issue I found was that VMware was returning a different set
of APIC id's in the ACPI tables than what it advertised on the CPU's.

http://www.mail-archive.com/linux-kernel@xxxxxxxxxxxxxxx/msg1266716.html

> > This damned attitude of we just hack the code into submission and let
> > everybody else deal with the outcoming is utterly annoying.
> >
> > Thanks,
> >
> > 	tglx