s390x_is_feature_detected!: detect more features

[folkertdev]

tracking issue: rust-lang/rust#130869
follow-up to #1699

with rust-lang/rust#135630 merged, we can now also check for these facilities at runtime.

I am now using the stfle instruction to get the facilities. From what I can tell AT_HWCAP does not include a bit for the vector-packed-decimal facility. Also the stfle version is just shorter, and I like that the factility bit index is now actually used.

@uweigand previously said that using the stfle instruction is safe because LLVM only supports CPUs with this instruction. This is also the official specification of the target

Code generated by the target uses the z/Architecture ISA assuming a minimum architecture level of z10 (Eighth Edition of the z/Architecture Principles of Operation), and is compliant with the s390x ELF ABI.

In theory that might change if e.g. the GCC backend wants to support something older (gcc appears to still support z900). We can deal with that if it ever becomes relevant.

Testing

I could not find a qemu CPU that works with rust programs and also does not support vx. I did test the logic using the vxrs_ext2 field, and a custom CPU:

runner = "qemu-s390x -cpu qemu,vx=on,vxeh=on,vxeh2=off -L /usr/s390x-linux-gnu"

I verified that toggling the vxeh2 flag is observed by the implementation.

[rustbot]

r? @Amanieu

rustbot has assigned @Amanieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[uweigand]

I am now using the stfle instruction to get the facilities. From what I can tell AT_HWCAP does not include a bit for the vector-packed-decimal facility. Also the stfle version is just shorter, and I like that the factility bit index is now actually used.

The AT_HWCAP bit HWCAP_VXRS_BCD indicates the vector-packed-decimal facility. However, in general it is true that stfle provides a somewhat finer-grained list, if only in theory: in practice, it is possible to recover the facilities "missing" from AT_HWCAP for all s390x machines that have ever existed.

I'd agree that in general, it may be preferable to use stfle over AT_HWCAP. There is one exception, however: there are certain facilities that must be explicitly supported and enabled by the kernel in order to be useful. The main example here is the vector facility: even if the HW provides this facility, all vector instructions will still trap by default, unless they are enabled by the kernel. That is because the vector facility provides a new set of registers, and those are only safe to be used from user-space applications if the kernel is aware of their use (so they can be swapped in/out on context switch). In those cases, stfle will report that the facility is present in HW, while AT_HWCAP will report that the facility is present and enabled.

While at this point in time, most kernels in actual use will support and enable the vector facility if present, it would still be safer to check the AT_HWCAP bit at least for this case.

In theory that might change if e.g. the GCC backend wants to support something older (gcc appears to still support z900). We can deal with that if it ever becomes relevant.

At some point we're likely to drop support from GCC for very old architectures. In any case, having Rust enforce some minimum architecture level even with the GCC backend would certainly be fine.

[folkertdev]

Then it's better to just use AT_HWCAP, so I've removed the commit that uses stfle. This code only gets executed once per program execution, retrieving info for all of the features and caching it. So if AT_HWCAP is needed for the vector feature, we can just use it for all of the others too.

If it ever does become relevant, #1699 has some example code that uses stfle.