On Thu, Dec 09, 2021 at 06:41:26PM +0000, Catalin Marinas wrote:
On Mon, Nov 15, 2021 at 03:28:11PM +0000, Mark Brown wrote:
+#define HWCAP2_SME (1 << 20) +#define HWCAP2_SME_I16I64 (1 << 21) +#define HWCAP2_SME_F64F64 (1 << 22) +#define HWCAP2_SME_I8I32 (1 << 23) +#define HWCAP2_SME_F16F32 (1 << 24) +#define HWCAP2_SME_B16F32 (1 << 25) +#define HWCAP2_SME_F32F32 (1 << 26) +#define HWCAP2_SME_FA64 (1 << 27)
At this pace we'll need HWCAP3 pretty soon (since we only allocated 32-bit in each). I wonder whether we could instead not bother at all and just provide user-space emulation for ID_AA64SMFR0_EL1.
I think so if people are willing to go along with just having userspace check the ID register (IIRC access to it already does the right thing but I need to confirm). We'll also need to think about how we handle any new SVE features, that's got a similar thing going on and is most of the existing usage of HWCAP2.
- {
.desc = "FA64",.type = ARM64_CPUCAP_SYSTEM_FEATURE,.capability = ARM64_SME_FA64,.sys_reg = SYS_ID_AA64SMFR0_EL1,.sign = FTR_UNSIGNED,.field_pos = ID_AA64SMFR0_FA64_SHIFT,.min_field_value = ID_AA64SMFR0_FA64,.matches = has_feature_flag,.cpu_enable = fa64_kernel_enable,- },
I'll comment here rather than the patch introducing has_feature_flag(): an alternative would be to add a .field_width option and in feature_matches() use cpuid_feature_extract_field_width() directly. All the arm64_ftr_bits entries already have a width, so just generalise it for arm64_cpu_capabilities.
Sure, if people are happy with that - it's a more invasive change since we don't currently set the widths, I wasn't clear if that was a case of not needing it right now or a design decision.