lkml.org 
[lkml]   [2016]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] x86/cpuid: Deal with broken firmware once more
From
Date
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?

-boris

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


\
 
 \ /
  Last update: 2016-11-10 15:05    [W:0.118 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site