On Fri, 2025-10-17 at 10:43 +0800, Lulu Cheng wrote: > > 在 2025/10/17 上午10:16, Xi Ruoyao 写道: > > 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. > > > I have no doubts about LSX and LASX, but I don’t quite understand LAM.:-(
LAM is just the am* instructions and IIUC it's only allowed to be unavailable on LA32. > Or should the documentation describe which features the kernel controls > and which it doesn't? I guess la-softdev-conventions should be updated to show it. -- Xi Ruoyao <[email protected]>
