[PATCH v9 25/30] KVM: arm64: Expose SME to nested guests

Mark Brown broonie at kernel.org
Wed Jan 14 10:22:05 PST 2026


On Tue, Jan 13, 2026 at 02:37:57PM +0000, Fuad Tabba wrote:
> On Tue, 23 Dec 2025 at 01:23, Mark Brown <broonie at kernel.org> 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.
-------------- 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/20260114/e3fec8f0/attachment.sig>


More information about the linux-arm-kernel mailing list