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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux