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@vger.kernel.org/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