add is_s390x_feature_detected

[folkertdev]

tracking issue: rust-lang/rust#135413
relevant issue: rust-lang/rust#130869

this PR adds the is_s390x_feature_detected macro.

Is an ACP needed here?

Below is a bunch of context.

Feature detection

This PR uses only the getauxval function. That is sufficient for the current feature flags.

Based on the official documents, the stfl instruction can/should be used to test for "Facility Indications". Unfortunately, it appears that this instruction can only be executed by the kernel, and in any case stores its result at address 200, that users cannot read. Bummer.

There is also the stfle instruction, that provides more facility indications. We can actually use that from user space, e.g.

struct ExtendedFacilityList([u64; 4]);

impl ExtendedFacilityList {
    unsafe fn new() -> Self {
        let mut result: [u64; 4] = [0; 4];
        unsafe {
            core::arch::asm!(
                "lgr %r0, {0}",
                // equivalently ".insn s, 0xb2b00000, 0({1})",
                "stfle 0({1})",
                in(reg) result.len() as u64 - 1,
                in(reg_addr) result.as_mut_ptr() ,
                options(nostack, preserves_flags )
            );
        }
        Self(result)
    }

    const fn get(&self, n: usize) -> bool {
        // of course they number bits from the left...
        self.0[n / 64] & (1 << (63 - (n % 64))) != 0
    }
}

But, for now, this is not needed and getauxval is sufficient.

Feature names

On nightly, s390x currently has two target features, introduced in rust-lang/rust#127506:

• vector for SIMD capabilities
• backchain related to stack unwinding

The "vector" name appears to be an LLVM concept: in qemu, clang and the linux kernel the "vector" extension is called vx. There is nothing called "backchain" in the Facility Indications, so it looks like that is not a feature that can be queried for at runtime.

Anyway, for now, only "vector" is supported by the is_s390x_feature_detected macro, and it maps internally to the vx facility indication. For some of the vector instructions, the extensions like vector-enhancements-1 will likely also be needed, but this PR does not include them.

This LLVM file lists many more features that are not currently supported.

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.

Obviously that is not an automated test, so for now the details of the implementation go untested.

cc @taiki-e, hope I'm not stepping on your toes here, but this nerdsniped me.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Amanieu (or someone else) some time within the next two weeks.

[taiki-e]

             core::arch::asm!(
                "lgr %r0, {0}",
                // equivalently ".insn s, 0xb2b00000, 0({1})",
                "stfle 0({1})",
                in(reg) result.len() as u64 - 1,
                in(reg_addr) result.as_mut_ptr() ,
                options(nostack, preserves_flags )
            );

Btw, this inline assembly has UBs. (I missed it because it was not included in the change by PR...)

• r0 is clobbered (by both lgr .. and stfile), but not marked clobbered in assembly. (Need to add out("r0") _,, or use inout("r0") result.len() as u64 - 1 => _, and remove lgr ...)

  Section for stfile in PoP says:

  bits 56-63 of general register 0 are updated to contain one less than the number of doublewords needed to contain all of the facility bits assigned for the configuration

• condition code is modified (by stfile), but preserves_flags is used. (Need to remove preserves_flags)

  Section for stfile in PoP says:

  Resulting Condition Code:
  0 Complete facility list stored
  1 --
  2 --
  3 Incomplete facility list stored