On Thu, 21 Mar 2019, Stephane Eranian wrote: > On Thu, Mar 21, 2019 at 9:45 AM Thomas Gleixner <t...@linutronix.de> wrote: > > > > On Thu, 21 Mar 2019, Peter Zijlstra wrote: > > > Subject: perf/x86/intel: Initialize TFA MSR > > > > > > Stephane reported that we don't initialize the TFA MSR, which could lead > > > to trouble if the RESET value is not 0 or on kexec. > > > > That sentence doesn't parse. > > > > Stephane reported that the TFA MSR is not initialized by the kernel, but > > the TFA bit could set by firmware or as a leftover from a kexec, which > > makes the state inconsistent. > > > Correct. This is what I meant. > The issue is what does the kernel guarantee when it boots? > > I see: > static bool allow_tsx_force_abort = true; > > Therefore you must ensure the MSR is set to reflect that state on boot. > So you have to force it to that value to be in sync which is what your > new patch is doing.
The initial state should be that the MSR TFA bit is 0. The software state is a different beast. allow_tsx_force_abort false Do not set MSR TFA bit (Make TSX work with PMC3) and exclude PMC3 from being used. true Set the MSR TFA bit when PMC3 is used by perf, clear it when PMC3 is not longer in use. Now, if the firmware or the kexec has the TFA bit set in the MSR and PMC3 is not in use then TSX always aborts pointlessly. It's not a fatal isseu, but it's inconsistent. So independent of the state of allow_tsx_force_abort the kernel has to clear the MSR TSA bit when the CPUs are brought up. The state of allow_tsx_force_abort is solely relevant after CPUs coming up to decide whether PMC3 can be used by perf or not. Thanks, tglx