summaryrefslogtreecommitdiffstats
path: root/tools/testing/selftests/arm64/fp/vec-syscfg.c
Commit message (Collapse)AuthorAgeFilesLines
* kselftest/arm64: Don't probe the current VL for unsupported vector typesMark Brown2023-12-191-3/+11
| | | | | | | | | | | | | The vec-syscfg selftest verifies that setting the VL of the currently tested vector type does not disrupt the VL of the other vector type. To do this it records the current vector length for each type but neglects to guard this with a check for that vector type actually being supported. Add one, using a helper function which we also update all the other instances of this pattern. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20231218-kselftest-arm64-vec-syscfg-rdvl-v1-1-0ac22d47e81f@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
* kselftest/arm64: Validate that changing one VL type does not affect anotherMark Brown2023-07-271-1/+21
| | | | | | | | | | On a system with both SVE and SME when we change one of the VLs this should not result in a change in the other VL. Add a check that this is in fact the case to vec-syscfg. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230720-arm64-fix-sve-sme-vl-change-v2-3-8eea06b82d57@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
* kselftest/arm64: Add a test case for SVE VL changes with SME activeMark Brown2023-07-271-3/+102
| | | | | | | | | | | | | | | | | | We just fixed an issue where changing the SVE VL while SME was active could result in us attempting to save the streaming mode SVE vectors without any backing storage. Add a test case which provokes that issue, ideally we should also verify that the contents of ZA are unaffected by any of what we did. Note that since we need to keep streaming mode enabled we can't use any syscalls to trigger the issue, we have to sit in a loop in usersapce and hope to be preempted. The chosen numbers trigger with defconfig on all the virtual platforms for me, this won't be 100% on all systems but avoid an overcomplicated test implementation. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230720-arm64-fix-sve-sme-vl-change-v2-2-8eea06b82d57@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
* kselftest/arm64: Extend vector configuration API tests to cover SMEMark Brown2022-04-281-0/+10
| | | | | | | | | | | Provide RDVL helpers for SME and extend the main vector configuration tests to cover SME. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220419112247.711548-32-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
* selftests/arm64: remove ARRAY_SIZE define from vec-syscfg.cShuah Khan2021-12-101-2/+0
| | | | | | | | | | | | ARRAY_SIZE is defined in several selftests. Remove definitions from individual test files and include header file for the define instead. ARRAY_SIZE define is added in a separate patch to prepare for this change. Remove ARRAY_SIZE from vec-syscfg.c and pickup the one defined in kselftest.h. Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
* selftests: arm64: Verify that all possible vector lengths are handledMark Brown2021-09-291-0/+77
| | | | | | | | | | | | | 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 <broonie@kernel.org> Reviewed-by: Tomohiro Misono <misono.tomohiro@jp.fujitsu.com> Link: https://lore.kernel.org/r/20210929151925.9601-5-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
* selftests: arm64: Fix and enable test for setting current VL in vec-syscfgMark Brown2021-09-291-6/+4
| | | | | | | | | | | We had some test code for verifying that we can write the current VL via the prctl() interface but the condition for the test was inverted which wasn't noticed as it was never actually hooked up to the array of tests we execute. Fix this. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210929151925.9601-4-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
* selftests: arm64: Remove bogus error check on writing to filesMark Brown2021-09-291-6/+0
| | | | | | | | | Due to some refactoring with the error handling we ended up mangling things so we never actually set ret and therefore shouldn't be checking it. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210929151925.9601-3-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
* selftests: arm64: Fix printf() format mismatch in vec-syscfgMark Brown2021-09-291-1/+1
| | | | | | | | | The format for this error message calls for the plain text version of the error but we weren't supply it. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210929151925.9601-2-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
* kselftest/arm64: Add tests for SVE vector configurationMark Brown2021-08-031-0/+593
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@kernel.org> Reviewed-by: Dave Martin <Dave.Martin@arm.com> Link: https://lore.kernel.org/r/20210803140450.46624-4-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>