- Linux-kselftest-mirror - lists.linaro.org

[PATCH bpf-next v1 0/3] bpf, sockmap: Improve performance with CPU affinity

by Jiayuan Chen

Abstract === This patchset improves the performance of sockmap by providing CPU affinity, resulting in a 1-10x increase in throughput. Motivation === Traditional user-space reverse proxy: Reserve Proxy _________________ client -> | fd1 <-> fd2 | -> server |_________________| Using sockmap for reverse proxy: Reserve Proxy _________________ client -> | fd1 <-> fd2 | -> server | |_________________| | | | | | | _________ | | | sockmap | | --> |_________| --> By adding fds to sockmap and using a BPF program, we can quickly forward data and avoid data copying between user space and kernel space. Mainstream multi-process reverse proxy applications, such as Nginx and HAProxy, support CPU affinity settings, which allow each process to be pinned to a specific CPU, avoiding conflicts between data plane processes and other processes, especially in multi-tenant environments. Current Issues === The current design of sockmap uses a workqueue to forward ingress_skb and wakes up the workqueue without specifying a CPU (by calling schedule_delayed_work()). In the current implementation of schedule_delayed_work, it tends to run the workqueue on the current CPU. This approach has a high probability of running on the current CPU, which is the same CPU that handles the net rx soft interrupt, especially for programs that access each other using local interfaces. The loopback driver's transmit interface, loopback_xmit(), directly calls __netif_rx() on the current CPU, which means that the CPU handling sockmap's workqueue and the client's sending CPU are the same, resulting in contention. For a TCP flow, if the request or response is very large, the psock->ingress_skb queue can become very long. When the workqueue traverses this queue to forward the data, it can consume a significant amount of CPU time. Solution === Configuring RPS on a loopback interface can be useful, but it will trigger additional softirq, and furthermore, it fails to achieve our expected effect of CPU isolation from other processes. Instead, we provide a kfunc that allow users to specify the CPU on which the workqueue runs through a BPF program. We can use the existing benchmark to test the performance, which allows us to evaluate the effectiveness of this optimization. Because we use local interfaces for communication and the client consumes a significant amount of CPU when sending data, this prevents the workqueue from processing ingress_skb in a timely manner, ultimately causing the server to fail to read data quickly. Without cpu-affinity: ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --no-verify Setting up benchmark 'sockmap'... create socket fd c1:14 p1:15 c2:16 p2:17 Benchmark 'sockmap' started. Iter 0 ( 36.031us): Send Speed 1143.693 MB/s ... Rcv Speed 109.572 MB/s Iter 1 ( 0.608us): Send Speed 1320.550 MB/s ... Rcv Speed 48.103 MB/s Iter 2 ( -5.448us): Send Speed 1314.790 MB/s ... Rcv Speed 47.842 MB/s Iter 3 ( -0.613us): Send Speed 1320.158 MB/s ... Rcv Speed 46.531 MB/s Iter 4 ( -3.441us): Send Speed 1319.375 MB/s ... Rcv Speed 46.662 MB/s Iter 5 ( 3.764us): Send Speed 1166.667 MB/s ... Rcv Speed 42.467 MB/s Iter 6 ( -4.404us): Send Speed 1319.508 MB/s ... Rcv Speed 47.973 MB/s Summary: total trans 7758 MB ± 1293.506 MB/s Without cpu-affinity(RPS enabled): ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --no-verify Setting up benchmark 'sockmap'... create socket fd c1:14 p1:15 c2:16 p2:17 Benchmark 'sockmap' started. Iter 0 ( 28.925us): Send Speed 1630.357 MB/s ... Rcv Speed 850.960 MB/s Iter 1 ( -2.042us): Send Speed 1644.564 MB/s ... Rcv Speed 822.478 MB/s Iter 2 ( 0.754us): Send Speed 1644.297 MB/s ... Rcv Speed 850.787 MB/s Iter 3 ( 0.159us): Send Speed 1644.429 MB/s ... Rcv Speed 850.198 MB/s Iter 4 ( -2.898us): Send Speed 1646.924 MB/s ... Rcv Speed 830.867 MB/s Iter 5 ( -0.210us): Send Speed 1649.410 MB/s ... Rcv Speed 824.246 MB/s Iter 6 ( -1.448us): Send Speed 1650.723 MB/s ... Rcv Speed 808.256 MB/s With cpu-affinity(RPS disabled): ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --no-verify --cpu-affinity Setting up benchmark 'sockmap'... create socket fd c1:14 p1:15 c2:16 p2:17 Benchmark 'sockmap' started. Iter 0 ( 36.051us): Send Speed 1883.437 MB/s ... Rcv Speed 1865.087 MB/s Iter 1 ( 1.246us): Send Speed 1900.542 MB/s ... Rcv Speed 1761.737 MB/s Iter 2 ( -8.595us): Send Speed 1883.128 MB/s ... Rcv Speed 1860.714 MB/s Iter 3 ( 7.033us): Send Speed 1890.831 MB/s ... Rcv Speed 1806.684 MB/s Iter 4 ( -8.397us): Send Speed 1884.700 MB/s ... Rcv Speed 1973.568 MB/s Iter 5 ( -1.822us): Send Speed 1894.125 MB/s ... Rcv Speed 1775.046 MB/s Iter 6 ( 4.936us): Send Speed 1877.597 MB/s ... Rcv Speed 1959.320 MB/s Summary: total trans 11328 MB ± 1888.507 MB/s Appendix === Through this optimization, we discovered that sk_mem_charge() and sk_mem_uncharge() have concurrency issues. The performance improvement brought by this optimization has made these concurrency issues more evident. This concurrency issue can cause the WARN_ON_ONCE(sk->sk_forward_alloc) check to be triggered when the socket is released. Since this patch is a feature-type patch and does not intend to fix this bug, I will provide additional patches to fix this issue later. Jiayuan Chen (3): bpf, sockmap: Introduce a new kfunc for sockmap bpf, sockmap: Affinitize workqueue to a specific CPU selftest/bpf/benchs: Add cpu-affinity for sockmap bench Documentation/bpf/map_sockmap.rst | 14 +++++++ include/linux/skmsg.h | 15 +++++++ kernel/bpf/btf.c | 3 ++ net/core/skmsg.c | 10 +++-- net/core/sock_map.c | 39 +++++++++++++++++++ .../selftests/bpf/benchs/bench_sockmap.c | 35 +++++++++++++++-- tools/testing/selftests/bpf/bpf_kfuncs.h | 6 +++ .../selftests/bpf/progs/bench_sockmap_prog.c | 7 ++++ 8 files changed, 122 insertions(+), 7 deletions(-) -- 2.47.1

2 months

3
8
0 0

[PATCH AUTOSEL 6.6 19/21] selftests/bpf: Mitigate sockmap_ktls disconnect_after_delete failure

by Sasha Levin

From: Ihor Solodrai <ihor.solodrai(a)linux.dev> [ Upstream commit f2858f308131a09e33afb766cd70119b5b900569 ] "sockmap_ktls disconnect_after_delete" test has been failing on BPF CI after recent merges from netdev: * https://github.com/kernel-patches/bpf/actions/runs/14458537639 * https://github.com/kernel-patches/bpf/actions/runs/14457178732 It happens because disconnect has been disabled for TLS [1], and it renders the test case invalid. Removing all the test code creates a conflict between bpf and bpf-next, so for now only remove the offending assert [2]. The test will be removed later on bpf-next. [1] https://lore.kernel.org/netdev/20250404180334.3224206-1-kuba@kernel.org/ [2] https://lore.kernel.org/bpf/cfc371285323e1a3f3b006bfcf74e6cf7ad65258@linux.… Signed-off-by: Ihor Solodrai <ihor.solodrai(a)linux.dev> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Reviewed-by: Jiayuan Chen <jiayuan.chen(a)linux.dev> Link: https://lore.kernel.org/bpf/20250416170246.2438524-1-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c b/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c index 2d0796314862a..0a99fd404f6dc 100644 --- a/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c +++ b/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c @@ -68,7 +68,6 @@ static void test_sockmap_ktls_disconnect_after_delete(int family, int map) goto close_cli; err = disconnect(cli); - ASSERT_OK(err, "disconnect"); close_cli: close(cli); -- 2.39.5

2 months

1
0
0 0

[PATCH AUTOSEL 6.12 33/37] selftests/bpf: Mitigate sockmap_ktls disconnect_after_delete failure

by Sasha Levin

From: Ihor Solodrai <ihor.solodrai(a)linux.dev> [ Upstream commit f2858f308131a09e33afb766cd70119b5b900569 ] "sockmap_ktls disconnect_after_delete" test has been failing on BPF CI after recent merges from netdev: * https://github.com/kernel-patches/bpf/actions/runs/14458537639 * https://github.com/kernel-patches/bpf/actions/runs/14457178732 It happens because disconnect has been disabled for TLS [1], and it renders the test case invalid. Removing all the test code creates a conflict between bpf and bpf-next, so for now only remove the offending assert [2]. The test will be removed later on bpf-next. [1] https://lore.kernel.org/netdev/20250404180334.3224206-1-kuba@kernel.org/ [2] https://lore.kernel.org/bpf/cfc371285323e1a3f3b006bfcf74e6cf7ad65258@linux.… Signed-off-by: Ihor Solodrai <ihor.solodrai(a)linux.dev> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Reviewed-by: Jiayuan Chen <jiayuan.chen(a)linux.dev> Link: https://lore.kernel.org/bpf/20250416170246.2438524-1-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c b/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c index 2d0796314862a..0a99fd404f6dc 100644 --- a/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c +++ b/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c @@ -68,7 +68,6 @@ static void test_sockmap_ktls_disconnect_after_delete(int family, int map) goto close_cli; err = disconnect(cli); - ASSERT_OK(err, "disconnect"); close_cli: close(cli); -- 2.39.5

2 months

1
0
0 0

[PATCH AUTOSEL 6.14 34/39] selftests/bpf: Mitigate sockmap_ktls disconnect_after_delete failure

by Sasha Levin

From: Ihor Solodrai <ihor.solodrai(a)linux.dev> [ Upstream commit f2858f308131a09e33afb766cd70119b5b900569 ] "sockmap_ktls disconnect_after_delete" test has been failing on BPF CI after recent merges from netdev: * https://github.com/kernel-patches/bpf/actions/runs/14458537639 * https://github.com/kernel-patches/bpf/actions/runs/14457178732 It happens because disconnect has been disabled for TLS [1], and it renders the test case invalid. Removing all the test code creates a conflict between bpf and bpf-next, so for now only remove the offending assert [2]. The test will be removed later on bpf-next. [1] https://lore.kernel.org/netdev/20250404180334.3224206-1-kuba@kernel.org/ [2] https://lore.kernel.org/bpf/cfc371285323e1a3f3b006bfcf74e6cf7ad65258@linux.… Signed-off-by: Ihor Solodrai <ihor.solodrai(a)linux.dev> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Reviewed-by: Jiayuan Chen <jiayuan.chen(a)linux.dev> Link: https://lore.kernel.org/bpf/20250416170246.2438524-1-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c b/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c index 2d0796314862a..0a99fd404f6dc 100644 --- a/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c +++ b/tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c @@ -68,7 +68,6 @@ static void test_sockmap_ktls_disconnect_after_delete(int family, int map) goto close_cli; err = disconnect(cli); - ASSERT_OK(err, "disconnect"); close_cli: close(cli); -- 2.39.5

2 months

1
0
0 0

[PATCH net 0/4] Fix Felix DSA taprio gates after clock jump

by Vladimir Oltean

Richie Pearn presented a reproducible situation where traffic would get blocked on the NXP LS1028A switch if a certain taprio schedule was applied, and stepping the PTP clock would take place. The latter event is an expected initial occurrence, but also at runtime, for example when transitioning from one grandmaster to another. The issue is completely described in patch 1/4, which also contains the fix, but it has left me with some doubts regarding the need for vsc9959_tas_clock_adjust() in general. In order to prove to myself that vsc9959_tas_clock_adjust() is needed in general, I have written a selftest for the tc-taprio data path in patch 4/4. On the LS1028A, we can clearly see the following failures without that function: INFO: Forcing a backward clock jump TEST: ping [FAIL] INFO: Setting up taprio after PTP TEST: In band with gate [FAIL] Reception of 100 packets failed TEST: Out of band with gate [FAIL] Reception of 100 packets failed As for testing my fix from patch 1/4, that was quite a bit more complex to do automatically. In fact, I couldn't find any other schedule that would fail to be updated by vsc9959_tas_clock_adjust() as cleanly as the schedule from Richie, so I've added that specific schedule as the test_clock_jump_backward() test. The test ordering is also (unfortunately) very strategic. Running the selftest to the end dirties the GCL RAM, and when running test_clock_jump_backward() once again, the GCL entries won't be all zeroes as they were the first time around. They will contain bits and pieces of old schedules, making it very challenging to make it fail. Thus, test_clock_jump_backward() is the first in the test suite, and without patch 1/4, it is only supposed to fail the _first_ time when running after a clean boot. Vladimir Oltean (4): net: dsa: felix: fix broken taprio gate states after clock jump selftests: net: tsn_lib: create common helper for counting received packets selftests: net: tsn_lib: add window_size argument to isochron_do() selftests: net: tc_taprio: new test drivers/net/dsa/ocelot/felix_vsc9959.c | 5 +- .../selftests/drivers/net/dsa/tc_taprio.sh | 1 + .../selftests/drivers/net/ocelot/psfp.sh | 8 +- .../selftests/net/forwarding/tc_taprio.sh | 421 ++++++++++++++++++ .../selftests/net/forwarding/tsn_lib.sh | 26 ++ 5 files changed, 454 insertions(+), 7 deletions(-) create mode 120000 tools/testing/selftests/drivers/net/dsa/tc_taprio.sh create mode 100755 tools/testing/selftests/net/forwarding/tc_taprio.sh -- 2.43.0

2 months

2
5
0 0

[PATCH bpf-next] selftests/bpf: Fix compilation errors

by Feng Yang

From: Feng Yang <yangfeng(a)kylinos.cn> If the CONFIG_NET_SCH_BPF configuration is not enabled, the BPF test compilation will report the following error: In file included from progs/bpf_qdisc_fq.c:39: progs/bpf_qdisc_common.h:17:51: error: declaration of 'struct bpf_sk_buff_ptr' will not be visible outside of this function [-Werror,-Wvisibility] 17 | void bpf_qdisc_skb_drop(struct sk_buff *p, struct bpf_sk_buff_ptr *to_free) __ksym; | ^ progs/bpf_qdisc_fq.c:309:14: error: declaration of 'struct bpf_sk_buff_ptr' will not be visible outside of this function [-Werror,-Wvisibility] 309 | struct bpf_sk_buff_ptr *to_free) | ^ progs/bpf_qdisc_fq.c:309:14: error: declaration of 'struct bpf_sk_buff_ptr' will not be visible outside of this function [-Werror,-Wvisibility] progs/bpf_qdisc_fq.c:308:5: error: conflicting types for '____bpf_fq_enqueue' Fixes: 11c701639ba9 ("selftests/bpf: Add a basic fifo qdisc test") Signed-off-by: Feng Yang <yangfeng(a)kylinos.cn> --- tools/testing/selftests/bpf/progs/bpf_qdisc_common.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/testing/selftests/bpf/progs/bpf_qdisc_common.h b/tools/testing/selftests/bpf/progs/bpf_qdisc_common.h index 65a2c561c0bb..7e7f2fe04f22 100644 --- a/tools/testing/selftests/bpf/progs/bpf_qdisc_common.h +++ b/tools/testing/selftests/bpf/progs/bpf_qdisc_common.h @@ -12,6 +12,8 @@ #define private(name) SEC(".data." #name) __hidden __attribute__((aligned(8))) +struct bpf_sk_buff_ptr; + u32 bpf_skb_get_hash(struct sk_buff *p) __ksym; void bpf_kfree_skb(struct sk_buff *p) __ksym; void bpf_qdisc_skb_drop(struct sk_buff *p, struct bpf_sk_buff_ptr *to_free) __ksym; -- 2.43.0

2 months

2
1
0 0

[PATCH] selftests/bpf: Fix kmem_cache iterator draining

by T.J. Mercier

The closing parentheses around the read syscall is misplaced, causing single byte reads from the iterator instead of buf sized reads. While the end result is the same, many more read calls than necessary are performed. $ tools/testing/selftests/bpf/vmtest.sh "./test_progs -t kmem_cache_iter" 145/1 kmem_cache_iter/check_task_struct:OK 145/2 kmem_cache_iter/check_slabinfo:OK 145/3 kmem_cache_iter/open_coded_iter:OK 145 kmem_cache_iter:OK Summary: 1/3 PASSED, 0 SKIPPED, 0 FAILED Fixes: a496d0cdc84d ("selftests/bpf: Add a test for kmem_cache_iter") Signed-off-by: T.J. Mercier <tjmercier(a)google.com> --- tools/testing/selftests/bpf/prog_tests/kmem_cache_iter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/bpf/prog_tests/kmem_cache_iter.c b/tools/testing/selftests/bpf/prog_tests/kmem_cache_iter.c index 8e13a3416a21..1de14b111931 100644 --- a/tools/testing/selftests/bpf/prog_tests/kmem_cache_iter.c +++ b/tools/testing/selftests/bpf/prog_tests/kmem_cache_iter.c @@ -104,7 +104,7 @@ void test_kmem_cache_iter(void) goto destroy; memset(buf, 0, sizeof(buf)); - while (read(iter_fd, buf, sizeof(buf) > 0)) { + while (read(iter_fd, buf, sizeof(buf)) > 0) { /* Read out all contents */ printf("%s", buf); } base-commit: b4432656b36e5cc1d50a1f2dc15357543add530e -- 2.49.0.906.g1f30a19c02-goog

2 months

4
4
0 0

[PATCH net-next] selftests: net: exit cleanly on SIGTERM / timeout

by Jakub Kicinski

ksft runner sends 2 SIGTERMs in a row if a test runs out of time. Handle this in a similar way we handle SIGINT - cleanup and stop running further tests. Because we get 2 signals we need a bit of logic to ignore the subsequent one, they come immediately one after the other (due to commit 9616cb34b08e ("kselftest/runner.sh: Propagate SIGTERM to runner child")). This change makes sure we run cleanup (scheduled defer()s) and also print a stack trace on SIGTERM, which doesn't happen by default. Tests occasionally hang in NIPA and it's impossible to tell what they are waiting from or doing. Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> --- CC: petrm(a)nvidia.com CC: willemb(a)google.com CC: sdf(a)fomichev.me CC: linux-kselftest(a)vger.kernel.org --- tools/testing/selftests/net/lib/py/ksft.py | 27 +++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/net/lib/py/ksft.py b/tools/testing/selftests/net/lib/py/ksft.py index 3cfad0fd4570..73710634d457 100644 --- a/tools/testing/selftests/net/lib/py/ksft.py +++ b/tools/testing/selftests/net/lib/py/ksft.py @@ -3,6 +3,7 @@ import builtins import functools import inspect +import signal import sys import time import traceback @@ -26,6 +27,10 @@ KSFT_DISRUPTIVE = True pass +class KsftTerminate(KeyboardInterrupt): + pass + + def ksft_pr(*objs, **kwargs): print("#", *objs, **kwargs) @@ -193,6 +198,19 @@ KSFT_DISRUPTIVE = True return env +term_cnt = 0 + +def _ksft_intr(signum, frame): + # ksft runner.sh sends 2 SIGTERMs in a row on a timeout + # if we don't ignore the second one it will stop us from handling cleanup + global term_cnt + term_cnt += 1 + if term_cnt == 1: + raise KsftTerminate() + else: + ksft_pr(f"Ignoring SIGTERM (cnt: {term_cnt}), already exiting...") + + def ksft_run(cases=None, globs=None, case_pfx=None, args=()): cases = cases or [] @@ -205,6 +223,10 @@ KSFT_DISRUPTIVE = True cases.append(value) break + global term_cnt + term_cnt = 0 + prev_sigterm = signal.signal(signal.SIGTERM, _ksft_intr) + totals = {"pass": 0, "fail": 0, "skip": 0, "xfail": 0} print("TAP version 13") @@ -229,11 +251,12 @@ KSFT_DISRUPTIVE = True cnt_key = 'xfail' except BaseException as e: stop |= isinstance(e, KeyboardInterrupt) + stop |= isinstance(e, KsftTerminate) tb = traceback.format_exc() for line in tb.strip().split('\n'): ksft_pr("Exception|", line) if stop: - ksft_pr("Stopping tests due to KeyboardInterrupt.") + ksft_pr(f"Stopping tests due to {type(e).__name__}.") KSFT_RESULT = False cnt_key = 'fail' @@ -248,6 +271,8 @@ KSFT_DISRUPTIVE = True if stop: break + signal.signal(signal.SIGTERM, prev_sigterm) + print( f"# Totals: pass:{totals['pass']} fail:{totals['fail']} xfail:{totals['xfail']} xpass:0 skip:{totals['skip']} error:0" ) -- 2.49.0

2 months

3
5
0 0

[PATCH v2 0/6] Add support for FEAT_{LS64, LS64_V} and related tests

by Yicong Yang

From: Yicong Yang <yangyicong(a)hisilicon.com> Armv8.7 introduces single-copy atomic 64-byte loads and stores instructions and its variants named under FEAT_{LS64, LS64_V}. Add support for Armv8.7 FEAT_{LS64, LS64_V}: - Add identifying and enabling in the cpufeature list - Expose the support of these features to userspace through HWCAP3 and cpuinfo - Add related hwcap test - Handle the trap of unsupported memory (normal/uncacheable) access in a VM A real scenario for this feature is that the userspace driver can make use of this to implement direct WQE (workqueue entry) - a mechanism to fill WQE directly into the hardware. This patchset also complement with Marc's patchset v2[1] for handling LS64* trapped if not advertised for a VM. [1] https://lore.kernel.org/linux-arm-kernel/20250310122505.2857610-1-maz@kerne… Tested with updated hwcap test: On host: root@localhost:/tmp# dmesg | grep "All CPU(s) started" [ 0.504846] CPU: All CPU(s) started at EL2 root@localhost:/tmp# ./hwcap [...] # LS64 present ok 217 cpuinfo_match_LS64 ok 218 sigill_LS64 ok 219 # SKIP sigbus_LS64 # LS64_V present ok 220 cpuinfo_match_LS64_V ok 221 sigill_LS64_V ok 222 # SKIP sigbus_LS64_V # 115 skipped test(s) detected. Consider enabling relevant config options to improve coverage. # Totals: pass:107 fail:0 xfail:0 xpass:0 skip:115 error:0 On guest: root@localhost:/# dmesg | grep "All CPU(s) started" [ 0.205580] CPU: All CPU(s) started at EL1 root@localhost:/mnt# ./hwcap [...] # LS64 present ok 217 cpuinfo_match_LS64 ok 218 sigill_LS64 ok 219 # SKIP sigbus_LS64 # LS64_V present ok 220 cpuinfo_match_LS64_V ok 221 sigill_LS64_V ok 222 # SKIP sigbus_LS64_V # 115 skipped test(s) detected. Consider enabling relevant config options to improve coverage. # Totals: pass:107 fail:0 xfail:0 xpass:0 skip:115 error:0 Change since v1: - Drop the suppport for LS64_ACCDATA - handle the DABT of unsupported memory type after checking the memory attributes Link: https://lore.kernel.org/linux-arm-kernel/20241202135504.14252-1-yangyicong@… Yicong Yang (6): arm64: Provide basic EL2 setup for FEAT_{LS64, LS64_V} usage at EL0/1 arm64: Add support for FEAT_{LS64, LS64_V} KVM: arm64: Enable FEAT_{LS64, LS64_V} in the supported guest kselftest/arm64: Add HWCAP test for FEAT_{LS64, LS64_V} arm64: Add ESR.DFSC definition of unsupported exclusive or atomic access KVM: arm64: Handle DABT caused by LS64* instructions on unsupported memory Documentation/arch/arm64/booting.rst | 12 +++ Documentation/arch/arm64/elf_hwcaps.rst | 6 ++ arch/arm64/include/asm/el2_setup.h | 12 ++- arch/arm64/include/asm/esr.h | 8 ++ arch/arm64/include/asm/hwcap.h | 2 + arch/arm64/include/asm/kvm_emulate.h | 7 ++ arch/arm64/include/uapi/asm/hwcap.h | 2 + arch/arm64/kernel/cpufeature.c | 51 +++++++++++++ arch/arm64/kernel/cpuinfo.c | 2 + arch/arm64/kvm/inject_fault.c | 35 +++++++++ arch/arm64/kvm/mmu.c | 37 +++++++++- arch/arm64/tools/cpucaps | 2 + tools/testing/selftests/arm64/abi/hwcap.c | 90 +++++++++++++++++++++++ 13 files changed, 264 insertions(+), 2 deletions(-) -- 2.24.0

2 months

4
16
0 0

[PATCH 0/3] RISC-V KVM selftests improvements

by Atish Patra

This series improves the following tests. 1. Get-reg-list : Adds vector support 2. SBI PMU test : Distinguish between different types of illegal exception The first patch is just helper patch that adds stval support during exception handling. Signed-off-by: Atish Patra <atishp(a)rivosinc.com> --- Atish Patra (3): KVM: riscv: selftests: Add stval to exception handling KVM: riscv: selftests: Decode stval to identify exact exception type KVM: riscv: selftests: Add vector extension tests .../selftests/kvm/include/riscv/processor.h | 1 + tools/testing/selftests/kvm/lib/riscv/handlers.S | 2 + tools/testing/selftests/kvm/riscv/get-reg-list.c | 111 ++++++++++++++++++++- tools/testing/selftests/kvm/riscv/sbi_pmu_test.c | 32 ++++++ 4 files changed, 145 insertions(+), 1 deletion(-) --- base-commit: b3f263a98d30fe2e33eefea297598c590ee3560e change-id: 20250324-kvm_selftest_improve-9bedb9f0a6d3 -- Regards, Atish patra

2 months

4
14
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror