From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752429AbbBWWO3 (ORCPT ); Mon, 23 Feb 2015 17:14:29 -0500 Received: from mail-ie0-f176.google.com ([209.85.223.176]:43073 "EHLO mail-ie0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751601AbbBWWO1 (ORCPT ); Mon, 23 Feb 2015 17:14:27 -0500 MIME-Version: 1.0 In-Reply-To: <54EB99E8.2060500@redhat.com> References: <20150221093150.GA27841@gmail.com> <20150221163840.GA32073@pd.tnic> <20150221172914.GB32073@pd.tnic> <54EB99E8.2060500@redhat.com> Date: Mon, 23 Feb 2015 14:14:26 -0800 X-Google-Sender-Auth: dqM4olrbaS3sAbPe0AfW-aAXYwo Message-ID: Subject: Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs From: Linus Torvalds To: Rik van Riel Cc: "Maciej W. Rozycki" , Andy Lutomirski , Borislav Petkov , Ingo Molnar , Oleg Nesterov , X86 ML , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 23, 2015 at 1:21 PM, Rik van Riel wrote: > > On 02/23/2015 04:17 PM, Maciej W. Rozycki wrote: >>> >>> It seems highly unlikely to me that a slow FPU instruction can >>> retire *after* a subsequent fxsave, which would need to happen >>> for this to work. >> >> I meant something else -- a slow FPU instruction can retire after a >> task has been switched where the FP context has been left intact, >> i.e. in the lazy FP context switching case, where only the MMU >> context and GPRs have been replaced. > > I don't think that's true, because changing the MMU context and GPRs > also includes changing the instruction pointer, and changing over the > execution to the new task. We have one traditional special case, which actually did something like Maciej's nightmare scenario: the completely broken "FPU errors over irq13" IBM PC/AT FPU linkage. But since we don't actually support old i386 machines any more, we don't really need to care. The only way you can get into that situation is with an external i387. I don't think we need to worry about it. But with the old horrid irq13 error handling, you literally could get into a situation that you got an error "exception" (irq) from the previous state, *after* you had already switched to the new one. We had some code to mitigate the problem, but as mentioned, I don't think it's an issue any more. Linus