Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     "Liu, Jing2" <jing2.liu@intel.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>
Cc:     "x86@kernel.org" <x86@kernel.org>,
        "Bae, Chang Seok" <chang.seok.bae@intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Arjan van de Ven <arjan@linux.intel.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "Nakajima, Jun" <jun.nakajima@intel.com>,
        Jing Liu <jing2.liu@linux.intel.com>,
        "seanjc@google.com" <seanjc@google.com>,
        "Cooper, Andrew" <andrew.cooper3@citrix.com>
Subject: RE: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core
In-Reply-To: <BYAPR11MB3256D90BEEDE57988CA39705A9B99@BYAPR11MB3256.namprd11.prod.outlook.com>
References: <871r4p9fyh.ffs@tglx>
 <ec9c761d-4b5c-71e2-c1fc-d256b6b78c04@redhat.com>
 <BL0PR11MB3252511FC48E43484DE79A3CA9B89@BL0PR11MB3252.namprd11.prod.outlook.com>
 <6bbc5184-a675-1937-eb98-639906a9cf15@redhat.com> <87wnmf66m5.ffs@tglx>
 <3997787e-402d-4b2b-0f90-4a672c77703f@redhat.com>
 <BYAPR11MB3256D90BEEDE57988CA39705A9B99@BYAPR11MB3256.namprd11.prod.outlook.com>
Date:   Fri, 15 Oct 2021 12:50:36 +0200
Message-ID: <877dee5zpf.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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.

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!

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.

Thanks,

        tglx