Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934005AbcKJPHc (ORCPT ); Thu, 10 Nov 2016 10:07:32 -0500 Received: from mx0a-000f0801.pphosted.com ([67.231.144.122]:42548 "EHLO mx0a-000f0801.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933033AbcKJPHb (ORCPT ); Thu, 10 Nov 2016 10:07:31 -0500 Subject: Re: [PATCH] x86/cpuid: Deal with broken firmware once more To: Boris Ostrovsky , Thomas Gleixner , "M. Vefa Bicakci" 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: Sebastian Andrzej Siewior , "x86@kernel.org" , LKML , Peter Zijlstra , Borislav Petkov , David Vrabel , Juergen Gross From: "Charles (Chas) Williams" Message-ID: Date: Thu, 10 Nov 2016 10:05:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: hq1wp-excas12.corp.brocade.com (10.70.38.22) To BRMWP-EXMB12.corp.brocade.com (172.16.59.130) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-10_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611100273 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1893 Lines: 53 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 >> >> This damned attitude of we just hack the code into submission and let >> everybody else deal with the outcoming is utterly annoying. >> >> Thanks, >> >> tglx > >