[PATCH v9 02/30] arm64/fpsimd: Update FA64 and ZT0 enables when loading SME state

[Mark Brown]

On Wed, Jan 07, 2026 at 07:25:04PM +0000, Fuad Tabba wrote:
> On Tue, 23 Dec 2025 at 01:21, Mark Brown <broonie at kernel.org> wrote:

> > +#define sme_cond_update_smcr(vl, fa64, zt0, reg)               \
> > +       do {                                                    \
> > +               u64 __old = read_sysreg_s((reg));               \
> > +               u64 __new = vl;                                 \
> > +               if (fa64)                       \
> > +                       __new |= SMCR_ELx_FA64;                 \
> > +               if (zt0)                                        \
> > +                       __new |= SMCR_ELx_EZT0;                 \
> > +               if (__old != __new)                             \
> > +                       write_sysreg_s(__new, (reg));           \
> > +       } while (0)
> > +

> Should we cap the VL based on SMCR_ELx_LEN_MASK (as we do in
> sve_cond_update_zcr_vq())?

Yes, although I fear if we've got to the point where we've ever got a
bigger value going in we're going to have bigger problems.

> Should we also preserve the remaining old bits from SMCR_EL1, i.e.,
> copy over the bits that aren't
> SMCR_ELx_LEN_MASK|SMCR_ELx_FA64|SMCR_ELx_EZT0? For now they are RES0,
> but that could change.

My thinking here is that any new bits are almost certainly going to need
explicit support (like with the addition of ZT0) and that copying them
forward without understanding is more likely to lead to a bug like
exposing state we didn't mean to than clearing them will.
-------------- 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/20260108/0227049d/attachment.sig>