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

[Mark Brown]

On Thu, Apr 09, 2026 at 12:33:50PM +0100, Catalin Marinas wrote:
> 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().

OK, and hope that the SME feature always keeps in sync with this.

> 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?

Yeah, it's just a generally interesting choice for the architecture.
It'll also be fun if we get a new LUT feature that isn't SVE/SME
specific.

> 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.

There's a few things like this with the FP extension, I think mostly
with SME - it's future proofing in case we want to allow more
flexibility with when the individual features are available.

> 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.

Yeah, there's some traps here.  Generally you're probably best using the
most specific field for a given feature but there's still traps there.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260409/dfc8c0a7/attachment-0001.sig>