History log of /linux-master/tools/testing/selftests/arm64/signal/testcases/ssve_regs.c
Revision Date Author Comments
# 5f389238 31-Jan-2023 Mark Brown <broonie@kernel.org>

kselftest/arm64: Fix enumeration of systems without 128 bit SME

The current signal handling tests for SME do not account for the fact that
unlike SVE all SME vector lengths are optional so we can't guarantee that
we will encounter the minimum possible VL, they will hang enumerating VLs
on such systems. Abort enumeration when we find the lowest VL.

Fixes: 4963aeb35a9e ("kselftest/arm64: signal: Add SME signal handling tests")
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230131-arm64-kselftest-sig-sme-no-128-v1-1-d47c13dc8e1e@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>


# 4365eec8 31-Jan-2023 Mark Brown <broonie@kernel.org>

kselftest/arm64: Don't require FA64 for streaming SVE tests

During early development a dependedncy was added on having FA64
available so we could use the full FPSIMD register set in the signal
handler. Subsequently the ABI was finialised so the handler is run with
streaming mode disabled meaning this is redundant but the dependency was
never removed, do so now.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230131-arm64-kselfetest-ssve-fa64-v1-1-f418efcc2b60@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>


# f76cb73a 19-Jan-2023 Mark Brown <broonie@kernel.org>

kselftest/arm64: Verify that SSVE signal context has SVE_SIG_FLAG_SM set

Streaming mode SVE signal context should have SVE_SIG_FLAG_SM set but we
were not actually validating this. Add a check.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230117-arm64-test-ssve-za-v1-1-203c00150154@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>


# 31ba6342 29-Aug-2022 Mark Brown <broonie@kernel.org>

kselftest/arm64: Include larger SVE and SME VLs in signal tests

Now that the core utilities for signal testing support handling data in
EXTRA_CONTEXT blocks we can test larger SVE and SME VLs which spill over
the limits in the base signal context. This is done by defining storage
for the context as a union with a ucontext_t and a buffer together with
some helpers for getting relevant sizes and offsets like we do for
fake_sigframe, this isn't the most lovely code ever but is fairly
straightforward to implement and much less invasive to the somewhat
unclear and indistinct layers of abstraction in the signal handling test
code.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220829160703.874492-11-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>


# 38150a62 29-Aug-2022 Mark Brown <broonie@kernel.org>

kselftest/arm64: Allow larger buffers in get_signal_context()

In order to allow testing of signal contexts that overflow the base signal
frame allow callers to pass the buffer size for the user context into
get_signal_context(). No functional change.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220829160703.874492-10-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>


# 4963aeb3 18-Apr-2022 Mark Brown <broonie@kernel.org>

kselftest/arm64: signal: Add SME signal handling tests

Add test cases for the SME signal handing ABI patterned off the SVE tests.
Due to the small size of the tests and the differences in ABI (especially
around needing to account for both streaming SVE and ZA) there is some code
duplication here.

We currently cover:
- Reporting of the vector length.
- Lack of support for changing vector length.
- Presence and size of register state for streaming SVE and ZA.

As with the SVE tests we do not yet have any validation of register
contents.

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-36-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>