On Mon, Jan 06, 2025 at 05:40:20PM +0000, Marc Zyngier wrote: > 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. Reviewed-by: Mark Brown <broonie@xxxxxxxxxx> This is probably our best option here, it's what we really meant anyway - SME did retroactively complicate the meaning of the fields so it's not unreasaonable for userspace to get confused. For SME specific usage we should implement separate SME capabilities that have a similar has_sme() check, I'll look into that. I agree with the discussion on v2 that anything reading the ID registers from userspace needs to have a similar understanding that SME only systems exist so we shouldn't do anything there.
Attachment:
signature.asc
Description: PGP signature
