| 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 b
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>
show more ...
|
| 0ba1ce1e | 05-Oct-2021 |
Mark Brown <broonie@kernel.org> |
selftests: arm64: Add coverage of ptrace flags for SVE VL inheritance
Add a test that covers enabling and disabling of SVE vector length
inheritance via the ptrace interface.
Signed-off-by: Mark Br
selftests: arm64: Add coverage of ptrace flags for SVE VL inheritance
Add a test that covers enabling and disabling of SVE vector length
inheritance via the ptrace interface.
Signed-off-by: Mark Brown <broonie@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20211005123537.976795-1-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
| 8694e5e6 | 29-Sep-2021 |
Mark Brown <broonie@kernel.org> |
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, t
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 <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>
show more ...
|
| e4239115 | 29-Sep-2021 |
Mark Brown <broonie@kernel.org> |
selftests: arm64: Fix and enable test for setting current VL in vec-syscfg
We had some test code for verifying that we can write the current VL via
the prctl() interface but the condition for the te
selftests: arm64: Fix and enable test for setting current VL in vec-syscfg
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>
show more ...
|
| 4caf339c | 29-Sep-2021 |
Mark Brown <broonie@kernel.org> |
selftests: arm64: Remove bogus error check on writing to files
Due to some refactoring with the error handling we ended up mangling things
so we never actually set ret and therefore shouldn't be che
selftests: arm64: Remove bogus error check on writing to files
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>
show more ...
|
| ff944c44 | 29-Sep-2021 |
Mark Brown <broonie@kernel.org> |
selftests: arm64: Fix printf() format mismatch in vec-syscfg
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 <bro
selftests: arm64: Fix printf() format mismatch in vec-syscfg
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>
show more ...
|
| 34785030 | 13-Sep-2021 |
Mark Brown <broonie@kernel.org> |
selftests: arm64: Move FPSIMD in SVE ptrace test into a function
Now that all the other tests are in functions rather than inline in the
main parent process function also move the test for accessing
selftests: arm64: Move FPSIMD in SVE ptrace test into a function
Now that all the other tests are in functions rather than inline in the
main parent process function also move the test for accessing the FPSIMD
registers via the SVE regset out into their own function.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210913125505.52619-9-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
| a1d71112 | 13-Sep-2021 |
Mark Brown <broonie@kernel.org> |
selftests: arm64: More comprehensively test the SVE ptrace interface
Currently the selftest for the SVE register set is not quite as thorough
as is desirable - it only validates that the value of a
selftests: arm64: More comprehensively test the SVE ptrace interface
Currently the selftest for the SVE register set is not quite as thorough
as is desirable - it only validates that the value of a single Z register
is not modified by a partial write to a lower numbered Z register after
having previously been set through the FPSIMD regset.
Make this more thorough:
- Test the ability to set vector lengths and enumerate those supported in
the system.
- Validate data in all Z and P registers, plus FPSR and FPCR.
- Test reads via the FPSIMD regset after set via the SVE regset.
There's still some oversights, the main one being that due to the need to
generate a pattern in FFR and the fact that this rewrite is primarily
motivated by SME's streaming SVE which doesn't have FFR we don't currently
test FFR. Update the TODO to reflect those that occurred to me (and fix an
adjacent typo in there).
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210913125505.52619-8-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
| 9f7d03a2 | 13-Sep-2021 |
Mark Brown <broonie@kernel.org> |
selftests: arm64: Verify interoperation of SVE and FPSIMD register sets
After setting the FPSIMD registers via the SVE register set read them back
via the FPSIMD register set, validating that the tw
selftests: arm64: Verify interoperation of SVE and FPSIMD register sets
After setting the FPSIMD registers via the SVE register set read them back
via the FPSIMD register set, validating that the two register sets are
interoperating and that the values we thought we set made it into the
child process.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210913125505.52619-7-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
| 8c9eece0 | 13-Sep-2021 |
Mark Brown <broonie@kernel.org> |
selftests: arm64: Clarify output when verifying SVE register set
When verifying setting a Z register via ptrace we check each byte by hand,
iterating over the buffer using a pointer called p and tre
selftests: arm64: Clarify output when verifying SVE register set
When verifying setting a Z register via ptrace we check each byte by hand,
iterating over the buffer using a pointer called p and treating each
register value written as a test. This creates output referring to "p[X]"
which is confusing since SVE also has predicate registers Pn. Tweak the
output to avoid confusion here.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210913125505.52619-6-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
| 736e6d5a | 13-Sep-2021 |
Mark Brown <broonie@kernel.org> |
selftests: arm64: Document what the SVE ptrace test is doing
Before we go modifying it further let's add some comments and output
clarifications explaining what this test is actually doing.
Signed-
selftests: arm64: Document what the SVE ptrace test is doing
Before we go modifying it further let's add some comments and output
clarifications explaining what this test is actually doing.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210913125505.52619-5-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
| eab281e3 | 13-Sep-2021 |
Mark Brown <broonie@kernel.org> |
selftests: arm64: Remove extraneous register setting code
For some reason the SVE ptrace test code starts off by setting values in
some of the SVE vector registers in the parent process which it the
selftests: arm64: Remove extraneous register setting code
For some reason the SVE ptrace test code starts off by setting values in
some of the SVE vector registers in the parent process which it then never
interacts with when verifying the ptrace interfaces. This is not especially
relevant to what's being tested and somewhat confusing when reading the
code so let's remove it.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210913125505.52619-4-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
| 09121ad7 | 13-Sep-2021 |
Mark Brown <broonie@kernel.org> |
selftests: arm64: Don't log child creation as a test in SVE ptrace test
Currently we log the creation of the child process as a test but it's not
really relevant to what we're trying to test and can
selftests: arm64: Don't log child creation as a test in SVE ptrace test
Currently we log the creation of the child process as a test but it's not
really relevant to what we're trying to test and can make the output a
little confusing so don't do that.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210913125505.52619-3-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
| e96595c5 | 03-Aug-2021 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Add a TODO list for floating point tests
Write down some ideas for additional coverage for floating point in case
someone feels inspired to look into them.
Signed-off-by: Mark Brow
kselftest/arm64: Add a TODO list for floating point tests
Write down some ideas for additional coverage for floating point in case
someone feels inspired to look into them.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Link: https://lore.kernel.org/r/20210803140450.46624-5-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| 95cf3f23 | 03-Aug-2021 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Add tests for SVE vector configuration
We provide interfaces for configuring the SVE vector length seen by
processes using prctl and also via /proc for configuring the default
value
kselftest/arm64: Add tests for SVE vector configuration
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>
show more ...
|
| b43ab36a | 03-Aug-2021 |
Mark Brown <broonie@kernel.org> |
kselftest/arm64: Validate vector lengths are set in sve-probe-vls
Currently sve-probe-vls does not verify that the vector lengths reported
by the prctl() interface are actually what is reported by t
kselftest/arm64: Validate vector lengths are set in sve-probe-vls
Currently sve-probe-vls does not verify that the vector lengths reported
by the prctl() interface are actually what is reported by the architecture,
use the rdvl_sve() helper to validate this.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Link: https://lore.kernel.org/r/20210803140450.46624-3-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
| 7011d725 | 19-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
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>
show more ...
|
| e093256d | 19-Aug-2020 |
Mark Brown <broonie@kernel.org> |
selftests: arm64: Add build and documentation for FP tests
Integrate the FP tests with the build system and add some documentation
for the ones run outside the kselftest infrastructure. The content
selftests: arm64: Add build and documentation for FP tests
Integrate the FP tests with the build system and add some documentation
for the ones run outside the kselftest infrastructure. The content in
the README was largely written by Dave Martin with edits 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-7-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|