Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030232Ab2B1TG1 (ORCPT ); Tue, 28 Feb 2012 14:06:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36120 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965674Ab2B1TGX (ORCPT ); Tue, 28 Feb 2012 14:06:23 -0500 Message-ID: <4F4D25A2.70307@redhat.com> Date: Tue, 28 Feb 2012 21:06:10 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Linus Torvalds CC: "H. Peter Anvin" , Josh Boyer , Jongman Heo , Thomas Gleixner , Ingo Molnar , x86@kernel.org, Linux Kernel Mailing List , KVM list Subject: Re: [PATCH 2/2] i387: split up into exported and internal interfaces References: <4F42FE08.5020309@zytor.com> <4F43DB69.9060509@zytor.com> <4F440945.1020904@zytor.com> <4F4CB89C.4060500@redhat.com> <4F4D0D18.4060409@redhat.com> <4F4D1857.4010706@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1656 Lines: 44 On 02/28/2012 08:34 PM, Linus Torvalds wrote: > On Tue, Feb 28, 2012 at 10:09 AM, Avi Kivity wrote: > > > > This is done by preempt notifiers. Whenever a task switch happens we > > push the guest fpu state into memory (if loaded) and let the normal > > stuff happen. So the if we had a task switch during instruction > > emulation, for example, then we'd get the "glacial and stupid path" to fire. > > Oh christ. > > This is exactly what the scheduler has ALWAYS ALREADY DONE FOR YOU. No, the scheduler saves the state into task_struct. I need it saved into the vcpu structure. We have two fpu states, the user state, and the guest state. APIs that take a task_struct as a parameter, or reference current implicitly, aren't going to work. > That's what the i387 save-and-restore code is all about. What's the > advantage of just re-implementing it in non-obvious ways? > > Stop doing it. You get *zero* advantages from just doing what the > scheduler natively does for you, and the scheduler does it *better*. The scheduler does something different. What I'd ideally want is struct fpu { int cpu; /* -1 = not loaded */ union thread_xstate *state; }; Perhaps with a struct fpu_ops *ops if needed. We could then let various users' fpus float around freely and only save/load them at the last moment. -- error compiling committee.c: too many arguments to function -- 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/