Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3508imm; Thu, 20 Sep 2018 14:02:24 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYnqyAPMNMauiHRg4Zmh9YHHQUwHn433iHdo+7w2Txfs5CLEFEg1sewftiKNkw/wNKb41xs X-Received: by 2002:a17:902:7614:: with SMTP id k20-v6mr41016520pll.170.1537477344183; Thu, 20 Sep 2018 14:02:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537477344; cv=none; d=google.com; s=arc-20160816; b=AtgBfWOr2aK4YmojIQfnFuKBcdQTwy1786ASvL/5HijiYvQnuw8cqffKfBSVcuYff1 tElkVnFGyJXFLNykErqLmYM9idAic6iuUzUHpNwWz0uLRb/7znp5vOex0xZIk1HbZ88K O4e7hA5W17KWKU2wZEvYMy1S/9p4tOx/IseKwJ7gHTtHuvkziNhWGKgdx9A9gBvt2VWN UNkCJvtdKDn2kcuCJIZElWb/gjiSloHJUM7Xb26p2sOn9pT5K4oBwCU7eua8JbhmAUsM b5d5t1rHwillh4ogq/dAfATxFIbFQA8fLODKpP97LUGfKXlXXoyij6E2X/JKGk6k8R7D QNkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Hm3bFKzihrL7uYqay8Ok08MgSH4jDluIxDXLSzrc4ME=; b=E8Oi2hnj3eSlgBbrfraJ5auktjYHavv6hAwPfcs0/4rqXM/CMg0I/RBDjuTqbDc/ra rBVoXCKESma9WdqYY9zQ1X+X5NsN4tn2WlqZ4zKXBZ6QTBpV8teuXPOtZKp5ofx2k+Jl nasNpABHISVrRbrJ/SVxi6pCuuOvswCNmAEIqPQL4Fb8KGtv/lXKoxwbqmfBvAdks0zR Tke+vRuT2Fa6/nZ2Uinx/bDMb7mdFcu/4plstDGmjddeU4DcAd7tP28PX9lxWfecl6Qz 9iolfjp5PNFaDr2J8gUcFilxPKu2OhUmZEWH+NKA+eRU8gP9D3DAZmVV3xTOGeOlv1V4 9lPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=YgYmTi2V; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e186-v6si25486793pfc.176.2018.09.20.14.02.04; Thu, 20 Sep 2018 14:02:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=YgYmTi2V; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388469AbeIUCqi (ORCPT + 99 others); Thu, 20 Sep 2018 22:46:38 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:51271 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726582AbeIUCqi (ORCPT ); Thu, 20 Sep 2018 22:46:38 -0400 Received: by mail-wm1-f68.google.com with SMTP id y2-v6so911256wma.1 for ; Thu, 20 Sep 2018 14:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Hm3bFKzihrL7uYqay8Ok08MgSH4jDluIxDXLSzrc4ME=; b=YgYmTi2VnnK+pW2faRajzZ7WmYDK3ad12Vooo6vDecNTL5g9cOBiW1F+866fCLq2LU a2/J+/MiOsB6enAp+7tRwuhIbsjDqkcen5tz0J+pgNFYLkt59gCcRCeitveWwIvBKDGr hyi0Z+PKHxlUfU0psEQJQ7ZJIo22vlrmxJ0JC0z9SV/VBuO5ZeQEXOOLbvIuMkUReU8W d5/qEDkr/0KACvhFVIUnQJg8HUAwWA5lUJfYPCy8Engr12FPE96RboqG+r3V/g1IaBuu s1wAB9GBUCpTxizCGt8GZIHl5I/IGvHI4N7QKC2Ni7SoRA6/JBQCiLVggr62/DbXelhj MNRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Hm3bFKzihrL7uYqay8Ok08MgSH4jDluIxDXLSzrc4ME=; b=uSdxa4TYcCD6hnay0FSpCjtIanr4IiW5+HIsP67iUt0kEaUs/hgTfdqzXLohrOUt2P 8ZdcRhtSEl4Y64zNGFaO4dfMzGlcVjWouAFELEfDHwIr2IPEsidn8tjKwIObR0X8pnwb 7VDotl3AHtOoWWnJV2r2Ok6nvL7T5LkDDcYl7gu9wujD6cocokdw0OPryWOFq9N0OVIr KANiDlaYcmoXKT1eC8AWrLK6waP1b0JRp8TKrQWPaLxOd77DzSp9NvsyLYgXLcVrp5zx WmF6iaybNOIuV4KDU+6W3AO0NZRbww/vgcwHl0vBt8O/hawEdq/pVehTa6voQIOYC1l6 EEWw== X-Gm-Message-State: APzg51CMDTlKK3i9Fh4Vds2ILLAKUdtjbkbAAk/ar/NGBSIsNnBKi54K 8IlrqltDRkq4AYz9X1xoPbto+j4XHb9DTR/sk3+GpQ== X-Received: by 2002:a1c:7e92:: with SMTP id z140-v6mr4426803wmc.48.1537477272990; Thu, 20 Sep 2018 14:01:12 -0700 (PDT) MIME-Version: 1.0 References: <1537476292-28056-1-git-send-email-tedheadster@gmail.com> In-Reply-To: <1537476292-28056-1-git-send-email-tedheadster@gmail.com> From: Andy Lutomirski Date: Thu, 20 Sep 2018 14:01:00 -0700 Message-ID: Subject: Re: [PATCH] x86/cpu: Enable cpuid instruction on Cyrix 6x86/6x86L processors To: Matthew Whitehead Cc: LKML , Ingo Molnar , Thomas Gleixner , Peter Zijlstra , Borislav Petkov , "H. Peter Anvin" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 20, 2018 at 1:45 PM Matthew Whitehead wrote: > > On power up, the cpuid instruction is disabled on Cyrix 6x86 and 6x86L > processors and it needs to be enabled. There is code to do this, but it > does not work because it uses the broken {set,get}Cx86_old() macros. > > There are comments in processor-cyrix.h advising you to _not_ make calls > using the deprecated macros in this style: > > setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80); > > This is because it expands the macro into a non-functioning calling > sequence. The new macros fix this problem, so we use them instead. > > We also need to forcibly enable X86_FEATURE_CPUID. This is because > early_identify_cpu() does not know that the call to > identify_cpu_without_cpuid() actually enables the cpuid instruction in the > odd Cyrix case, and it turns X86_FEATURE_CPUID off after it has just been > enabled on the processor. > > This was tested on actual Cyrix hardware. > > Signed-off-by: Matthew Whitehead > --- > arch/x86/kernel/cpu/cyrix.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c > index 8949b7a..e603cc5 100644 > --- a/arch/x86/kernel/cpu/cyrix.c > +++ b/arch/x86/kernel/cpu/cyrix.c > @@ -437,10 +437,11 @@ static void cyrix_identify(struct cpuinfo_x86 *c) > /* enable MAPEN */ > setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); > /* enable cpuid */ > - setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80); > + setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x80); Fine with me. > /* disable MAPEN */ > setCx86(CX86_CCR3, ccr3); > local_irq_restore(flags); > + setup_force_cpu_cap(X86_FEATURE_CPUID); I don't think this is right. This called from here: /* cyrix could have cpuid enabled via c_identify()*/ if (have_cpuid_p()) { cpu_detect(c); get_cpu_vendor(c); get_cpu_cap(c); get_cpu_address_sizes(c); setup_force_cpu_cap(X86_FEATURE_CPUID); if (this_cpu->c_early_init) this_cpu->c_early_init(c); c->cpu_index = 0; filter_cpuid_features(c, false); if (this_cpu->c_bsp_init) this_cpu->c_bsp_init(c); } else { identify_cpu_without_cpuid(c); <-- here setup_clear_cpu_cap(X86_FEATURE_CPUID); } and it won't do what it should do. I would instead restructure the code: if (!have_cpuid_p()) identify_cpu_without_cpuid(c); /* cyrix could have cpuid enabled via c_identify() */ if (have_cpuid_p()) { cpu_detect(); ... } else { setup_clear_cpu_cal(X86_FEATURE_CPUID); } and then re-test, of course, to make sure that the Cyrix identification code actually works when it gets re-invoked with CPUID on. --Andy