Re: [PATCH v2 26/28] arm64/sve: Add documentation

Szabolcs Nagy
2017-10-05T16:39:24Z

On 31/08/17 18:00, Dave Martin wrote:
> +prctl(PR_SVE_SET_VL, unsigned long arg)
> +
> + Sets the vector length of the calling thread and related flags, where
> + arg == vl | flags.
> +
> + vl is the desired vector length, where sve_vl_valid(vl) must be true.
> +
> + flags:
> +
> + PR_SVE_SET_VL_INHERIT
> +
> + Inherit the current vector length across execve(). Otherwise, the
> + vector length is reset to the system default at execve(). (See
> + Section 9.)
> +
> + PR_SVE_SET_VL_ONEXEC
> +
> + Defer the requested vector length change until the next execve().
> + This allows launching of a new program with a different vector
> + length, while avoiding runtime side effects in the caller.
> +
> + This also overrides the effect of PR_SVE_SET_VL_INHERIT for the
> + first execve().
> +
> + Without PR_SVE_SET_VL_ONEXEC, any outstanding deferred vector
> + length change is cancelled.
> +

based on later text it seems this works if exeve is
called in the same thread as prctl was called in.

this is a bit weird from user-space pov so it may
make sense to state it here explicitly.

> + Return value: a nonnegative on success, or a negative value on error:
> + EINVAL: SVE not supported, invalid vector length requested, or
> + invalid flags.
> +
> + On success, the calling thread's vector length is changed to the largest
> + value supported by the system that is less than or equal to vl.
> + If vl == SVE_VL_MAX, the calling thread's vector length is changed to the
> + largest value supported by the system.
> +
> + The returned value describes the resulting configuration, encoded as for
> + PR_SVE_GET_VL.
> +
> + Changing the vector length causes all of P0..P15, FFR and all bits of
> + Z0..V31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become
> + unspecified. Calling PR_SVE_SET_VL with vl equal to the thread's current
> + vector length does not constitute a change to the vector length for this
> + purpose.