linux-kernel - Re: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core

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]

Message-ID: <37923aa8-8d86-4409-7689-3fbf8ce8ae4f@redhat.com>
Date:   Fri, 15 Oct 2021 13:17:20 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        "Liu, Jing2" <jing2.liu@...el.com>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     "x86@...nel.org" <x86@...nel.org>,
        "Bae, Chang Seok" <chang.seok.bae@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Nakajima, Jun" <jun.nakajima@...el.com>,
        Jing Liu <jing2.liu@...ux.intel.com>,
        "seanjc@...gle.com" <seanjc@...gle.com>,
        "Cooper, Andrew" <andrew.cooper3@...rix.com>
Subject: Re: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core

On 15/10/21 12:50, Thomas Gleixner wrote:
> That might be matching the KVM expectations, but it's not going to
> happen.
> 
> KVM already violates all well known rules of encapsulation and just
> fiddles in the guts of FPU mechanism, duplicates code in buggy ways.
> 
> This has to stop now!

FWIW, I totally agree about that.  Over the years we've gotten more 
well-thought hooks in the kernel for KVM and less hacks, and I'll only 
be happy if that extends to the FPU code which I'm quite wary of 
touching.  Most of it has been unchanged since Ingo's last rewrite.

Paolo

> You are free to ignore me, but all you are going to achieve is to delay
> AMX integration further. Seriously, I'm not even going to reply to
> anything which is not based on the above approach.