On Thu, 2025-10-16 at 18:01 +0800, Lulu Cheng wrote: > > 在 2025/10/16 下午5:39, Xi Ruoyao 写道: > > On Thu, 2025-10-16 at 17:22 +0800, Lulu Cheng wrote: > > > + if (CPUCFG2 & CPUCFG2_LSX) > > > + setCPUFeature (FEAT_LSX); > > > + if (CPUCFG2 & CPUCFG2_LASX) > > > + setCPUFeature (FEAT_LASX); > > LSX and LASX capabilities should be obtained via kernel interface > > because they need kernel support. On Linux they can be obtained via > > getauxval(AT_HWCAP), and on other kernels we can only assume they are > > unavailable until their UAPI is stabilized. > > > > When I first implemented it, I wanted to use HWCAP, but I found that HWCAP > > only had the following values: > > #define HWCAP_LOONGARCH_CPUCFG (1 << 0) > #define HWCAP_LOONGARCH_LAM (1 << 1) > #define HWCAP_LOONGARCH_UAL (1 << 2) > #define HWCAP_LOONGARCH_FPU (1 << 3) > #define HWCAP_LOONGARCH_LSX (1 << 4) > #define HWCAP_LOONGARCH_LASX (1 << 5) > #define HWCAP_LOONGARCH_CRC32 (1 << 6) > #define HWCAP_LOONGARCH_COMPLEX (1 << 7) > #define HWCAP_LOONGARCH_CRYPTO (1 << 8) > #define HWCAP_LOONGARCH_LVZ (1 << 9) > #define HWCAP_LOONGARCH_LBT_X86 (1 << 10) > #define HWCAP_LOONGARCH_LBT_ARM (1 << 11) > #define HWCAP_LOONGARCH_LBT_MIPS (1 << 12) > #define HWCAP_LOONGARCH_PTW (1 << 13) > > So, do LAM and UAL also need to pass the HWCAP? Or do they both need to > pass the HWCAP?
Quote from an off-list message from Wang Rui (translated by myself): "Some features are not assigned a hwcap bit. The encoding space of hwcap is also smaller than cpucfg, and the support of a hwcap bit can be added much later than the ship of new hardware. IMO only the features those the kernel can disable/enable should be assigned with a hwcap bit." In this case the kernel cannot disable/enable LAM at all so it shouldn't be an issue. The kernel may disable UAL via CSR.MISC.ALCL3 in theory but the practice of kernels on modern architectures (MIPSr6, RISC-V, and LoongArch) does things in quite the opposite way: even if the hardware does not support UAL the kernel should emulate it by catching the ALE (or similar things on other architectures) trap. So there seems no point to disable it. But LSX and LASX can be disabled/enabled by kernel: on some old kernel versions the vector context switch wasn't implemented and so they are always disabled, and on Linux >= 6.18-rc1 the user can pass simd= parameter via kernel cmdline to disable LSX or LASX for debug or power- save purpose: https://git.kernel.org/torvalds/c/5dcddd268a8d Thus for LSX and LASX HWCAP must be used. -- Xi Ruoyao <[email protected]>
