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.
signature.asc
Description: PGP signature
