From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753824AbdAZRBF (ORCPT ); Thu, 26 Jan 2017 12:01:05 -0500 Received: from mail-vk0-f51.google.com ([209.85.213.51]:33180 "EHLO mail-vk0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753401AbdAZRBC (ORCPT ); Thu, 26 Jan 2017 12:01:02 -0500 MIME-Version: 1.0 In-Reply-To: <20170126155307.GA26069@gmail.com> References: <1485429989-23340-1-git-send-email-mingo@kernel.org> <1485429989-23340-6-git-send-email-mingo@kernel.org> <1485441852.15964.49.camel@redhat.com> <20170126151642.GB12274@gmail.com> <1485445549.15964.53.camel@redhat.com> <20170126155307.GA26069@gmail.com> From: Andy Lutomirski Date: Thu, 26 Jan 2017 09:00:36 -0800 Message-ID: Subject: Re: [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active To: Ingo Molnar Cc: Rik van Riel , "linux-kernel@vger.kernel.org" , Andrew Morton , Borislav Petkov , Dave Hansen , Fenghua Yu , "H . Peter Anvin" , Linus Torvalds , Oleg Nesterov , Peter Zijlstra , Thomas Gleixner , Yu-cheng Yu 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 Thu, Jan 26, 2017 at 7:53 AM, Ingo Molnar wrote: > > * Rik van Riel wrote: > >> Let me go totally reimplement this whole project in a different way... > > Note that I can still be convinced about complicating the FPU state machine as > well if that ends up being the best approach for KVM - but it appears to me (from > a very superficial look) that turning vCPU threads into no-FPU kthreads or > representing the guest FPU state directly with the host FPU context would be even > more beneficial, from the simplicity and KVM performance POV? I may be misunderstanding you, but I don't see how this would work without getting either messy or slow. But I think that your series may still be a good base for Rik's work. With your series applied, there are three possible FPU states: regs active (regs are in the CPU), regs inactive (in memory), and regs cached (in memory *and* regs). What Rik's series does doesn't really complicate the state machine -- there are still just these three states. The difference is that it's possible for the regs to be inactive or cached even for the current task so long as we're not in user mode. The point being that the user vCPU thread can enter the kernel, get its FPU state inactivated, enter the guest, and reenter the kernel without reactivating its regs. Rik, if you think about it that way, does your work map cleanly onto Ingo's patches? Ingo, as far as I know, the only serious conceptual complication is that this change has the potential to interact poorly with PKRU, but that should be manageable. --Andy