#
48f7ab21 |
|
05-Dec-2023 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Log SVCR when the SME tests barf On failure we log the actual and expected value of the register we detect a mismatch in. For SME one obvious potential source of corruption would be if we had corrupted SVCR since changes in streaming mode will reset the register values, log the value to aid in understanding issues. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20231205-arm64-kselftest-log-svcr-v1-1-b77abd9ee7f3@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
|
#
11a7a42e |
|
22-Sep-2023 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Validate SVCR in streaming SVE stress test In the ZA and ZT test programs we explicitly validate that PSTATE.ZA is as expected on each loop but we do not do the equivalent for our streaming SVE test, add a check that we are still in streaming mode on every loop in case that goes wrong. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230922-arm64-ssve-validate-svcr-v1-1-f518960eaeda@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
cd57a658 |
|
12-Jan-2023 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Remove redundant _start labels from FP tests There are a number of freestanding static executables used in floating point testing that have no runtime at all. These all define the main entry point as: .globl _start function _start _start: but clang's integrated assembler complains that: error: symbol '_start' is already defined due to having both a label and function directive. Remove the label to allow building with clang. No functional change. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20230111-arm64-kselftest-clang-v1-2-89c69d377727@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
d47d8a5e |
|
06-Sep-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Install signal handlers before output in FP stress tests To interface more robustly with other processes install the signal handers in the floating point stress tests before we produce any output, this means that a parent process can know that if it has seen any output from the test then the test is ready to handle incoming signals. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220906220056.820295-1-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
05a5980f |
|
29-Aug-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Count SIGUSR2 deliveries in FP stress tests Currently the floating point stress tests mostly support testing that the data they are checking can be disrupted from a signal handler triggered by SIGUSR1. This is not properly implemented for all the tests and in testing is frequently modified to just handle the signal without corrupting data in order to ensure that signal handling does not corrupt data. Directly support this usage by installing a SIGUSR2 handler which simply counts the signal delivery. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220829154452.824870-3-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
4126bde0 |
|
18-Apr-2022 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: sme: Provide streaming mode SVE stress test One of the features of SME is the addition of streaming mode, in which we have access to a set of streaming mode SVE registers at the SME vector length. Since these are accessed using the SVE instructions let's reuse the existing SVE stress test for testing with a compile time option for controlling the few small differences needed: - Enter streaming mode immediately on starting the program. - In streaming mode FFR is removed so skip reading and writing FFR. 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-33-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
260ea4ba |
|
19-Oct-2021 |
Mark Brown <broonie@kernel.org> |
selftests: arm64: Factor out utility functions for assembly FP tests The various floating point test programs written in assembly have a bunch of helper functions and macros which are cut'n'pasted between them. Factor them out into a separate source file which is linked into all of them. We don't include memcmp() since it isn't as generic as it should be and directly branches to report an error in the programs. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20211019181851.3341232-1-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
|
#
7011d725 |
|
18-Mar-2021 |
Andre Przywara <andre.przywara@arm.com> |
kselftest/arm64: sve: Do not use non-canonical FFR register value The "First Fault Register" (FFR) is an SVE register that mimics a predicate register, but clears bits when a load or store fails to handle an element of a vector. The supposed usage scenario is to initialise this register (using SETFFR), then *read* it later on to learn about elements that failed to load or store. Explicit writes to this register using the WRFFR instruction are only supposed to *restore* values previously read from the register (for context-switching only). As the manual describes, this register holds only certain values, it: "... contains a monotonic predicate value, in which starting from bit 0 there are zero or more 1 bits, followed only by 0 bits in any remaining bit positions." Any other value is UNPREDICTABLE and is not supposed to be "restored" into the register. The SVE test currently tries to write a signature pattern into the register, which is *not* a canonical FFR value. Apparently the existing setups treat UNPREDICTABLE as "read-as-written", but a new implementation actually only stores canonical values. As a consequence, the sve-test fails immediately when comparing the FFR value: ----------- # ./sve-test Vector length: 128 bits PID: 207 Mismatch: PID=207, iteration=0, reg=48 Expected [cf00] Got [0f00] Aborted ----------- Fix this by only populating the FFR with proper canonical values. Effectively the requirement described above limits us to 17 unique values over 16 bits worth of FFR, so we condense our signature down to 4 bits (2 bits from the PID, 2 bits from the generation) and generate the canonical pattern from it. Any bits describing elements above the minimum 128 bit are set to 0. This aligns the FFR usage to the architecture and fixes the test on microarchitectures implementing FFR in a more restricted way. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviwed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210319120128.29452-1-andre.przywara@arm.com Signed-off-by: Will Deacon <will@kernel.org>
|
#
3a57a643 |
|
08-Jan-2021 |
Mark Brown <broonie@kernel.org> |
arm64: selftests: Fix spelling of 'Mismatch' The SVE and FPSIMD stress tests have a spelling mistake in the output, fix it. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210108183144.673-1-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
5e992c63 |
|
18-Aug-2020 |
Mark Brown <broonie@kernel.org> |
selftests: arm64: Add stress tests for FPSMID and SVE context switching Add programs sve-test and fpsimd-test which spin reading and writing to the SVE and FPSIMD registers, verifying the operations they perform. The intended use is to leave them running to stress the context switch code's handling of these registers which isn't compatible with what kselftest does so they're not integrated into the framework but there's no other obvious testsuite where they fit so let's store them here. These tests were written by Dave Martin and lightly adapted by me. Signed-off-by: Mark Brown <broonie@kernel.org> Acked-by: Dave Martin <Dave.Martin@arm.com> Acked-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20200819114837.51466-4-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
|