On Fri, Dec 9, 2016 at 7:30 AM, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > On 12/09/2016 01:22 PM, Josh Boyer wrote: >> >> On Fri, Dec 9, 2016 at 6:10 AM, Florian Weimer <fweimer@xxxxxxxxxx> wrote: >>> >>> We would like to enable hardware-assisted lock optimizations in glibc on >>> multiple architectures. In general, this feature works only on >>> production >>> hardware with current firmware, and not on pre-production machines some >>> vendors provide for architecture bringup. >>> >>> Are the Fedora builders using hardware with support contracts, and are >>> vendor firmware updates applied occasionally, so that we can rely on what >>> the CPU/firmware reports about CPU features? (Some vendors had to >>> disable >>> lock optimizations through firmware updates because the CPU >>> implementation >>> was buggy.) >> >> >> We ran into that with the TSX stuff a couple releases ago, right? > > > I think that issue was caused by late microcode updates. They disabled CPU > features after critical processes had started using them. Early microcode > updates (either during Linux boot, or even earlier) will avoid that > completely. > > I don't think TSX was trivially broken, so whatever triggered Intel's > retroactive CPU downgrade probably wasn't the bug we were seeing. > >> What is to prevent another buggy implementation (hardware or >> microcode) from causing similar problems? > > > We can't predict the future. But if Fedora builders use commercially > supported hardware (and not pre-production samples from one of Red Hat's > hardware partners), we can benefit from the efforts vendors put into fixing > such issues. Otherwise, we will have to reverse-engineer and replicate such > workarounds in our own software, which is *very* difficult because vendors > are traditionally very tight-lipped about such issues. I believe all of the builders are commercially supported hardware, or the equivalent of such in case of some of the alternative architectures. If I remember correctly, on-site support and warranty are two things required to get HW into the Fedora datacenter. Again, hopefully someone from Infra will confirm. >>> What about default Fedora installations? Do they come with early boot >>> microcode updates? >> >> >> Yes. Dracut is configured to create and apply early microcode >> updates. It uses whatever version of microcode is installed at the >> time the kernel is installed and the initramfs is created. > > > This is good. Will the initramfs also be regenerated using dracut if Fedora > ships a microcode update? No. The initramfs is never regenerated automatically. Only a kernel installation creates it, and it only gets regenerated if someone does that by hand. >>> If all this is covered on the Fedora side, we probably can just enable >>> lock >>> optimizations, and we do not need to implement complicated hardware >>> blacklisting. >> >> >> The microcode is updated fairly regularly, but that doesn't seem to >> preclude bad implementations. Perhaps there should be some specific >> testcases around this locking with new microcode updates and/or >> hardware before it is pushed into Fedora? > > > We don't have test cases. CPU vendors generally do not disclose those to > the general public, and I don't want see any of them under NDA because it > might taint us for future support efforts. But we have code in glibc that leverages these instructions, correct? So I'm assuming glibc has test cases that utilize the instructions for locking and there may be some locking correctness tests in glibc? Even something like that would make me feel better. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
