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? What is to prevent another buggy implementation (hardware or microcode) from causing similar problems? > Do we at least apply microcode updates early during Linux boot on the > builders? Those above questions need to be answered by Fedora Infrastructure most likely. > 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. > 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? josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
