Runtime Detection of SVE2 Features Fails Due to Incorrect HWCAP Usage

ARMv8-A CPU Feature Detection and HWCAP Misconfiguration

The issue at hand revolves around the runtime detection of ARMv8-A CPU features, specifically the Scalable Vector Extension 2 (SVE2) and its associated matrix multiplication extensions (SVEF32MM and SVEF64MM). The user attempted to detect these features using the getauxval system call in conjunction with the AT_HWCAP and AT_HWCAP2 auxiliary vector types. However, the results were unexpected, with non-zero values being returned for SVE2 and SVEF64MM despite the absence of these features on the target hardware, a Raspberry Pi 4 (RPi4) based on the ARM Cortex-A72.

The ARMv8-A architecture provides a mechanism for runtime feature detection through the auxiliary vector, which is populated by the kernel and accessible via the getauxval function. The auxiliary vector contains two relevant entries for CPU feature detection: AT_HWCAP and AT_HWCAP2. These entries are bitmasks where each bit corresponds to a specific CPU feature. The AT_HWCAP entry typically covers basic features, while AT_HWCAP2 extends this to more advanced or newer features, such as SVE2.

In the provided code, the user attempted to check for SVE2 and its related features using the HWCAP2_SVE2, HWCAP2_SVEF32MM, and HWCAP2_SVEF64MM bitmasks. However, the user incorrectly used AT_HWCAP instead of AT_HWCAP2 when querying for these features. This misconfiguration led to the incorrect interpretation of the bitmask, resulting in non-zero values for SVE2 and SVEF64MM despite their absence on the RPi4.

The ARM Cortex-A72, which powers the RPi4, does not support SVE2 or its matrix multiplication extensions. Therefore, the expected output for these features should be zero. The unexpected non-zero values indicate a fundamental misunderstanding of how the AT_HWCAP and AT_HWCAP2 bitmasks are structured and accessed.

Misuse of AT_HWCAP for HWCAP2 Features and Bitmask Interpretation Errors

The root cause of the issue lies in the misuse of the AT_HWCAP auxiliary vector entry for querying features that are actually defined in AT_HWCAP2. The AT_HWCAP and AT_HWCAP2 entries are distinct bitmasks, each covering different sets of CPU features. The AT_HWCAP entry is typically used for basic features such as floating-point support (HWCAP_FP), while AT_HWCAP2 covers more advanced features like SVE2 (HWCAP2_SVE2), SVEF32MM (HWCAP2_SVEF32MM), and SVEF64MM (HWCAP2_SVEF64MM).

When the user called getauxval(AT_HWCAP), the returned bitmask did not contain any information about SVE2 or its extensions. However, the user proceeded to apply the HWCAP2_SVE2, HWCAP2_SVEF32MM, and HWCAP2_SVEF64MM bitmasks to this value. Since these bitmasks are defined for AT_HWCAP2, their application to the AT_HWCAP bitmask led to incorrect results.

For example, the HWCAP2_SVE2 bitmask corresponds to bit 1 in the AT_HWCAP2 bitmask. When applied to the AT_HWCAP bitmask, which does not contain this bit, the result was a non-zero value (2) due to the bitwise AND operation with an unrelated bit in the AT_HWCAP bitmask. Similarly, the HWCAP2_SVEF64MM bitmask corresponds to bit 11 in the AT_HWCAP2 bitmask. When applied to the AT_HWCAP bitmask, this resulted in a value of 2048, again due to the bitwise AND operation with an unrelated bit.

This misinterpretation of the bitmasks highlights the importance of understanding the structure and usage of the AT_HWCAP and AT_HWCAP2 entries. The AT_HWCAP and AT_HWCAP2 bitmasks are not interchangeable, and using the wrong one can lead to incorrect feature detection.

Correcting HWCAP Usage and Validating CPU Feature Detection

To resolve the issue, the user must correctly use the AT_HWCAP2 auxiliary vector entry when querying for SVE2 and its related features. The corrected code should call getauxval(AT_HWCAP2) to obtain the bitmask for advanced features and then apply the appropriate bitmasks (HWCAP2_SVE2, HWCAP2_SVEF32MM, and HWCAP2_SVEF64MM) to this value.

Here is the corrected code:

#include <stdio.h>
#include <sys/auxv.h>
#include <asm/hwcap.h>

int main() {
    long hwcaps = getauxval(AT_HWCAP);
    long hwcaps2 = getauxval(AT_HWCAP2);

    printf("FP: %d\n", hwcaps & HWCAP_FP);
    printf("SVE: %d\n", hwcaps & HWCAP_SVE);
    printf("SVE2: %d\n", hwcaps2 & HWCAP2_SVE2);
    printf("SVEF32MM: %d\n", hwcaps2 & HWCAP2_SVEF32MM);
    printf("SVEF64MM: %d\n", hwcaps2 & HWCAP2_SVEF64MM);

    return 0;
}

In this corrected version, the hwcaps variable is used to store the result of getauxval(AT_HWCAP), which is then used to check for basic features like floating-point support (HWCAP_FP) and SVE (HWCAP_SVE). The hwcaps2 variable is used to store the result of getauxval(AT_HWCAP2), which is then used to check for advanced features like SVE2 (HWCAP2_SVE2), SVEF32MM (HWCAP2_SVEF32MM), and SVEF64MM (HWCAP2_SVEF64MM).

When this corrected code is run on the RPi4, the output should now correctly reflect the absence of SVE2 and its extensions:

FP: 1
SVE: 0
SVE2: 0
SVEF32MM: 0
SVEF64MM: 0

This output confirms that the RPi4 does not support SVE2 or its matrix multiplication extensions, as expected.

Additional Considerations for Robust CPU Feature Detection

While the corrected code resolves the immediate issue, there are additional considerations to ensure robust CPU feature detection in ARMv8-A systems:

1. Kernel Support: The availability of CPU feature detection via getauxval depends on kernel support. Ensure that the kernel version running on the target system supports the AT_HWCAP and AT_HWCAP2 auxiliary vector entries and that they are correctly populated.

2. Feature Availability: Not all ARMv8-A CPUs support all features. Always refer to the CPU’s technical reference manual to determine which features are supported. For example, the ARM Cortex-A72 does not support SVE2, so any attempt to detect SVE2 on this CPU will return false.

3. Bitmask Definitions: The bitmask definitions for AT_HWCAP and AT_HWCAP2 may vary between different ARMv8-A implementations. Ensure that the correct bitmask definitions are used for the target CPU. These definitions are typically provided in the CPU’s technical reference manual or the system’s header files.

4. Cross-Platform Compatibility: If the code is intended to run on multiple ARMv8-A platforms, consider adding checks to handle cases where AT_HWCAP or AT_HWCAP2 may not be available or may have different bitmask definitions.

5. Error Handling: Always include error handling to manage cases where getauxval fails or returns unexpected values. This can help catch issues early and provide meaningful feedback to the user.

By following these guidelines, developers can ensure that their CPU feature detection code is accurate, robust, and portable across different ARMv8-A platforms.

Conclusion

The issue of incorrect SVE2 feature detection on the RPi4 was caused by the misuse of the AT_HWCAP auxiliary vector entry for querying features defined in AT_HWCAP2. By correctly using AT_HWCAP2 and applying the appropriate bitmasks, the issue was resolved, and the expected results were obtained. This case highlights the importance of understanding the structure and usage of the AT_HWCAP and AT_HWCAP2 bitmasks in ARMv8-A systems and the need for careful attention to detail when implementing CPU feature detection.