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
