From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754020AbcKROVR convert rfc822-to-8bit (ORCPT <rfc822;w@1wt.eu>);
        Fri, 18 Nov 2016 09:21:17 -0500
Received: from aserp1040.oracle.com ([141.146.126.69]:44999 "EHLO
        aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752090AbcKROVP (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 18 Nov 2016 09:21:15 -0500
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>
 <eecbbfdf-38c1-acdd-402b-3be48cf5fdb7@brocade.com>
 <cc8425f3-23df-a9e7-bc01-db6b529f96e5@oracle.com>
 <f622cd63-6af5-af71-9a5c-b6c71d269dfa@runbox.com>
 <68840c0b-44c9-ddd8-bfab-f4fd8bacbaf0@oracle.com>
 <41978b7b-2880-4ea5-14c3-7185422261e7@runbox.com>
 <96419776-022d-63f9-84c4-7426101f4657@oracle.com>
 <alpine.DEB.2.20.1611181214240.3615@nanos>
Cc: "M. Vefa Bicakci" <m.v.b@runbox.com>,
        "Charles (Chas) Williams" <ciwillia@Brocade.com>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        "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: <1edbdac8-dfef-5529-8246-bbcd499e6d5a@oracle.com>
Date: Fri, 18 Nov 2016 09:22:29 -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.1611181214240.3615@nanos>
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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 11/18/2016 06:16 AM, Thomas Gleixner wrote:
> On Mon, 14 Nov 2016, Boris Ostrovsky wrote:
>> On 11/13/2016 06:42 PM, M. Vefa Bicakci wrote:
>>
>>> I found out that my domU kernels invoke the 'apic_disable' function
>>> because CONFIG_X86_MPPARSE was not enabled in my kernel configuration,
>>> which would cause the 'smp_found_config' bit to be unset at boot-up.
>> smp_found_config is not the problem, it is usually zero for Xen PV guests.
>>
>> What is the problem is that because of your particular config selection
>> acpi_mps_check() fails (with the error message that you mention below) and
>> that leads to X86_FEATURE_APIC being cleared. And then we indeed switch to
>> APIC noop and things go south after that.
> Indeed. And what really puzzles me is that Xen manages to bring up a
> secondary CPU despite APIC being disabled. 

PV guests bring secondary VCPUs up using hypercalls (see xen_cpu_up()).

> There are quite some assumptions about no APIC == no SMP in all of x86. Can
> we please make Xen behave like anything else?
>

I will try to see if we can improve APIC emulation for these guests.
Unfortunately it will have to be done on kernel side since we still need
to support older Xen versions.

But as I said earlier, the right answer to this is PVH.

-boris