Re: [PATCH 14/27] arm64/sve: Backend logic for setting the vector length

Dave Martin <[email protected]>
Newsgroups gmane.linux.kernel.cross-arch,gmane.comp.lib.glibc.alpha,gmane.comp.gdb.devel,gmane.comp.emulators.kvm.arm.devel,gmane.linux.ports.arm.kernel
Message-ID <[email protected]>
On Wed, Aug 23, 2017 at 04:33:18PM +0100, Alex Bennée wrote:
> 
> Dave Martin <[email protected]> writes:
> 
> > This patch implements the core logic for changing a task's vector
> > length on request from userspace.  This will be used by the ptrace
> > and prctl frontends that are implemented in later patches.
> >
> > The SVE architecture permits, but does not require, implementations
> > to support vector lengths that are not a power of two.  To handle
> > this, logic is added to check a requested vector length against a
> > possibly sparse bitmap of available vector lengths at runtime, so
> > that the best supported value can be chosen.
> >
> > Signed-off-by: Dave Martin <[email protected]>
> > ---
> >  arch/arm64/include/asm/fpsimd.h |   6 +++
> >  arch/arm64/kernel/fpsimd.c      | 116 ++++++++++++++++++++++++++++++++++++++++
> >  include/uapi/linux/prctl.h      |   5 ++
> >  3 files changed, 127 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
> > index 7efd04e..39b26d2 100644
> > --- a/arch/arm64/include/asm/fpsimd.h
> > +++ b/arch/arm64/include/asm/fpsimd.h
> > @@ -70,11 +70,15 @@ extern void fpsimd_update_current_state(struct fpsimd_state *state);
> >
> >  extern void fpsimd_flush_task_state(struct task_struct *target);
> >
> > +#define SVE_VL_ARCH_MAX 0x100
> > +
> 
> Hmm this isn't the same as SVE_VL_MAX. Why aren't we using that?

There should probably be a comment on this.

SVE vector-length agnostic software needs to be able to assume that
VL <= 256 (the SVE maximum), because some instructions won't work as
expected if this is not the case, particularly TBL, where in a larger
vector there's no guarantee that a vector index (which might be as small
as a byte) can index a vector element (of which there could be >256).

I really don't want to expose SVE_VL_ARCH_MAX to userspace, so that
people are not tempted to design data structures and protocols that
can't handle up to SVE_VL_MAX.  Exposing both together seemed to carry
a high risk of confusion and misuse.

Instead, I silently clamp to an SVE-compatible length (i.e.,
SVE_VL_ARCH_MAX) in sve_set_vector_length().  If future architecture
revisions support larger vectors later on, my plan is to require an
extra "force flag" to be passed to override the clamp.

[...]

Cheers
---Dave
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.