[v3,11/28] arm64/sve: Core task context handling

This patch adds the core support for switching and managing the SVE
architectural state of user tasks.

Calls to the existing FPSIMD low-level save/restore functions are
factored out as new functions task_fpsimd_{save,load}(), since SVE
now dynamically may or may not need to be handled at these points
depending on the kernel configuration, hardware features discovered
at boot, and the runtime state of the task.  To make these
decisions as fast as possible, const cpucaps are used where
feasible, via the system_supports_sve() helper.

The SVE registers are only tracked for threads that have explicitly
used SVE, indicated by the new thread flag TIF_SVE.  Otherwise, the
FPSIMD view of the architectural state is stored in
thread.fpsimd_state as usual.

When in use, the SVE registers are not stored directly in
thread_struct due to their potentially large and variable size.
Because the task_struct slab allocator must be configured very
early during kernel boot, it is also tricky to configure it
correctly to match the maximum vector length provided by the
hardware, since this depends on examining secondary CPUs as well as
the primary.  Instead, a pointer sve_state in thread_struct points
to a dynamically allocated buffer containing the SVE register data,
and code is added to allocate, duplicate and free this buffer at
appropriate times.

TIF_SVE is set when taking an SVE access trap from userspace, if
suitable hardware support has been detected.  This enables SVE for
the thread: a subsequent return to userspace will disable the trap
accordingly.  If such a trap is taken without sufficient hardware
support, SIGILL is sent to the thread instead as if an undefined
instruction had been executed: this may happen if userspace tries
to use SVE in a system where not all CPUs support it for example.

The kernel may clear TIF_SVE and disable SVE for the thread
whenever an explicit syscall is made by userspace, though this is
considered an optimisation opportunity rather than a deterministic
guarantee: the kernel may not do this on every syscall, but it is
permitted to do so.  For backwards compatibility reasons and
conformance with the spirit of the base AArch64 procedure call
standard, the subset of the SVE register state that aliases the
FPSIMD registers is still preserved across a syscall even if this
happens.

TIF_SVE is also cleared, and SVE disabled, on exec: this is an
obvious slow path and a hint that we are running a new binary that
may not use SVE.

Code is added to sync data between thread.fpsimd_state and
thread.sve_state whenever enabling/disabling SVE, in a manner
consistent with the SVE architectural programmer's model.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Alex Bennée <alex.bennee@linaro.org>

---

Changes since v2
----------------

Changes requested by Catalin Marinas:

 * [bugfix] Enabled IRQs during SVE access traps

   There is no special reason why interrupts have to be disabled in
   do_sve_acc(), and the original intention was to enable them --
   I missed this while developing the series.

   This patch avoids IRQ blackout while allocating thread.sve_state and
   saving/restoring.

   This also protects us against kzalloc() sleeping, which was a bug
   here previously since this function was running in atomic context.
   Relying on GFP_ATOMIC here doen't seem justifiable.

   The code is currently suboptimal in the case where no context switch
   occurs, since it adds a store-reload roundtrip that is not strictly
   necessary.  However, avoiding this leads to violation of some
   assumptions which would require additional refactoring or code
   duplication to resolve, particularly regarding the setting of
   ZCR_EL1.LEN.

   For now, I prefer to have code that works initially, and let the
   dust settle for a bit.

   This may be refactored better later.

 * Added WARN_ON(in_softirq() && !irqs_disabled()) to
   task_fpsimd_{load,save}(), to flag up attempts to call these
   functions when softirqs could occur.  This is far from being
   everything we could check, but masking of softirqs is the most
   crucial requirement.

   This will guard against maintenance accidents that call these
   functions in inappropriate situations.

 * Provided an explicit helper
   fpsimd_preserve_current_state_discard_sve() to ensure that task
   vector state is stored to memory and unconditionally discard sve.
   This gets the parent task into the right state such that fork just
   requires a memcpy of thread_struct followed by NULLing dst->
   thread.sve_state.

   With this, fpsimd_dup_sve() has nothing to do any more, so this
   function has been deleted from the patch.

   task_fpsimd_save() is factored out with a backend
   __task_fpsimd_save(bool force_discard), which is used in the few
   places where it is appropriate.

   For now, this breaks fpsimd_preserve_current_state() for SVE tasks,
   but there is no way for SVE tasks to exist yet: so just WARN().
   This issue is resolved by "arm64/sve: Signal handling support".

Miscellaneous:

 * Added comments explaining the intent, purpose and basic constraints
   for fpsimd.c helpers.

 * Added comments explaining the role of TIF_SVE.

 * Added a WARN_ON() check in task_fpsimd_save to confirm that the
   VL currently configured in ZCR_EL1.LEN is correct for current.

   This was identified as a maintenance risk when working on enabling
   IRQs in do_sve_acc().

   The new logic flags and avoids potential buffer overruns on
   sve_state that could otherwise occur if the VL is wrong.  In this
   case, we simply skip the save.  The task state will be corrupted, but
   that's better than corrupting kernel memory.

   Since the task state is now wrong, it can't resume: just inject a
   SIGKILL instead.  We can't BUG(), since this problem may be detected
   in softirq context where BUG() panics the kernel -- so
   force_signal_inject() is called instead.  "bad mode" is a confusing
   thing to print for this, so force_signal_inject() is updated to print
   the more general "unknown or unrecoverable error" for such signals:
   there is no other call to force_signal_inject() with signal==SIGKILL
   today.
---
 arch/arm64/include/asm/fpsimd.h      |  17 ++
 arch/arm64/include/asm/processor.h   |   2 +
 arch/arm64/include/asm/thread_info.h |   1 +
 arch/arm64/include/asm/traps.h       |   2 +
 arch/arm64/kernel/entry.S            |  14 +-
 arch/arm64/kernel/fpsimd.c           | 342 ++++++++++++++++++++++++++++++++++-
 arch/arm64/kernel/process.c          |  14 +-
 arch/arm64/kernel/traps.c            |   6 +-
 8 files changed, 388 insertions(+), 10 deletions(-)

On Tue, Oct 10, 2017 at 07:38:28PM +0100, Dave P Martin wrote:
> diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
> index 026a7c7..b1409de 100644
> --- a/arch/arm64/include/asm/fpsimd.h
> +++ b/arch/arm64/include/asm/fpsimd.h
> @@ -72,6 +75,20 @@ extern void sve_load_state(void const *state, u32 const *pfpsr,
>  			   unsigned long vq_minus_1);
>  extern unsigned int sve_get_vl(void);
>  
> +#ifdef CONFIG_ARM64_SVE
> +
> +extern size_t sve_state_size(struct task_struct const *task);
> +
> +extern void sve_alloc(struct task_struct *task);
> +extern void fpsimd_release_thread(struct task_struct *task);
> +
> +#else /* ! CONFIG_ARM64_SVE */
> +
> +static void __maybe_unused sve_alloc(struct task_struct *task) { }
> +static void __maybe_unused fpsimd_release_thread(struct task_struct *task) { }

Nitpick: usually we just add static inline functions here rather than
__maybe_unused.

> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index 29adab8..4831d28 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -39,6 +47,8 @@
>  #define FPEXC_IDF	(1 << 7)
>  
>  /*
> + * (Note: in this discussion, statements about FPSIMD apply equally to SVE.)
> + *
>   * In order to reduce the number of times the FPSIMD state is needlessly saved
>   * and restored, we need to keep track of two things:
>   * (a) for each task, we need to remember which CPU was the last one to have
> @@ -99,6 +109,287 @@
>   */
>  static DEFINE_PER_CPU(struct fpsimd_state *, fpsimd_last_state);
>  
> +static void sve_free(struct task_struct *task)
> +{
> +	kfree(task->thread.sve_state);
> +	task->thread.sve_state = NULL;
> +}

I think we need a WARN_ON if TIF_SVE is still set here (and the callers
making sure it is cleared). I haven't checked the code paths via
fpsimd_release_thread() but wondering what happens if we get an
interrupt between freeing the state and making the pointer NULL, with
some context switching in a preemptible kernel.

Alternatively, always clear TIF_SVE here before freeing (also wondering
whether we should make sve_state NULL before the actual freeing but I
think TIF_SVE clearing should suffice).

> +/*
> + * TIF_SVE controls whether a task can use SVE without trapping while
> + * in userspace, and also the way a task's FPSIMD/SVE state is stored
> + * in thread_struct.
> + *
> + * The kernel uses this flag to track whether a user task is actively
> + * using SVE, and therefore whether full SVE register state needs to
> + * be tracked.  If not, the cheaper FPSIMD context handling code can
> + * be used instead of the more costly SVE equivalents.
> + *
> + *  * TIF_SVE set:
> + *
> + *    The task can execute SVE instructions while in userspace without
> + *    trapping to the kernel.
> + *
> + *    When stored, Z0-Z31 (incorporating Vn in bits[127:0] or the
> + *    corresponding Zn), P0-P15 and FFR are encoded in in
> + *    task->thread.sve_state, formatted appropriately for vector
> + *    length task->thread.sve_vl.
> + *
> + *    task->thread.sve_state must point to a valid buffer at least
> + *    sve_state_size(task) bytes in size.
> + *
> + *    During any syscall, the kernel may optionally clear TIF_SVE and
> + *    discard the vector state except for the FPSIMD subset.
> + *
> + *  * TIF_SVE clear:
> + *
> + *    An attempt by the user task to execute an SVE instruction causes
> + *    do_sve_acc() to be called, which does some preparation and then
> + *    sets TIF_SVE.
> + *
> + *    When stored, FPSIMD registers V0-V31 are encoded in
> + *    task->fpsimd_state; bits [max : 128] for each of Z0-Z31 are
> + *    logically zero but not stored anywhere; P0-P15 and FFR are not
> + *    stored and have unspecified values from userspace's point of
> + *    view.  For hygiene purposes, the kernel zeroes them on next use,
> + *    but userspace is discouraged from relying on this.
> + *
> + *    task->thread.sve_state does not need to be non-NULL, valid or any
> + *    particular size: it must not be dereferenced.
> + *
> + *  * FPSR and FPCR are always stored in task->fpsimd_state irrespctive of
> + *    whether TIF_SVE is clear or set, since these are not vector length
> + *    dependent.
> + */

This looks fine, thanks for adding the description.

On Wed, Oct 11, 2017 at 05:15:58PM +0100, Catalin Marinas wrote:
> On Tue, Oct 10, 2017 at 07:38:28PM +0100, Dave P Martin wrote:
> > diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
> > index 026a7c7..b1409de 100644
> > --- a/arch/arm64/include/asm/fpsimd.h
> > +++ b/arch/arm64/include/asm/fpsimd.h
> > @@ -72,6 +75,20 @@ extern void sve_load_state(void const *state, u32 const *pfpsr,
> >  			   unsigned long vq_minus_1);
> >  extern unsigned int sve_get_vl(void);
> >  
> > +#ifdef CONFIG_ARM64_SVE
> > +
> > +extern size_t sve_state_size(struct task_struct const *task);
> > +
> > +extern void sve_alloc(struct task_struct *task);
> > +extern void fpsimd_release_thread(struct task_struct *task);
> > +
> > +#else /* ! CONFIG_ARM64_SVE */
> > +
> > +static void __maybe_unused sve_alloc(struct task_struct *task) { }
> > +static void __maybe_unused fpsimd_release_thread(struct task_struct *task) { }
> 
> Nitpick: usually we just add static inline functions here rather than
> __maybe_unused.

Fair enough -- come to think of it I've already converted some other
instances of this at Ard's request.

> 
> > diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> > index 29adab8..4831d28 100644
> > --- a/arch/arm64/include/asm/processor.h
> > +++ b/arch/arm64/include/asm/processor.h
> > @@ -39,6 +47,8 @@
> >  #define FPEXC_IDF	(1 << 7)
> >  
> >  /*
> > + * (Note: in this discussion, statements about FPSIMD apply equally to SVE.)
> > + *
> >   * In order to reduce the number of times the FPSIMD state is needlessly saved
> >   * and restored, we need to keep track of two things:
> >   * (a) for each task, we need to remember which CPU was the last one to have
> > @@ -99,6 +109,287 @@
> >   */
> >  static DEFINE_PER_CPU(struct fpsimd_state *, fpsimd_last_state);
> >  
> > +static void sve_free(struct task_struct *task)
> > +{
> > +	kfree(task->thread.sve_state);
> > +	task->thread.sve_state = NULL;
> > +}
> 
> I think we need a WARN_ON if TIF_SVE is still set here (and the callers
> making sure it is cleared). I haven't checked the code paths via
> fpsimd_release_thread() but wondering what happens if we get an
> interrupt between freeing the state and making the pointer NULL, with
> some context switching in a preemptible kernel.

Having a WARN_ON() here may be a decent way to sanity-check that we
don't ever have sve_state NULL with TIF_SVE set.  This is a lot more
economical than putting a WARN_ON() at each dereference of sve_state
(of which there are quite a few).  sve_free() is also a slow path.

Currently, there are two callsites: sve_set_vector_length(), where we
test_and_clear_tsk_thread_flags(task, TIF_SVE) before calling sve_free();
and fpsimd_release_thread() where we "don't care" because the thread
is dying.

Looking more closely though, is the release_thread() path preemptible?
I can't see anything in the scheduler core to ensure this, nor any
general reason why it should be needed.

In which case preemption during thread exit after sve_free() could
result in a NULL deference in fpsimd_thread_switch().


So, I think my favoured approach is:

sve_release_thread()
{
	local_bh_disable();
	fpsimd_flush_task_state(current);
	clear_thread_flag(TIF_SVE);
	local_bh_enable();

	sve_free();
}

The local_bh stuff is cumbersome here, and could be replaced with
barrier()s to force the order of fpsimd_flusk_task_state() versus
clearing TIF_SVE.  Or should the barrier really be in
fpsimd_flush_task_state()?  Disabling softirqs avoids the need to answer
such questions...


Then:

sve_free(task)
{
	WARN_ON(test_thread_flag(TIF_SVE));

	barrier();
	kfree(task->thread.sve_state);
	tash->thread.sve_state = NULL;
}

I'm assuming here that kfree() can't be called safely from atomic
context, but this is unclear.  I would expect to be able to free
GFP_ATOMIC memory from atomic context (though sve_statue is GFP_KERNEL,
so dunno).

> Alternatively, always clear TIF_SVE here before freeing (also wondering
> whether we should make sve_state NULL before the actual freeing but I
> think TIF_SVE clearing should suffice).

Could do.  I feel that the current placement of the TIF_SVE clearing in
sve_set_vector_length() feels "more natural", but this is a pretty
flimsy argument.  How strongly do you feel about this?

[...]

> > + *  * TIF_SVE set:

[...]

> > + *  * TIF_SVE clear:
> > + *
> > + *    An attempt by the user task to execute an SVE instruction causes
> > + *    do_sve_acc() to be called, which does some preparation and then
> > + *    sets TIF_SVE.
> > + *
> > + *    When stored, FPSIMD registers V0-V31 are encoded in
> > + *    task->fpsimd_state; bits [max : 128] for each of Z0-Z31 are
> > + *    logically zero but not stored anywhere; P0-P15 and FFR are not
> > + *    stored and have unspecified values from userspace's point of
> > + *    view.  For hygiene purposes, the kernel zeroes them on next use,
> > + *    but userspace is discouraged from relying on this.
> > + *
> > + *    task->thread.sve_state does not need to be non-NULL, valid or any
> > + *    particular size: it must not be dereferenced.
> > + *
> > + *  * FPSR and FPCR are always stored in task->fpsimd_state irrespctive of
> > + *    whether TIF_SVE is clear or set, since these are not vector length
> > + *    dependent.
> > + */
> 
> This looks fine, thanks for adding the description.

OK, thanks for checking it.

Cheers
---Dave

On Thu, Oct 12, 2017 at 05:05:07PM +0100, Dave P Martin wrote:
> On Wed, Oct 11, 2017 at 05:15:58PM +0100, Catalin Marinas wrote:
> > On Tue, Oct 10, 2017 at 07:38:28PM +0100, Dave P Martin wrote:
> > > diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> > > index 29adab8..4831d28 100644
> > > --- a/arch/arm64/include/asm/processor.h
> > > +++ b/arch/arm64/include/asm/processor.h
> > > @@ -39,6 +47,8 @@
> > >  #define FPEXC_IDF	(1 << 7)
> > >  
> > >  /*
> > > + * (Note: in this discussion, statements about FPSIMD apply equally to SVE.)
> > > + *
> > >   * In order to reduce the number of times the FPSIMD state is needlessly saved
> > >   * and restored, we need to keep track of two things:
> > >   * (a) for each task, we need to remember which CPU was the last one to have
> > > @@ -99,6 +109,287 @@
> > >   */
> > >  static DEFINE_PER_CPU(struct fpsimd_state *, fpsimd_last_state);
> > >  
> > > +static void sve_free(struct task_struct *task)
> > > +{
> > > +	kfree(task->thread.sve_state);
> > > +	task->thread.sve_state = NULL;
> > > +}
> > 
> > I think we need a WARN_ON if TIF_SVE is still set here (and the callers
> > making sure it is cleared). I haven't checked the code paths via
> > fpsimd_release_thread() but wondering what happens if we get an
> > interrupt between freeing the state and making the pointer NULL, with
> > some context switching in a preemptible kernel.
> 
> Having a WARN_ON() here may be a decent way to sanity-check that we
> don't ever have sve_state NULL with TIF_SVE set.  This is a lot more
> economical than putting a WARN_ON() at each dereference of sve_state
> (of which there are quite a few).  sve_free() is also a slow path.
> 
> Currently, there are two callsites: sve_set_vector_length(), where we
> test_and_clear_tsk_thread_flags(task, TIF_SVE) before calling sve_free();
> and fpsimd_release_thread() where we "don't care" because the thread
> is dying.
> 
> Looking more closely though, is the release_thread() path preemptible?
> I can't see anything in the scheduler core to ensure this, nor any
> general reason why it should be needed.
> 
> In which case preemption during thread exit after sve_free() could
> result in a NULL deference in fpsimd_thread_switch().
> 
> 
> So, I think my favoured approach is:
> 
> sve_release_thread()
> {
> 	local_bh_disable();
> 	fpsimd_flush_task_state(current);
> 	clear_thread_flag(TIF_SVE);
> 	local_bh_enable();
> 
> 	sve_free();
> }
> 
> The local_bh stuff is cumbersome here, and could be replaced with
> barrier()s to force the order of fpsimd_flusk_task_state() versus
> clearing TIF_SVE.  Or should the barrier really be in
> fpsimd_flush_task_state()?  Disabling softirqs avoids the need to answer
> such questions...
> 
> 
> Then:
> 
> sve_free(task)
> {
> 	WARN_ON(test_thread_flag(TIF_SVE));
> 
> 	barrier();
> 	kfree(task->thread.sve_state);
> 	tash->thread.sve_state = NULL;
> }
> 
> I'm assuming here that kfree() can't be called safely from atomic
> context, but this is unclear.  I would expect to be able to free
> GFP_ATOMIC memory from atomic context (though sve_statue is GFP_KERNEL,
> so dunno).

The kfree should be fine.

Alternative proposal: free the SVE state in arch_release_task_struct().
This is called via the RCU mechanism and the task is no longer current,
so no preemption issues.

> > Alternatively, always clear TIF_SVE here before freeing (also wondering
> > whether we should make sve_state NULL before the actual freeing but I
> > think TIF_SVE clearing should suffice).
> 
> Could do.  I feel that the current placement of the TIF_SVE clearing in
> sve_set_vector_length() feels "more natural", but this is a pretty
> flimsy argument.  How strongly do you feel about this?

I agree with you, keep the TIF_SVE clearing in sve_set_vector_length().

On Fri, Oct 13, 2017 at 02:57:37PM +0100, Catalin Marinas wrote:
> On Thu, Oct 12, 2017 at 05:05:07PM +0100, Dave P Martin wrote:
> > On Wed, Oct 11, 2017 at 05:15:58PM +0100, Catalin Marinas wrote:
> > > On Tue, Oct 10, 2017 at 07:38:28PM +0100, Dave P Martin wrote:
> > > > diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> > > > index 29adab8..4831d28 100644
> > > > --- a/arch/arm64/include/asm/processor.h
> > > > +++ b/arch/arm64/include/asm/processor.h
> > > > @@ -39,6 +47,8 @@
> > > >  #define FPEXC_IDF	(1 << 7)
> > > >  
> > > >  /*
> > > > + * (Note: in this discussion, statements about FPSIMD apply equally to SVE.)
> > > > + *
> > > >   * In order to reduce the number of times the FPSIMD state is needlessly saved
> > > >   * and restored, we need to keep track of two things:
> > > >   * (a) for each task, we need to remember which CPU was the last one to have
> > > > @@ -99,6 +109,287 @@
> > > >   */
> > > >  static DEFINE_PER_CPU(struct fpsimd_state *, fpsimd_last_state);
> > > >  
> > > > +static void sve_free(struct task_struct *task)
> > > > +{
> > > > +	kfree(task->thread.sve_state);
> > > > +	task->thread.sve_state = NULL;
> > > > +}
> > > 
> > > I think we need a WARN_ON if TIF_SVE is still set here (and the callers
> > > making sure it is cleared). I haven't checked the code paths via
> > > fpsimd_release_thread() but wondering what happens if we get an
> > > interrupt between freeing the state and making the pointer NULL, with
> > > some context switching in a preemptible kernel.
> > 
> > Having a WARN_ON() here may be a decent way to sanity-check that we
> > don't ever have sve_state NULL with TIF_SVE set.  This is a lot more
> > economical than putting a WARN_ON() at each dereference of sve_state
> > (of which there are quite a few).  sve_free() is also a slow path.
> > 
> > Currently, there are two callsites: sve_set_vector_length(), where we
> > test_and_clear_tsk_thread_flags(task, TIF_SVE) before calling sve_free();
> > and fpsimd_release_thread() where we "don't care" because the thread
> > is dying.
> > 
> > Looking more closely though, is the release_thread() path preemptible?
> > I can't see anything in the scheduler core to ensure this, nor any
> > general reason why it should be needed.
> > 
> > In which case preemption during thread exit after sve_free() could
> > result in a NULL deference in fpsimd_thread_switch().
> > 
> > 
> > So, I think my favoured approach is:
> > 
> > sve_release_thread()
> > {
> > 	local_bh_disable();
> > 	fpsimd_flush_task_state(current);
> > 	clear_thread_flag(TIF_SVE);
> > 	local_bh_enable();
> > 
> > 	sve_free();
> > }
> > 
> > The local_bh stuff is cumbersome here, and could be replaced with
> > barrier()s to force the order of fpsimd_flusk_task_state() versus
> > clearing TIF_SVE.  Or should the barrier really be in
> > fpsimd_flush_task_state()?  Disabling softirqs avoids the need to answer
> > such questions...
> > 
> > 
> > Then:
> > 
> > sve_free(task)
> > {
> > 	WARN_ON(test_thread_flag(TIF_SVE));
> > 
> > 	barrier();
> > 	kfree(task->thread.sve_state);
> > 	tash->thread.sve_state = NULL;
> > }
> > 
> > I'm assuming here that kfree() can't be called safely from atomic
> > context, but this is unclear.  I would expect to be able to free
> > GFP_ATOMIC memory from atomic context (though sve_statue is GFP_KERNEL,
> > so dunno).
> 
> The kfree should be fine.
> 
> Alternative proposal: free the SVE state in arch_release_task_struct().
> This is called via the RCU mechanism and the task is no longer current,
> so no preemption issues.

Heh, I wasn't aware of that option.  That would be better, since
there's no value in the task still being schedulable while we do
the freeing.

Only SuperH seems to have a real version of that function, but it
frees some dynamically allocated state, which sounds familiar.

I'll take a look at moving over to this.

> 
> > > Alternatively, always clear TIF_SVE here before freeing (also wondering
> > > whether we should make sve_state NULL before the actual freeing but I
> > > think TIF_SVE clearing should suffice).
> > 
> > Could do.  I feel that the current placement of the TIF_SVE clearing in
> > sve_set_vector_length() feels "more natural", but this is a pretty
> > flimsy argument.  How strongly do you feel about this?
> 
> I agree with you, keep the TIF_SVE clearing in sve_set_vector_length().

OK, will do

Cheers
---Dave