selftests: arm64: vec-syscfg updates

Subject: [PATCH v2 4/4] selftests: arm64: Verify that all possible vector lengths are handled

As part of the enumeration interface for setting vector lengths it is valid to set vector lengths not supported in the system, these will be rounded to a supported vector length and returned from the prctl(). Add a test which exercises this for every valid vector length and makes sure that the return value is as expected and that this is reflected in the actual system state.

Signed-off-by Mark Brown <[email protected]>

---
 tools/testing/selftests/arm64/fp/vec-syscfg.c | 71
+++++++++++++++++++
 1 file changed, 71 insertions(+)

tools/testing/selftests/arm64/fp/vec-syscfg.c +48 -0

index 9d6ac843e651..de11cd2f5d79 100644
@@ -540,6 +540,76 @@ static void prctl_set_onexec(struct vec_data *data)
 	file_write_integer(data->default_vl_file, data->default_vl);
 }
 
+/* For each VQ verify that setting via prctl() does the right thing */
+static void prctl_set_all_vqs(struct vec_data *data)
+{
+	int ret, vq, vl, new_vl;
+	int errors = 0;
+
+	for (vq = SVE_VQ_MIN; vq <= SVE_VQ_MAX; vq++) {
+		vl = sve_vl_from_vq(vq);
+
+		/* Attempt to set the VL */
+		ret = prctl(data->prctl_set, vl);
+		if (ret < 0) {
+			errors++;
+			ksft_print_msg("%s prctl set failed for %d: %d
 (%s)\n",
+				       data->name, vl,
+				       errno, strerror(errno));
+			continue;
+		}
+
+		new_vl = ret & PR_SVE_VL_LEN_MASK;
+
+		/* Check that we actually have the reported new VL */
+		if (data->rdvl() != new_vl) {
+			ksft_print_msg("Set %s VL %d but RDVL
 reports %d\n",
+				       data->name, new_vl, data->rdvl());
+			errors++;
+		}
+
+		/* Was that the VL we asked for? */
+		if (new_vl == vl)
+			continue;
+
+		/* Should round up to the minimum VL if below it */
+		if (vl < data->min_vl) {
+			if (new_vl != data->min_vl) {
+				ksft_print_msg("%s VL %d returned %d not
 minimum %d\n",
+					       data->name, vl, new_vl,
+					       data->min_vl);
+				errors++;
+			}
+
+			continue;
+		}
+
+		/* Should round down to maximum VL if above it */
+		if (vl > data->max_vl) {
+			if (new_vl != data->max_vl) {
+				ksft_print_msg("%s VL %d returned %d not

maximum %d\n",

tools/testing/selftests/arm64/fp/vec-syscfg.c +11 -0

+					       data->name, vl, new_vl,
+					       data->max_vl);
+				errors++;
+			}
+
+			continue;
+		}
+
+		/* Otherwise we should've rounded down */
+		if (!(new_vl < vl)) {
+			ksft_print_msg("%s VL %d returned %d, did not round

down\n",

tools/testing/selftests/arm64/fp/vec-syscfg.c +12 -1

+				       data->name, vl, new_vl);
+			errors++;
+
+			continue;
+		}
+	}
+
+	ksft_test_result(errors == 0, "%s prctl() set all VLs, %d errors\n",
+			 data->name, errors);
+}
+
 typedef void (*test_type)(struct vec_data *);
 
 static const test_type tests[] = {

@@ -557,6 +627,7 @@ static const test_type tests[] = {
 	prctl_set_no_child,
 	prctl_set_for_child,
 	prctl_set_onexec,
+	prctl_set_all_vqs,
 };
 
 int main(void)
--

2.20.1

This series fixes up a few issues introduced into vec-syscfg during refactoring in the review process, then adds a new test which ensures that the behaviour when we attempt to set a vector length which is not supported by the current system matches what is documented in the SVE ABI documentation.

v2:
- Fix handling of missing VLs when checking that vector length setting works as expected.

With this series applied, I see a test failing under qemu with:

# selftests: arm64: vec-syscfg
# TAP version 13
# 1..10

# ok 1 SVE default vector length 64
# ok 2 # SKIP Need to be root to write to /proc
# ok 3 # SKIP Need to be root to write to /proc

# ok 4 SVE current VL is 64
# ok 5 SVE set VL 64 and have VL 64
# ok 6 # SKIP SVE only one VL supported
# ok 7 # SKIP SVE only one VL supported
# ok 8 # SKIP SVE only one VL supported
# ok 9 # SKIP SVE only one VL supported
# # SVE VL 272 returned 256 not maximum 0

Quoted 8 lines · Will Deacon

With this series applied, I see a test failing under qemu with:

# selftests: arm64: vec-syscfg
# TAP version 13
# 1..10

# ok 1 SVE default vector length 64
# ok 2 # SKIP Need to be root to write to /proc
# ok 3 # SKIP Need to be root to write to /proc

AFAICT this is due to running as a non-root user, the testsuite was already having serious issues before then...

Quoted 7 lines

# ok 4 SVE current VL is 64
# ok 5 SVE set VL 64 and have VL 64
# ok 6 # SKIP SVE only one VL supported
# ok 7 # SKIP SVE only one VL supported
# ok 8 # SKIP SVE only one VL supported
# ok 9 # SKIP SVE only one VL supported
# # SVE VL 272 returned 256 not maximum 0

...as it's starting off by testing an interface that's only writable by root and then relying on that information, the existing tests were also not working usefully. qemu by default supports way more than one vector length. In any case it's just the test added by the last patch that's causing the output here, the first four patches should be fine and fix issues.

I'm not sure it's a particularly good idea to run kselftest as a non-root user TBH, it's going to cause you to skip a lot of tests.

Quoted 2 lines · Mark Brown

I'm not sure it's a particularly good idea to run kselftest as a non-root user TBH, it's going to cause you to skip a lot of tests.

Ah, thanks for pointing that out. It would probably be better to skip the tests rather than fail them if they're not running with sufficient permissions, but I'll go ahead and queue your v3 for now.

Quoted 29 lines · Mark Brown

Quoted 8 lines · Will Deacon

With this series applied, I see a test failing under qemu with:

# selftests: arm64: vec-syscfg
# TAP version 13
# 1..10

# ok 1 SVE default vector length 64
# ok 2 # SKIP Need to be root to write to /proc
# ok 3 # SKIP Need to be root to write to /proc

AFAICT this is due to running as a non-root user, the testsuite was already having serious issues before then...

Quoted 7 lines

# ok 4 SVE current VL is 64
# ok 5 SVE set VL 64 and have VL 64
# ok 6 # SKIP SVE only one VL supported
# ok 7 # SKIP SVE only one VL supported
# ok 8 # SKIP SVE only one VL supported
# ok 9 # SKIP SVE only one VL supported
# # SVE VL 272 returned 256 not maximum 0

...as it's starting off by testing an interface that's only writable by root and then relying on that information, the existing tests were also not working usefully. qemu by default supports way more than one vector length. In any case it's just the test added by the last patch that's causing the output here, the first four patches should be fine and fix issues.

Quoted 2 lines

I'm not sure it's a particularly good idea to run kselftest as a non-root user TBH, it's going to cause you to skip a lot of tests.

Ah, thanks for pointing that out. It would probably be better to skip the tests rather than fail them if they're not running with sufficient permissions, but I'll go ahead and queue your v3 for now.

Quoted 4 lines · Will Deacon

Quoted 2 lines · Mark Brown

I'm not sure it's a particularly good idea to run kselftest as a non-root user TBH, it's going to cause you to skip a lot of tests.

We don't want Kselftest default run to be as root. Users can choose to run as root which would be an explicit choice so they expect and plan for the impact. Example panic test.

Quoted 3 lines

Ah, thanks for pointing that out. It would probably be better to skip the tests rather than fail them if they're not running with sufficient permissions, but I'll go ahead and queue your v3 for now.

Correct. I would like to see tests skipped not failed if either config or permissions are lacking to run the tests.

Quoted 5 lines · Shuah Khan

Quoted 4 lines · Will Deacon

Quoted 2 lines · Mark Brown

I'm not sure it's a particularly good idea to run kselftest as a non-root user TBH, it's going to cause you to skip a lot of tests.

Quoted 3 lines

We don't want Kselftest default run to be as root. Users can choose to run as root which would be an explicit choice so they expect and plan for the impact. Example panic test.

OTOH if you're trying to verify that the tests aren't broken it's not that great since it'll mean that you'll not be exercising a bunch of the code.