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.
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?
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.
Thanks,
Florian
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
