On Thu, Jul 29, 2021 at 06:37:12PM +0100, Mark Brown wrote:
> We provide interfaces for configuring the SVE vector length seen by
> processes using prctl and also via /proc for configuring the default
> values. Provide tests that exercise all these interfaces and verify that
> they take effect as expected, though at present no test fully enumerates
> all the possible vector lengths.
>
> A subset of this is already tested via sve-probe-vls but the /proc
> interfaces are not currently covered at all.
>
> In preparation for the forthcoming support for SME, the Scalable Matrix
> Extension, which has separately but similarly configured vector lengths
> which we expect to offer similar userspace interfaces for, all the actual
> files and prctls used are parameterised and we don't validate that the
> architectural minimum vector length is the minimum we see.
>
> Signed-off-by: Mark Brown <broonie@xxxxxxxxxx>
> ---
> tools/testing/selftests/arm64/fp/.gitignore | 1 +
> tools/testing/selftests/arm64/fp/Makefile | 3 +-
> tools/testing/selftests/arm64/fp/vec-syscfg.c | 594 ++++++++++++++++++
> 3 files changed, 597 insertions(+), 1 deletion(-)
> create mode 100644 tools/testing/selftests/arm64/fp/vec-syscfg.c
[...]
> diff --git a/tools/testing/selftests/arm64/fp/vec-syscfg.c b/tools/testing/selftests/arm64/fp/vec-syscfg.c
> new file mode 100644
> index 000000000000..15fec1aaeec6
> --- /dev/null
> +++ b/tools/testing/selftests/arm64/fp/vec-syscfg.c
[...]
> +static int stdio_read_integer(FILE *f, const char *what, int *val)
> +{
> + int ret, n;
> +
n needs to be initialised to 0, since fscanf won't touch it if there is
a matching failure before it reaches the %n conversion.
With that,
Reviewed-by: Dave Martin <Dave.Martin@xxxxxxx>
(One minor coment below, but that's just in relation to a possibly
future test.)
> + ret = fscanf(f, "%d%*1[\n]%n", val, &n);
> + if (ret < 1 || n < 1) {
> + ksft_print_msg("%d %d %d\n", ret, n, *val);
> + ksft_print_msg("failed to parse VL from %s\n", what);
> + return -1;
> + }
> +
> + return 0;
> +}
[...]
> +/* If we didn't request it a new VL shouldn't affect the child */
> +static void prctl_set_for_child(struct vec_data *data)
> +{
> + int ret, child_vl;
> +
> + if (data->min_vl == data->max_vl) {
> + ksft_test_result_skip("%s only one VL supported\n",
> + data->name);
> + return;
> + }
> +
> + ret = prctl(data->prctl_set, data->min_vl | PR_SVE_VL_INHERIT);
> + if (ret < 0) {
> + ksft_test_result_fail("%s prctl set failed for %d: %d (%s)\n",
> + data->name, data->min_vl,
> + errno, strerror(errno));
> + return;
> + }
> +
> + /* The _INHERIT flag should be present when we read the VL */
> + ret = prctl(data->prctl_get);
> + if (ret == -1) {
> + ksft_test_result_fail("%s prctl() read failed: %d (%s)\n",
> + data->name, errno, strerror(errno));
> + return;
> + }
> + if (!(ret & PR_SVE_VL_INHERIT)) {
> + ksft_test_result_fail("%s prctl() does not report _INHERIT\n",
> + data->name);
> + return;
> + }
It occurs to me that tt would make sense to test that the
PR_SVE_VL_INHERIT flag (or lack thereof) does the right thing for
further execs in the child. If reposting, it could make sense to add
this as a TODO, but don't sweat it otherwise.
[...]
Cheers
---Dave
