linux-kernel - Re: [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to fpu->fpstate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 26 Jan 2017 09:00:36 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Rik van Riel <riel@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Yu-cheng Yu <yu-cheng.yu@...el.com>
Subject: Re: [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active

On Thu, Jan 26, 2017 at 7:53 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Rik van Riel <riel@...hat.com> 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