On Tue, Jan 13, 2026 at 02:37:57PM +0000, Fuad Tabba wrote: > On Tue, 23 Dec 2025 at 01:23, Mark Brown <[email protected]> wrote:
> > case SYS_ID_AA64PFR1_EL1: > > - /* Only support BTI, SSBS, CSV2_frac */ > > + /* Only support BTI, SME, SSBS, CSV2_frac */ > > val &= ~(ID_AA64PFR1_EL1_PFAR | > > ID_AA64PFR1_EL1_MTEX | > > ID_AA64PFR1_EL1_THE | > > ID_AA64PFR1_EL1_GCS | > > ID_AA64PFR1_EL1_MTE_frac | > > ID_AA64PFR1_EL1_NMI | > > - ID_AA64PFR1_EL1_SME | > Should we also limit this to SME2, i.e. > + val = ID_REG_LIMIT_FIELD_ENUM(val, ID_AA64PFR1_EL1, SME, SME2); > That said, we don't do anything similar to SVE, but it might also be > worth doing that there. This feels like a general approach issue with these registers that's out of scope for this series, it's not just the vector extensions which could introduce new state or anything else that requires explicit support. AIUI the theory here is that we bootstrap from the host's sanitised registers so the time to add any required limits on future values would be when enabling them for the host kernel, assuming KVM support isn't added simultaneously.
signature.asc
Description: PGP signature
