Subject: Re: [PATCH] x86/cpuid: Deal with broken firmware once more
To: Thomas Gleixner <tglx@linutronix.de>
References: <20161102122557.qs4rl6mb7n7l7j7p@linutronix.de>
 <24e69019-60d0-29e7-e31f-c6f00f9ed98a@brocade.com>
 <alpine.DEB.2.20.1611071717000.3709@nanos>
 <58e229e2-91f4-a97f-1b9f-089f48ef994a@brocade.com>
 <alpine.DEB.2.20.1611072117040.3501@nanos>
 <e3a6f9cb-ee46-6e5c-7b2e-9a6ed2fc949e@brocade.com>
 <alpine.DEB.2.20.1611081525160.3501@nanos>
 <86609338-2b45-ed7e-fb07-99421e43a2f1@brocade.com>
 <alpine.DEB.2.20.1611081721330.3501@nanos>
 <alpine.DEB.2.20.1611091613540.3501@nanos>
 <49fe8cc5-0f0f-6cac-7a5c-803e81f5667d@runbox.com>
 <alpine.DEB.2.20.1611101125090.3501@nanos>
 <b5f6e797-580b-3c16-c89c-ec16cce084c5@oracle.com>
 <alpine.DEB.2.20.1611101610230.3501@nanos>
Cc: "M. Vefa Bicakci" <m.v.b@runbox.com>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        "Charles (Chas) Williams" <ciwillia@brocade.com>,
        "x86@kernel.org" <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>, Borislav Petkov <bp@alien8.de>,
        David Vrabel <david.vrabel@citrix.com>,
        Juergen Gross <jgross@suse.com>, xen-devel <xen-devel@lists.xen.org>
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
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: <alpine.DEB.2.20.1611101610230.3501@nanos>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1949
Lines: 47

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)