[PATCH v2 00/13] arm64: Preparatory FPSIMD/SVE/SME fixes

[Mark Rutland]

On Tue, Apr 29, 2025 at 08:46:01PM +0100, Will Deacon wrote:
> On Wed, Apr 09, 2025 at 06:17:09PM +0100, Catalin Marinas wrote:
> > On Wed, 09 Apr 2025 17:39:57 +0100, Mark Rutland wrote:
> > > These patches fix a number of problems in the FPSIMD/SVE/SME code, as a
> > > step towards re-enabling SME support. Additional fixes/changes will be
> > > necessary before we can re-enable SME support. I intend to follow up
> > > with more patches in the near future.
> > > 
> > > I'm hoping these patches as-is are largely uncontroversial, though I'm
> > > afraid they've only seen light/targeted testing so far, so any testing
> > > would be much appreciated.
> > > 
> > > [...]
> > 
> > I added these patches to for-next/sme-fixes (and for-kernelci) for wider
> > exposure. Not queued for upstream yet, I need to review and discuss with
> > Will whether we target 6.15 or 6.16.
> 
> FYI: I see the following warning from 'allnoconfig' with these patches
> applied:
> 
> 
> arch/arm64/kernel/fpsimd.c:676:13: warning: unused function 'sve_to_fpsimd' [-Wunused-function]
>   676 | static void sve_to_fpsimd(struct task_struct *task)
>       |             ^~~~~~~~~~~~~
> 1 warning generated.

Argh, sorry about this.

That's a side-effect of fpsimd_signal_preserve_current_state() being
removed in commit:

  929fa99b1215966f ("arm64/fpsimd: signal: Always save+flush state early")

... since fpsimd_signal_preserve_current_state() was always defined and
would (conditionally) call sve_to_fpsimd().

> It's easy enough to move that inside the CONFIG_ARM64_SVE guards, but
> it's a little strange that fpsimd_to_sve() is more widely referenced
> and harder to move.

Yeah, this is a bit messy. I think no matter how we clean things up
we'll end up with a reference to fpsimd_to_sve() via do_sve_acc().  We
want do_sve_acc() to be defined regardless of CONFIG_ARM64_SVE so that
we get consistent trap/SIGILL behaviour when either CONFIG_ARM64_SVE=n
or SVE isn't supported by all PEs, and I don't think we want to move the
bulk of that logic under ifdeffery.

The simplest fix for now would be to mark fpsimd_to_sve() and
sve_to_fpsimd() as 'static inline' or '__maybe_unused', and the former
would be more consistent with the rest of the file.

I'll spin a fix shortly.

Mark.