Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753536AbcCLRVq (ORCPT ); Sat, 12 Mar 2016 12:21:46 -0500 Received: from mail-ob0-f172.google.com ([209.85.214.172]:36468 "EHLO mail-ob0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751883AbcCLRVh (ORCPT ); Sat, 12 Mar 2016 12:21:37 -0500 MIME-Version: 1.0 In-Reply-To: <20160311222023.GH4312@pd.tnic> References: <20160310145940.GB26708@pd.tnic> <20160311090840.GA8486@gmail.com> <20160311094802.GA4312@pd.tnic> <1457694124.2007.12.camel@nexus-software.ie> <20160311112610.GC4312@pd.tnic> <20160311113206.GD4312@pd.tnic> <20160311220313.GG4312@pd.tnic> <56E34197.8080209@linux.intel.com> <20160311222023.GH4312@pd.tnic> From: Andy Lutomirski Date: Sat, 12 Mar 2016 09:21:16 -0800 Message-ID: Subject: Re: [PATCH] x86/FPU: Fix FPU handling on legacy FPU machines To: Borislav Petkov Cc: Fenghua Yu , Thomas Gleixner , "x86@kernel.org" , Dave Hansen , "Bryan O'Donoghue" , Andrew Morton , Oleg Nesterov , Ingo Molnar , "linux-kernel@vger.kernel.org" , Andy Shevchenko , "H. Peter Anvin" , "Yu, Yu-cheng" , Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1001 Lines: 23 On Mar 11, 2016 2:20 PM, "Borislav Petkov" wrote: > > On Fri, Mar 11, 2016 at 02:07:19PM -0800, Dave Hansen wrote: > > I've actually got 4.0 running on my Quark board. The FPU rewrite > > dropped in just after that iirc. > > 4.2 or so... Ok, so it looks like we broke it then. > For reference, what are the QEMU options and boot options you used to trigger this? I'm asking because I tested eagerfpu=on without fxsr a few weeks ago in QEMU, and I didn't trigger it. Maybe I needed to force KVM off or something. Off the top of my head, I'm guessing that when I wrote "x86/fpu: Fix FNSAVE usage in eagerfpu mode", I was inadvertently using a bastardize combination of FNSAVE and FXRSTOR-of-init-state, KVM let the FXRSTOR through despite not advertising it in CPUID, and it papered over the init issue because the wrong init state format was hidden by using the wrong instruction to load it. Sigh. Yet more reason for Intel to add chicken bits to *turn off* new features. --Andy