Re: [PATCH] x86/tsx: Set default TSX mode to auto

[Nikolay Borisov <nik.borisov@suse.com>]

On 8/20/25 19:46, Dave Hansen wrote:
> On 8/20/25 06:21, Nikolay Borisov wrote:
>> The last known vulnerability concerning TSX was TAA (CVE-2019-11135) a
>> lot of time has passed since then and Intel has released a numerous
>> processor which do not have the TAA vulnerability (Cooper/Ice Lake,
>> Sapphire/Emerald/Granite Rappids) yet have TSX disable by default.
>>
>> I believe having the default to AUTO rather than OFF strikes a good
>> balance between mitigation and reaping the benefits of the TSX feature.
>> So let's switch the default to AUTO.
> 
> At a bare minimum, the help text needs to get fixed up too. It still says:
> 
> 	Therefore TSX is not enabled by default (aka tsx=off).
> 
> I'm also not highly motivated by the fact that CPUs have been released
> without TAA. I think TAA is mostly irrelevant. CPUs had been released
> with it mitigated even in the original commit that introduced this
> Kconfig option: db616173d787 ("x86/tsx: Add config options to set
> tsx=on|off|auto").

To add a bit more context about the change, SUSE has been running with 
TSX enabled for the past 6 years and we haven't received any complaints 
from customers. Furthermore, there are customers which explicitly rely 
on TSX being enabled for sane performance.

It's our desire to be aligned with the upstream default option rather 
than ship a different options, hence the compromise we arrived at is 
switching the upstream kernel to auto so that TSX gets enabled by 
default unless there is an explicit reason not to.

> 
> What has _changed_? Are there lots more folks who want to use TSX than
> there were in 2019? Did it get faster? Has the chance of it being
> exploited (separate from TAA) gone down?
> 
> Now would be the time for folks who are chomping at the bit to use TSX
> in their big fancy apps to stand up and say why they want it and why
> having their customers use the command-line to override this Kconfig
> default is not workable.
> 
> Also, from distros, why not just set the Kconfig option to something
> other than the default? I mean, we put Kconfig there for a *REASON*.
> Let's not pretend that it's a massive engineering effort to change it.