[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <90457491-1ac3-b04a-856a-25c6e04d429a@intel.com>
Date:   Tue, 12 Apr 2022 08:54:10 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Jon Kohler <jon@...anix.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>, Tony Luck <tony.luck@...el.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Borislav Petkov <bp@...e.de>,
        Neelima Krishnan <neelima.krishnan@...el.com>,
        "kvm @ vger . kernel . org" <kvm@...r.kernel.org>
Subject: Re: [PATCH] x86/tsx: fix KVM guest live migration for tsx=on
On 4/12/22 06:36, Jon Kohler wrote:
> So my theory here is to extend the logical effort of the microcode driven
> automatic disablement as well as the tsx=auto automatic disablement and
> have tsx=on force abort all transactions on X86_BUG_TAA SKUs, but leave
> the CPU features enumerated to maintain live migration.
> 
> This would still leave TSX totally good on Ice Lake / non-buggy systems.
> 
> If it would help, I'm working up an RFC patch, and we could discuss there?
Sure.  But, it sounds like you really want a new tdx=something rather
than to muck with tsx=on behavior.  Surely someone else will come along
and complain that we broke their TDX setup if we change its behavior.
Maybe you should just pay the one-time cost and move your whole fleet
over to tsx=off if you truly believe nobody is using it.
Powered by blists - more mailing lists
 
