]> www.infradead.org Git - users/jedix/linux-maple.git/commit
arm64: Filter out SVE hwcaps when FEAT_SVE isn't implemented
authorMarc Zyngier <maz@kernel.org>
Tue, 7 Jan 2025 22:59:41 +0000 (22:59 +0000)
committerWill Deacon <will@kernel.org>
Wed, 8 Jan 2025 13:41:06 +0000 (13:41 +0000)
commit064737920bdbca86df91b96aed256e88018fef3a
tree4ea4ac2da4f355b1719007f7396f9075fca28921
parentd3c7c48d004f6c8d892f39b5d69884fd0fe98c81
arm64: Filter out SVE hwcaps when FEAT_SVE isn't implemented

The hwcaps code that exposes SVE features to userspace only
considers ID_AA64ZFR0_EL1, while this is only valid when
ID_AA64PFR0_EL1.SVE advertises that SVE is actually supported.

The expectations are that when ID_AA64PFR0_EL1.SVE is 0, the
ID_AA64ZFR0_EL1 register is also 0. So far, so good.

Things become a bit more interesting if the HW implements SME.
In this case, a few ID_AA64ZFR0_EL1 fields indicate *SME*
features. And these fields overlap with their SVE interpretations.
But the architecture says that the SME and SVE feature sets must
match, so we're still hunky-dory.

This goes wrong if the HW implements SME, but not SVE. In this
case, we end-up advertising some SVE features to userspace, even
if the HW has none. That's because we never consider whether SVE
is actually implemented. Oh well.

Fix it by restricting all SVE capabilities to ID_AA64PFR0_EL1.SVE
being non-zero. The HWCAPS documentation is amended to reflect the
actually checks performed by the kernel.

Fixes: 06a916feca2b ("arm64: Expose SVE2 features for userspace")
Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: stable@vger.kernel.org
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20250107-arm64-2024-dpisa-v5-1-7578da51fc3d@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Documentation/arch/arm64/elf_hwcaps.rst
arch/arm64/kernel/cpufeature.c