On Sat, Dec 10, 2016 at 2:23 AM, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > On 12/09/2016 11:16 PM, Peter Robinson wrote: >> >> On Fri, Dec 9, 2016 at 11: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. >> >> >> Have you got an overview of the required instructions/generations of >> CPU architecture needed for each different architecture by chance? > > > I'm afraid not. Even the information on ark.intel.com is not accurate > because it lists TSX support at launch time and does not take into account > subsequent firmware updates which disable TSX. Based on ark.intel.com, > Broadwell and Skylake Xeons seem to support TSX, and Haswell-EX Xeons as > well, but some other Haswell Xeons do not. > > In /proc/cpuinfo, the Intel feature appears as “rtm” (even though the > marketing name is TSX). > > I don't know where the POWER8 support status appears. It could well be the > case that all POWER8 CPUs support the form lock elision of that glibc > supports (optionally). > >> From there it might be easier to give details of where all the build >> HW is at. In the case of build VMs (x86/aarch64/Power64) does this >> need to be emulated by qemu/kvm or is it passed through from the host >> CPU? > > > TSX does not need hypervisor support AFAIK. We are trying to get > clarification from KVM folks which CPUID values can be influenced by the > hypervisor. We are concerned that the hypervisor makes a CPU with broken > TSX look like one with working TSX (so that Debian-style software > blacklisting of TSX fails). KVM should arguably take care of this itself: mask off TSX in CPUID on problematic CPUs. Actually obtaining the list of problematic CPUs may be difficult. But maybe it's easy -- Intel often documents errata fairly well. --Andy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
