Well, I've finally finished analysing things for Broadwell. The amd64 (x86-64) glibc lock elision code keys on the RTM CPUID bit because it is actually using RTM (and not HLE) to implement lock elision. I failed to keep this in mind when worrying about permanently blacklisting Broadwell processors from glibc lock elision in unstable.
Errata BDM53/BDW51/BDD51/BDE42 "Intel TSX Instructions not avalilable" _should_ mean that trying to use any of the TSX-NI opcodes (i.e. RTM) in Broadwell would always result in an illegal opcode exception (SIGILL). The specificaton updates also explicitly say in the descriptions of these errata that the RTM bit in CPUID is not set. Were those errata present on every microcode revision/core versions of those processors, it would make them "safe" as far as our (patched) glibc lock elision is concerned. We are not that lucky. Seaching the network for cpuinfo reports resulted in a /proc/cpuinfo dump of signature 0x306d4, microcode rev 0x11 (Core i5-5300U), and rev 0x18 (Core M-5Y71), where both RTM and HLE are reported as enabled. Another /proc/cpuinfo dump of signature 0x306d4, with microcode rev 0x18 (Core i5-5300U and also Core M-5Y10c) and rev 0x1f (Core i5-5287U), shows both HLE and RTM already disabled. The fact that revision 0x18 had a different CPUID response for (Core i5-5300U, Core M-5Y10c), and Core M-5Y71 was a surprise. Perhaps it also has a dependency on the firmware doing a (hopefully boot-locked) wrmsr to disable TSX. Anyway, regardless of the reason, one cannot count on the RTM and HLE bits being disabled in CPUID(7) on every Broadwell processor and microcode revision out there. OTOH, it does means we can, and should, blacklist signature 0x306d4 (and earlier) permanently, because RTM is extremely unlikely to be fixed/fixable on these processors. Either it is disabled as it should be per the errata documentation, or enabled and very dangerous (resulting in either SIGILL or Haswell-style risk of unpredictable system behavior). Since signature 0x40671 also has the same "TSX unavailable" type of errata (BDD51, BDE42), I guess we can assume the same applies to Broadwell-H and Broadwell-DE, and blacklist lock elision there permanently as well. I am still collecting data for Skylake-S, but it boils down to whether up-to-date Skylake-S microcode (revisions 0x34 and higher) fixes, or disable TSX. We know that microcode update does stop glibc lock elision crashing with SIGSEGV, though. Meanwhile, a suggestion by Samuel Thibault to try to use hwcap did provide for a possible long-term plan to fine-tune the lock-elision blacklist (and anything else of that sort). We would have to (finally) extend x86-64 hwcap to cpuid(1) fully, and also at least cpuid(7), which is anything but trivial and a lot of work. This is _not_ worth the trouble if it is done just for lock elision blacklisting purposes. However, it would be useful for link-time optimization in libraries (e.g. avx2 flavours of something that really benefits from it, etc), so it is likely worth pursuing... but only if we get buy-in from upstream. Once it is there for far better purposes than blacklisting, there is no reason not to do the trivial work to have the kernel blacklist whatever capabilities should be avoided, and switch glibc to use the hwcap extension instead of doing cpuid directly wherever available, thus making it usable _also_ for blacklisting things. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh <h...@debian.org>
