From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934420AbcKJPhk convert rfc822-to-8bit (ORCPT ); Thu, 10 Nov 2016 10:37:40 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:24060 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933658AbcKJPhi (ORCPT ); Thu, 10 Nov 2016 10:37:38 -0500 Subject: Re: [PATCH] x86/cpuid: Deal with broken firmware once more To: Thomas Gleixner References: <20161102122557.qs4rl6mb7n7l7j7p@linutronix.de> <24e69019-60d0-29e7-e31f-c6f00f9ed98a@brocade.com> <58e229e2-91f4-a97f-1b9f-089f48ef994a@brocade.com> <86609338-2b45-ed7e-fb07-99421e43a2f1@brocade.com> <49fe8cc5-0f0f-6cac-7a5c-803e81f5667d@runbox.com> Cc: "M. Vefa Bicakci" , Sebastian Andrzej Siewior , "Charles (Chas) Williams" , "x86@kernel.org" , LKML , Peter Zijlstra , Borislav Petkov , David Vrabel , Juergen Gross , xen-devel From: Boris Ostrovsky Message-ID: <34456dc1-191f-dddb-7881-8409b654cdc8@oracle.com> Date: Thu, 10 Nov 2016 10:38:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/10/2016 10:12 AM, Thomas Gleixner wrote: > On Thu, 10 Nov 2016, 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. > You either have to provide ACPI or MP tables. And either of those has to > provide the intial APIC ids for the CPUs. They are supposed to match the > IDs which are in the CPUID leafs. > >> How about returning cpu_data(cpu).initial_apicid? > For a not yet brought up CPU. That's what the initial ACPI/MP table > enumeration is for. Unfortunately PV guests have neither. So we may need to emulate something in xen_cpu_present_to_apicid(). -boris (+xen-devel)