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:   Fri, 15 Oct 2021 12:50:36 +0200
From:   Thomas Gleixner <>
To:     "Liu, Jing2" <>,
        Paolo Bonzini <>,
        LKML <>
Cc:     "" <>,
        "Bae, Chang Seok" <>,
        Dave Hansen <>,
        Arjan van de Ven <>,
        "" <>,
        "Nakajima, Jun" <>,
        Jing Liu <>,
        "" <>,
        "Cooper, Andrew" <>
Subject: RE: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core


On Fri, Oct 15 2021 at 09:00, Jing2 Liu wrote:
> On 10/14/2021 11:01 PM, Paolo Bonzini wrote:
> For the guest dynamic state support, based on the latest discussion,
> four copies of XFD need be cared and switched, I'd like to list as
> follows.

There will not be 4 copies. Read my last mail and think about the

I'm really tired of this tinkering frenzy. There is only one correct
approach to this:

   1) Define the requirements

   2) Define the best trapping mechanism

   3) Sit down, look at the existing code including the FPU rework for
      AMX. Come up with a proper integration plan

   4) Clean up the existing KVM FPU mess further so the integration
      can be done smoothly

   5) Add the required infrastructure in FPU core and KVM

   6) Add the trapping mechanics

   7) Enable feature

What you are doing is looking for the quickest way to duct tape this
into the existing mess.

That might be matching the KVM expectations, but it's not going to

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!

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.

I'm sure you can figure out at which point we are at the moment.



Powered by blists - more mailing lists