Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756985Ab2B1SJI (ORCPT ); Tue, 28 Feb 2012 13:09:08 -0500 Received: from mail-wi0-f174.google.com ([209.85.212.174]:44841 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751810Ab2B1SJG (ORCPT ); Tue, 28 Feb 2012 13:09:06 -0500 Authentication-Results: mr.google.com; spf=pass (google.com: domain of linus971@gmail.com designates 10.180.85.35 as permitted sender) smtp.mail=linus971@gmail.com; dkim=pass header.i=linus971@gmail.com MIME-Version: 1.0 In-Reply-To: References: <4F42FE08.5020309@zytor.com> <4F43DB69.9060509@zytor.com> <4F440945.1020904@zytor.com> <4F4CB89C.4060500@redhat.com> <4F4D0D18.4060409@redhat.com> From: Linus Torvalds Date: Tue, 28 Feb 2012 10:08:44 -0800 X-Google-Sender-Auth: r2wW4RWPuw4N06aJStnWGFtBcjo Message-ID: Subject: Re: [PATCH 2/2] i387: split up into exported and internal interfaces To: Avi Kivity Cc: "H. Peter Anvin" , Josh Boyer , Jongman Heo , Thomas Gleixner , Ingo Molnar , x86@kernel.org, Linux Kernel Mailing List , KVM list Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1766 Lines: 42 On Tue, Feb 28, 2012 at 9:37 AM, Linus Torvalds wrote: > > So where's the comment about why you actually own and control CR0.TS, > and nobody else does? So what I think KVM should strive for (but I really don't know the code, so maybe there are good reasons why it is impossible) is to just never touch TS at all, and let the core kernel code do it all for you. When you need access to the FPU, let the core code just handle it for you. Let it trap and restore the state. When you get scheduled away, let the core code just set TS, because you really can't touch the FP state again. IOW, just do the FP operations you do within the thread you are. Never touch TS at all, just don't worry about it. Worry about your own internal FP state machine, but don't interact with the "global" kernel TS state machine. You can't do a lot better than that, I think. Especially now that we do the lazy restore, we can schedule between two tasks and if only one of them actually uses the FPU, we won't bother with extraneous state restores. The one exception I can think of is that if you are loading totally *new* FP state, and you think that TS is likely to be set, instead of trapping (and loading the old state in the trap handling) only to return to load the *new* state, we could expose a helper for that situation. It would look something like user_fpu_begin(); fpu_restore_checking(newfpustate); and it would avoid the trap when loading the new state. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/