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

[Boris Ostrovsky]

On 11/10/2016 10:05 AM, Charles (Chas) Williams wrote:
>
>
> 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

For Xen, we recently added a6a198bc60e6 ("xen/x86: Update topology map
for PV VCPUs") to at least temporarily work around some topology map
problems that PV guests have with RAPL (which I think is what Vefa's
problem was).

-boris