Lack of a standardized userspace API to detect active ARMv8.2‑A LSE atomic instruction usage

Answer to the Core Question

There is currently no stable, ABI‑preserving userspace API that reports whether a running kernel or libc is executing atomic primitives with the ARMv8.2‑A Large System Extensions (LSE) instruction set. The only mechanisms that exist are:

• Inspection of the CPU's feature list in /proc/cpuinfo or via getauxval(AT_HWCAP2) for the HWCAP2_LSE bit.
• Compile‑time macros such as __ARM_FEATURE_LSE that inform the compiler which instruction set to generate.
• Kernel boot parameters (e.g., arm64.lse=off) that can force the kernel to fall back to LDREX/STREX loops, but no user‑space query exists to detect that switch.

Because the feature is a low‑level CPU capability and the kernel may choose to enable or disable it per‑process, a portable, version‑agnostic API would need to expose a per‑process flag that can be queried without changing the existing ABI. The most straightforward approach would be a read‑only sysfs entry (e.g., /sys/devices/system/cpu/cpu0/lse_enabled) or a prctl option that returns a boolean. Such a feature would not alter the current ABI; it would simply add a new, optional query path for applications that need to adapt at runtime.

Likely Explanation for Current Absence

Linux and other kernels historically expose CPU capabilities only through the auxiliary vector and /proc/cpuinfo. Adding a new userspace API would require kernel development effort and careful consideration of backward compatibility. Since LSE is optional and may be disabled by boot parameters, kernel maintainers have not found a strong enough use case to justify the added complexity.

Confirmed Facts

• ARMv8.2‑A LSE adds atomic instructions such as LDADDX and STLEX that can replace the legacy LDREX/STREX loop.
• The auxiliary vector flag HWCAP2_LSE (bit 6 in AT_HWCAP2) indicates hardware support for LSE at boot time.
• Linux can disable LSE per‑process via the arm64.lse=off kernel parameter, but there is no user‑space query for that state.
• Standard user‑space libraries (glibc, musl) currently generate LDREX/STREX loops unless compiled with -march=armv8.2-a+lse or the compiler detects the flag at runtime.

Steps for the Current Case

1. Check CPU feature flags. Run cat /proc/cpuinfo | grep lse or use getauxval(AT_HWCAP2) & 0x40 to see if the CPU advertises LSE support.
2. Verify kernel configuration. If the kernel was built with CONFIG_ARM64_LSE and no boot flag disables it, the kernel will allow LSE instructions. Check /proc/cmdline for arm64.lse=off.
3. Test at runtime. Compile a small program that uses a GCC builtin atomic (e.g., __atomic_fetch_add) with -march=armv8.2-a+lse. Run it on the target; if it crashes with SIGILL, the CPU or kernel is not allowing LSE.
4. Library adaptation. Libraries can perform a one‑time getauxval check at startup and set an internal flag. They can then choose the LSE path if the flag is set and the kernel is not disabling it via boot parameters.

What Could Be Added to the Kernel

• A read‑only /sys/devices/system/cpu/cpu0/lse_enabled file that mirrors the per‑process LSE state.
• A prctl(SET_LSE_ENABLED, 0/1) call that lets a process query or enforce LSE usage, with a no‑op implementation on kernels that do not support the flag.
• Documentation in arch/arm64/Documentation explaining the relationship between HWCAP2_LSE, kernel boot parameters, and userspace detection.

Missing Diagnostic Detail

To refine the recommendation, could you confirm whether the kernel you target is built with CONFIG_ARM64_LSE and whether the arm64.lse=off parameter is ever used? Knowing the kernel configuration will determine whether a runtime query is necessary or whether compile‑time detection suffices.