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
| ||
|
Date: Fri, 15 Oct 2021 13:01:57 +0000 From: "Liu, Jing2" <jing2.liu@...el.com> To: Thomas Gleixner <tglx@...utronix.de>, Paolo Bonzini <pbonzini@...hat.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 Hi Thomas, On 10/15/2021 6:50 PM, Thomas Gleixner wrote: > Jing, > > 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 > consequences. > Actually I saw there are fpu_init_fpstate_user(vcpu->arch.user_fpu) and fpu_init_fpstate_user(vcpu->arch.guest_fpu) in the full series, so I understood that we'd keep it this way. (Your last mail corrects me) But yes, these xstate copies really make things complex and bad, and I'm glad to do for a good clean way. I'll reply the thinking (based on your approach below) on that thread later. > 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 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! > Yes, this is an opportunity to make current KVM FPU better. > You are free to ignore me, Of course I won't, because I also want to try a good way that both KVM and kernel are glad to use. Thanks, Jing 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. > > Thanks, > > tglx
Powered by blists - more mailing lists