[<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