Re: Status of microcode updates
On Fri, Dec 9, 2016 at 6:10 AM, Florian Weimer <fweimer(a)redhat.com> 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