Re: [PATCH 7/8] arm64/cpufeature: Define hwcaps for 2025 dpISA features

[Catalin Marinas <catalin.marinas@arm.com>]

On Mon, Mar 02, 2026 at 10:53:22PM +0000, Mark Brown wrote:
> @@ -3290,11 +3295,13 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
>  	HWCAP_CAP(ID_AA64ISAR1_EL1, I8MM, IMP, CAP_HWCAP, KERNEL_HWCAP_I8MM),
>  	HWCAP_CAP(ID_AA64ISAR1_EL1, LS64, LS64, CAP_HWCAP, KERNEL_HWCAP_LS64),
>  	HWCAP_CAP(ID_AA64ISAR2_EL1, LUT, IMP, CAP_HWCAP, KERNEL_HWCAP_LUT),
> +	HWCAP_CAP(ID_AA64ISAR2_EL1, LUT, LUT6, CAP_HWCAP, KERNEL_HWCAP_LUT6),

IIUC that's a LUTI6 SVE instruction which would not be available if
SVE2p3 is not available (or SVE in general), though we have the
equivalent SME one with SME2p3 (and a separate HWCAP for it). We should
rename it to HWCAP_SVE_LUT6 and make it conditional on
has_sve_feature().

KVM will probably confuse guests here if SVE is disabled but the
ISAR2.LUT field is not capped (I haven't checked). The conditional
has_sve_feature() would solve this but it won't address the MRS
emulation. Arguably it's a KVM problem for exposing inconsistent
id regs: ISAR2.LUT==0b0010 is not permitted without SVE2p3 or SME2p3.
But the spec isn't greatly written either - why does a field about
AdvSIMD all of a sudden reports SVE instructions availability?

On SME, unless I'm misreading the spec, the bits seem to have been
written by three different people in isolation:

- ID_AA64ZFR0_EL1.SVEver + ID_AA64PFR1_EL1.SME (and if these weren't
  enough, we have ID_AA64SMFR0_EL1.SMEver) tells us that SME2p3 is
  implemented. LUTI6 is mandated by SME2p3

- ID_AA64SMFR0_EL1.LUT6 means that the LUTI6 instruction is present but
  this field can only be 0b1 with SME2p3

- ID_AA64ISAR2_EL1.LUT == 0b0010 means that LUTI6 instruction is present
  (if SVE2p3 or SME2p3) and, again, that's the only value permitted by
  SME2p3

So a lot of redundancy and we did end up reporting the fine-grained
details to the user already. The SMExpy versions seem to be cumulative
unless Arm decides to make some of the instructions optional (it still
doesn't explain why we have the same information in SMFR0 and ISAR2). I
guess that's where the fine-grained HWCAPs come in handy.

I wonder if the user would ever be able to parse these ID fields
correctly if using the MRS emulation. We'd need to sanity-check KVM as
well, not sure it proactively caps id fields.

-- 
Catalin