November 2025 - Linux-kselftest-mirror

[PATCH net-next 0/6] selftests: drv-net: Fix issues in devlink_rate_tc_bw.py

by Carolina Jubran

Hi, This series fixes issues in the devlink_rate_tc_bw.py selftest and introduces a new Iperf3Runner that helps with measurement handling. Thanks, Carolina Carolina Jubran (6): selftests: drv-net: Add devlink_rate_tc_bw.py to TEST_PROGS selftests: drv-net: introduce Iperf3Runner for measurement use cases selftests: drv-net: Use Iperf3Runner in devlink_rate_tc_bw.py selftests: drv-net: Set shell=True for sysfs writes in devlink_rate_tc_bw.py selftests: drv-net: Fix and clarify TC bandwidth split in devlink_rate_tc_bw.py selftests: drv-net: Fix tolerance calculation in devlink_rate_tc_bw.py .../testing/selftests/drivers/net/hw/Makefile | 1 + .../drivers/net/hw/devlink_rate_tc_bw.py | 174 ++++++++---------- .../drivers/net/hw/lib/py/__init__.py | 5 +- .../selftests/drivers/net/lib/py/__init__.py | 5 +- .../selftests/drivers/net/lib/py/load.py | 84 ++++++++- 5 files changed, 157 insertions(+), 112 deletions(-) -- 2.38.1

1 week, 4 days

2
7
0 0

[PATCH net-next v3 00/12] selftests: drv-net: convert GRO and Toeplitz tests to work for drivers in NIPA

by Jakub Kicinski

Main objective of this series is to convert the gro.sh and toeplitz.sh tests to be "NIPA-compatible" - meaning make use of the Python env, which lets us run the tests against either netdevsim or a real device. The tests seem to have been written with a different flow in mind. Namely they source different bash "setup" scripts depending on arguments passed to the test. While I have nothing against the use of bash and the overall architecture - the existing code needs quite a bit of work (don't assume MAC/IP addresses, support remote endpoint over SSH). If I'm the one fixing it, I'd rather convert them to our "simplistic" Python. This series rewrites the tests in Python while addressing their shortcomings. The functionality of running the test over loopback on a real device is retained but with a different method of invocation (see the last patch). Once again we are dealing with a script which run over a variety of protocols (combination of [ipv4, ipv6, ipip] x [tcp, udp]). The first 4 patches add support for test variants to our scripts. We use the term "variant" in the same sense as the C kselftest_harness.h - variant is just a set of static input arguments. Note that neither GRO nor the Toeplitz test fully passes for me on any HW I have access to. But this is unrelated to the conversion. This series is not making any real functional changes to the tests, it is limited to improving the "test harness" scripts. v3: [patch 1] Exception -> BaseException [patch 3] use named tuple instead of attaching attrs directly to a func [patch 9] restore the comment about retries in GRO test [patch 10] use open() instead of echo [patch 10] move MTU changes to _setup() to handle all the config related stuff in that function v2: https://lore.kernel.org/20251118215126.2225826-1-kuba@kernel.org [patch 5] fix accidental modification of gitignore [patch 8] fix typo in "compared" [patch 9] fix typo I -> It [patch 10] fix typoe configure -> configured v1: https://lore.kernel.org/20251117205810.1617533-1-kuba@kernel.org Jakub Kicinski (12): selftests: net: py: coding style improvements selftests: net: py: extract the case generation logic selftests: net: py: add test variants selftests: drv-net: xdp: use variants for qstat tests selftests: net: relocate gro and toeplitz tests to drivers/net selftests: net: py: support ksft ready without wait selftests: net: py: read ip link info about remote dev netdevsim: pass packets thru GRO on Rx selftests: drv-net: add a Python version of the GRO test selftests: drv-net: hw: convert the Toeplitz test to Python netdevsim: add loopback support selftests: net: remove old setup_* scripts tools/testing/selftests/drivers/net/Makefile | 2 + .../testing/selftests/drivers/net/hw/Makefile | 6 +- tools/testing/selftests/net/Makefile | 7 - tools/testing/selftests/net/lib/Makefile | 1 + drivers/net/netdevsim/netdev.c | 26 ++- .../testing/selftests/{ => drivers}/net/gro.c | 5 +- .../{net => drivers/net/hw}/toeplitz.c | 7 +- .../testing/selftests/drivers/net/.gitignore | 1 + tools/testing/selftests/drivers/net/gro.py | 164 ++++++++++++++ .../selftests/drivers/net/hw/.gitignore | 1 + .../drivers/net/hw/lib/py/__init__.py | 4 +- .../selftests/drivers/net/hw/toeplitz.py | 209 ++++++++++++++++++ .../selftests/drivers/net/lib/py/__init__.py | 4 +- .../selftests/drivers/net/lib/py/env.py | 2 + tools/testing/selftests/drivers/net/xdp.py | 42 ++-- tools/testing/selftests/net/.gitignore | 2 - tools/testing/selftests/net/gro.sh | 105 --------- .../selftests/net/lib/ksft_setup_loopback.sh | 111 ++++++++++ .../testing/selftests/net/lib/py/__init__.py | 5 +- tools/testing/selftests/net/lib/py/ksft.py | 91 ++++++-- tools/testing/selftests/net/lib/py/nsim.py | 2 +- tools/testing/selftests/net/lib/py/utils.py | 20 +- tools/testing/selftests/net/setup_loopback.sh | 120 ---------- tools/testing/selftests/net/setup_veth.sh | 45 ---- tools/testing/selftests/net/toeplitz.sh | 199 ----------------- .../testing/selftests/net/toeplitz_client.sh | 28 --- 26 files changed, 632 insertions(+), 577 deletions(-) rename tools/testing/selftests/{ => drivers}/net/gro.c (99%) rename tools/testing/selftests/{net => drivers/net/hw}/toeplitz.c (99%) create mode 100755 tools/testing/selftests/drivers/net/gro.py create mode 100755 tools/testing/selftests/drivers/net/hw/toeplitz.py delete mode 100755 tools/testing/selftests/net/gro.sh create mode 100755 tools/testing/selftests/net/lib/ksft_setup_loopback.sh delete mode 100644 tools/testing/selftests/net/setup_loopback.sh delete mode 100644 tools/testing/selftests/net/setup_veth.sh delete mode 100755 tools/testing/selftests/net/toeplitz.sh delete mode 100755 tools/testing/selftests/net/toeplitz_client.sh -- 2.51.1

1 week, 4 days

4
16
0 0

[PATCH 0/3] HID: multitouch: set INPUT_PROP_PRESSUREPAD on compatible touchpads

by Peter Hutterer

Note: this requires INPUT_PROP_PRESSUREPAD [1] which is not yet available in Linus' tree but it is in Dmitry's for-linus tree. Nicely enough MS defines a button type for a pressurepad touchpad [2] and it looks like most touchpad vendors fill this in. The selftests require a bit of prep work (and a hack for the test itself) - hidtools 0.12 requires python-libevdev 0.13 which in turn provides constructors for unknown properties. [1] https://lore.kernel.org/linux-input/20251030011735.GA969565@quokka/T/#m9d9b… [2] https://learn.microsoft.com/en-us/windows-hardware/design/component-guideli… Signed-off-by: Peter Hutterer <peter.hutterer(a)who-t.net> --- Peter Hutterer (3): selftests/hid: require hidtools 0.12 selftests/hid: use a enum class for the different button types HID: multitouch: set INPUT_PROP_PRESSUREPAD based on Digitizer/Button Type drivers/hid/hid-multitouch.c | 12 ++++- tools/testing/selftests/hid/tests/conftest.py | 14 +++++ .../testing/selftests/hid/tests/test_multitouch.py | 61 +++++++++++++++++----- 3 files changed, 73 insertions(+), 14 deletions(-) --- base-commit: 2bc4c50a42f8b83f611d0475598dc72740e87640 change-id: 20251111-wip-hid-pressurepad-8a800cdf1813 Best regards, -- Peter Hutterer <peter.hutterer(a)who-t.net>

1 week, 4 days

1
3
0 0

[PATCH v1] selftests: hid: tests: test_wacom_generic: add base test for display devices and opaque devices

by Alex Tran

Verify Wacom devices set INPUT_PROP_DIRECT appropriately on display devices and INPUT_PROP_POINTER appropriately on opaque devices. Tests are defined in the base class and disabled for inapplicable device types. Signed-off-by: Alex Tran <alex.t.tran(a)gmail.com> --- .../selftests/hid/tests/test_wacom_generic.py | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/hid/tests/test_wacom_generic.py b/tools/testing/selftests/hid/tests/test_wacom_generic.py index 2d6d04f0f..aa2a175f2 100644 --- a/tools/testing/selftests/hid/tests/test_wacom_generic.py +++ b/tools/testing/selftests/hid/tests/test_wacom_generic.py @@ -600,15 +600,17 @@ class BaseTest: def test_prop_direct(self): """ - Todo: Verify that INPUT_PROP_DIRECT is set on display devices. + Verify that INPUT_PROP_DIRECT is set on display devices. """ - pass + evdev = self.uhdev.get_evdev() + assert libevdev.INPUT_PROP_DIRECT in evdev.properties def test_prop_pointer(self): """ - Todo: Verify that INPUT_PROP_POINTER is set on opaque devices. + Verify that INPUT_PROP_POINTER is set on opaque devices. """ - pass + evdev = self.uhdev.get_evdev() + assert libevdev.INPUT_PROP_POINTER in evdev.properties class PenTabletTest(BaseTest.TestTablet): @@ -622,6 +624,8 @@ class TouchTabletTest(BaseTest.TestTablet): class TestOpaqueTablet(PenTabletTest): + test_prop_direct = None + def create_device(self): return OpaqueTablet() @@ -864,6 +868,7 @@ class TestPTHX60_Pen(TestOpaqueCTLTablet): class TestDTH2452Tablet(test_multitouch.BaseTest.TestMultitouch, TouchTabletTest): ContactIds = namedtuple("ContactIds", "contact_id, tracking_id, slot_num") + test_prop_pointer = None def create_device(self): return test_multitouch.Digitizer( -- 2.51.0

1 week, 4 days

2
3
0 0

[PATCH net-next v10 00/11] vsock: add namespace support to vhost-vsock and loopback

by Bobby Eshleman

This series adds namespace support to vhost-vsock and loopback. It does not add namespaces to any of the other guest transports (virtio-vsock, hyperv, or vmci). The current revision supports two modes: local and global. Local mode is complete isolation of namespaces, while global mode is complete sharing between namespaces of CIDs (the original behavior). The mode is set using /proc/sys/net/vsock/ns_mode. Modes are per-netns and write-once. This allows a system to configure namespaces independently (some may share CIDs, others are completely isolated). This also supports future possible mixed use cases, where there may be namespaces in global mode spinning up VMs while there are mixed mode namespaces that provide services to the VMs, but are not allowed to allocate from the global CID pool (this mode is not implemented in this series). If a socket or VM is created when a namespace is global but the namespace changes to local, the socket or VM will continue working normally. That is, the socket or VM assumes the mode behavior of the namespace at the time the socket/VM was created. The original mode is captured in vsock_create() and so occurs at the time of socket(2) and accept(2) for sockets and open(2) on /dev/vhost-vsock for VMs. This prevents a socket/VM connection from suddenly breaking due to a namespace mode change. Any new sockets/VMs created after the mode change will adopt the new mode's behavior. Additionally, added tests for the new namespace features: tools/testing/selftests/vsock/vmtest.sh 1..29 ok 1 vm_server_host_client ok 2 vm_client_host_server ok 3 vm_loopback ok 4 ns_guest_local_mode_rejected ok 5 ns_host_vsock_ns_mode_ok ok 6 ns_host_vsock_ns_mode_write_once_ok ok 7 ns_global_same_cid_fails ok 8 ns_local_same_cid_ok ok 9 ns_global_local_same_cid_ok ok 10 ns_local_global_same_cid_ok ok 11 ns_diff_global_host_connect_to_global_vm_ok ok 12 ns_diff_global_host_connect_to_local_vm_fails ok 13 ns_diff_global_vm_connect_to_global_host_ok ok 14 ns_diff_global_vm_connect_to_local_host_fails ok 15 ns_diff_local_host_connect_to_local_vm_fails ok 16 ns_diff_local_vm_connect_to_local_host_fails ok 17 ns_diff_global_to_local_loopback_local_fails ok 18 ns_diff_local_to_global_loopback_fails ok 19 ns_diff_local_to_local_loopback_fails ok 20 ns_diff_global_to_global_loopback_ok ok 21 ns_same_local_loopback_ok ok 22 ns_same_local_host_connect_to_local_vm_ok ok 23 ns_same_local_vm_connect_to_local_host_ok ok 24 ns_mode_change_connection_continue_vm_ok ok 25 ns_mode_change_connection_continue_host_ok ok 26 ns_mode_change_connection_continue_both_ok ok 27 ns_delete_vm_ok ok 28 ns_delete_host_ok ok 29 ns_delete_both_ok SUMMARY: PASS=29 SKIP=0 FAIL=0 Dependent on series: https://lore.kernel.org/all/20251108-vsock-selftests-fixes-and-improvements… Thanks again for everyone's help and reviews! Suggested-by: Sargun Dhillon <sargun(a)sargun.me> Signed-off-by: Bobby Eshleman <bobbyeshleman(a)gmail.com> To: Stefano Garzarella <sgarzare(a)redhat.com> To: Shuah Khan <shuah(a)kernel.org> To: David S. Miller <davem(a)davemloft.net> To: Eric Dumazet <edumazet(a)google.com> To: Jakub Kicinski <kuba(a)kernel.org> To: Paolo Abeni <pabeni(a)redhat.com> To: Simon Horman <horms(a)kernel.org> To: Stefan Hajnoczi <stefanha(a)redhat.com> To: Michael S. Tsirkin <mst(a)redhat.com> To: Jason Wang <jasowang(a)redhat.com> To: Xuan Zhuo <xuanzhuo(a)linux.alibaba.com> To: Eugenio Pérez <eperezma(a)redhat.com> To: K. Y. Srinivasan <kys(a)microsoft.com> To: Haiyang Zhang <haiyangz(a)microsoft.com> To: Wei Liu <wei.liu(a)kernel.org> To: Dexuan Cui <decui(a)microsoft.com> To: Bryan Tan <bryan-bt.tan(a)broadcom.com> To: Vishnu Dasa <vishnu.dasa(a)broadcom.com> To: Broadcom internal kernel review list <bcm-kernel-feedback-list(a)broadcom.com> Cc: virtualization(a)lists.linux.dev Cc: netdev(a)vger.kernel.org Cc: linux-kselftest(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: kvm(a)vger.kernel.org Cc: linux-hyperv(a)vger.kernel.org Cc: berrange(a)redhat.com Cc: Sargun Dhillon <sargun(a)sargun.me> Changes in v10: - Combine virtio common patches into one (Stefano) - Resolve vsock_loopback virtio_transport_reset_no_sock() issue with info->vsk setting. This eliminates the need for skb->cb, so remove skb->cb patches. - many line width 80 fixes - Link to v9: https://lore.kernel.org/all/20251111-vsock-vmtest-v9-0-852787a37bed@meta.com Changes in v9: - reorder loopback patch after patch for virtio transport common code - remove module ordering tests patch because loopback no longer depends on pernet ops - major simplifications in vsock_loopback - added a new patch for blocking local mode for guests, added test case to check - add net ref tracking to vsock_loopback patch - Link to v8: https://lore.kernel.org/r/20251023-vsock-vmtest-v8-0-dea984d02bb0@meta.com Changes in v8: - Break generic cleanup/refactoring patches into standalone series, remove those from this series - Link to dependency: https://lore.kernel.org/all/20251022-vsock-selftests-fixes-and-improvements… - Link to v7: https://lore.kernel.org/r/20251021-vsock-vmtest-v7-0-0661b7b6f081@meta.com Changes in v7: - fix hv_sock build - break out vmtest patches into distinct, more well-scoped patches - change `orig_net_mode` to `net_mode` - many fixes and style changes in per-patch change sets (see individual patches for specific changes) - optimize `virtio_vsock_skb_cb` layout - update commit messages with more useful descriptions - vsock_loopback: use orig_net_mode instead of current net mode - add tests for edge cases (ns deletion, mode changing, loopback module load ordering) - Link to v6: https://lore.kernel.org/r/20250916-vsock-vmtest-v6-0-064d2eb0c89d@meta.com Changes in v6: - define behavior when mode changes to local while socket/VM is alive - af_vsock: clarify description of CID behavior - af_vsock: use stronger langauge around CID rules (dont use "may") - af_vsock: improve naming of buf/buffer - af_vsock: improve string length checking on proc writes - vsock_loopback: add space in struct to clarify lock protection - vsock_loopback: do proper cleanup/unregister on vsock_loopback_exit() - vsock_loopback: use virtio_vsock_skb_net() instead of sock_net() - vsock_loopback: set loopback to NULL after kfree() - vsock_loopback: use pernet_operations and remove callback mechanism - vsock_loopback: add macros for "global" and "local" - vsock_loopback: fix length checking - vmtest.sh: check for namespace support in vmtest.sh - Link to v5: https://lore.kernel.org/r/20250827-vsock-vmtest-v5-0-0ba580bede5b@meta.com Changes in v5: - /proc/net/vsock_ns_mode -> /proc/sys/net/vsock/ns_mode - vsock_global_net -> vsock_global_dummy_net - fix netns lookup in vhost_vsock to respect pid namespaces - add callbacks for vsock_loopback to avoid circular dependency - vmtest.sh loads vsock_loopback module - remove vsock_net_mode_can_set() - change vsock_net_write_mode() to return true/false based on success - make vsock_net_mode enum instead of u8 - Link to v4: https://lore.kernel.org/r/20250805-vsock-vmtest-v4-0-059ec51ab111@meta.com Changes in v4: - removed RFC tag - implemented loopback support - renamed new tests to better reflect behavior - completed suite of tests with permutations of ns modes and vsock_test as guest/host - simplified socat bridging with unix socket instead of tcp + veth - only use vsock_test for success case, socat for failure case (context in commit message) - lots of cleanup Changes in v3: - add notion of "modes" - add procfs /proc/net/vsock_ns_mode - local and global modes only - no /dev/vhost-vsock-netns - vmtest.sh already merged, so new patch just adds new tests for NS - Link to v2: https://lore.kernel.org/kvm/20250312-vsock-netns-v2-0-84bffa1aa97a@gmail.com Changes in v2: - only support vhost-vsock namespaces - all g2h namespaces retain old behavior, only common API changes impacted by vhost-vsock changes - add /dev/vhost-vsock-netns for "opt-in" - leave /dev/vhost-vsock to old behavior - removed netns module param - Link to v1: https://lore.kernel.org/r/20200116172428.311437-1-sgarzare@redhat.com Changes in v1: - added 'netns' module param to vsock.ko to enable the network namespace support (disabled by default) - added 'vsock_net_eq()' to check the "net" assigned to a socket only when 'netns' support is enabled - Link to RFC: https://patchwork.ozlabs.org/cover/1202235/ --- Bobby Eshleman (11): vsock: a per-net vsock NS mode state vsock: add netns to vsock core vsock: reject bad VSOCK_NET_MODE_LOCAL configuration for G2H vsock: add netns support to virtio transports virtio: set skb owner of virtio_transport_reset_no_sock() reply selftests/vsock: add namespace helpers to vmtest.sh selftests/vsock: prepare vm management helpers for namespaces selftests/vsock: add tests for proc sys vsock ns_mode selftests/vsock: add namespace tests for CID collisions selftests/vsock: add tests for host <-> vm connectivity with namespaces selftests/vsock: add tests for namespace deletion and mode changes MAINTAINERS | 1 + drivers/vhost/vsock.c | 57 +- include/linux/virtio_vsock.h | 8 +- include/net/af_vsock.h | 58 +- include/net/net_namespace.h | 4 + include/net/netns/vsock.h | 17 + net/vmw_vsock/af_vsock.c | 294 ++++++++- net/vmw_vsock/hyperv_transport.c | 6 + net/vmw_vsock/virtio_transport.c | 29 +- net/vmw_vsock/virtio_transport_common.c | 69 +- net/vmw_vsock/vmci_transport.c | 7 + net/vmw_vsock/vsock_loopback.c | 20 +- tools/testing/selftests/vsock/vmtest.sh | 1037 +++++++++++++++++++++++++++++-- 13 files changed, 1514 insertions(+), 93 deletions(-) --- base-commit: 962ac5ca99a5c3e7469215bf47572440402dfd59 change-id: 20250325-vsock-vmtest-b3a21d2102c2 prerequisite-message-id: <20251022-vsock-selftests-fixes-and-improvements-v1-0-edeb179d6463(a)meta.com> prerequisite-patch-id: a2eecc3851f2509ed40009a7cab6990c6d7cfff5 prerequisite-patch-id: 501db2100636b9c8fcb3b64b8b1df797ccbede85 prerequisite-patch-id: ba1a2f07398a035bc48ef72edda41888614be449 prerequisite-patch-id: fd5cc5445aca9355ce678e6d2bfa89fab8a57e61 prerequisite-patch-id: 795ab4432ffb0843e22b580374782e7e0d99b909 prerequisite-patch-id: 1499d263dc933e75366c09e045d2125ca39f7ddd prerequisite-patch-id: f92d99bb1d35d99b063f818a19dcda999152d74c prerequisite-patch-id: e3296f38cdba6d903e061cff2bbb3e7615e8e671 prerequisite-patch-id: bc4662b4710d302d4893f58708820fc2a0624325 prerequisite-patch-id: f8991f2e98c2661a706183fde6b35e2b8d9aedcf prerequisite-patch-id: 44bf9ed69353586d284e5ee63d6fffa30439a698 prerequisite-patch-id: d50621bc630eeaf608bbaf260370c8dabf6326df Best regards, -- Bobby Eshleman <bobbyeshleman(a)meta.com>

1 week, 4 days

2
24
0 0

[PATCH RESEND v2 1/1] selftest/sched: skip the test if smt is not enabled

by Yifei Liu

The core scheduling is for smt enabled cpus. It is not returns failure and gives plenty of error messages and not clearly points to the smt issue if the smt is disabled. It just mention "not a core sched system" and many other messages. For example: Not a core sched system tid=210574, / tgid=210574 / pgid=210574: ffffffffffffffff Not a core sched system tid=210575, / tgid=210575 / pgid=210574: ffffffffffffffff Not a core sched system tid=210577, / tgid=210575 / pgid=210574: ffffffffffffffff (similar things many other times) In this patch, the test will first read /sys/devices/system/cpu/smt/active, if the file cannot be opened or its value is 0, the test is skipped with an explanatory message. This helps developers understand why it is skipped and avoids unnecessary attention when running the full selftest suite. Cc: stable(a)vger.kernel.org Signed-off-by: Yifei Liu <yifei.l.liu(a)oracle.com> --- tools/testing/selftests/sched/cs_prctl_test.c | 23 ++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/sched/cs_prctl_test.c b/tools/testing/selftests/sched/cs_prctl_test.c index 52d97fae4dbd..7ce8088cde6a 100644 --- a/tools/testing/selftests/sched/cs_prctl_test.c +++ b/tools/testing/selftests/sched/cs_prctl_test.c @@ -32,6 +32,8 @@ #include <stdlib.h> #include <string.h> +#include "../kselftest.h" + #if __GLIBC_PREREQ(2, 30) == 0 #include <sys/syscall.h> static pid_t gettid(void) @@ -109,6 +111,22 @@ static void handle_usage(int rc, char *msg) exit(rc); } +int check_smt(void) +{ + int c = 0; + FILE *file; + + file = fopen("/sys/devices/system/cpu/smt/active", "r"); + if (!file) + return 0; + c = fgetc(file) - 0x30; + fclose(file); + if (c == 0 || c == 1) + return c; + //if fgetc returns EOF or -1 for correupted files, return 0. + return 0; +} + static unsigned long get_cs_cookie(int pid) { unsigned long long cookie; @@ -271,7 +289,10 @@ int main(int argc, char *argv[]) delay = -1; srand(time(NULL)); - + if (!check_smt()) { + ksft_test_result_skip("smt not enabled\n"); + return 1; + } /* put into separate process group */ if (setpgid(0, 0) != 0) handle_error("process group"); -- 2.50.1

1 week, 4 days

1
0
0 0

Re: [PATCH] genpt: Make GENERIC_PT invisible

by Geert Uytterhoeven

Hi Jason, CC kunit On Thu, 20 Nov 2025 at 18:07, Jason Gunthorpe <jgg(a)ziepe.ca> wrote: > On Thu, Nov 20, 2025 at 12:49:33PM -0400, Jason Gunthorpe wrote: > > On Wed, Nov 12, 2025 at 03:08:05PM +0100, Geert Uytterhoeven wrote: > > > There is no point in asking the user about the Generic Radix Page > > > Table API: > > > - All IOMMU drivers that use this API already select GENERIC_PT when > > > needed, > > > - Most users probably do not know what to answer anyway. > > > > > > Fixes: 7c5b184db7145fd4 ("genpt: Generic Page Table base API") > > > Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> > > > --- > > > drivers/iommu/generic_pt/Kconfig | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> > > Actually, it doesn't work :\ > > $ tools/testing/kunit/kunit.py run --build_dir build_kunit_x86_64 --arch x86_64 --kunitconfig ./drivers/iommu/generic_pt/.kunitconfig > [13:01:26] Configuring KUnit Kernel ... > [13:01:26] Building KUnit Kernel ... > Populating config with: > $ make ARCH=x86_64 O=build_kunit_x86_64 olddefconfig > Building with: > $ make all compile_commands.json scripts_gdb ARCH=x86_64 O=build_kunit_x86_64 --jobs=20 > ERROR:root:Not all Kconfig options selected in kunitconfig were in the generated .config. > This is probably due to unsatisfied dependencies. > Missing: CONFIG_IOMMUFD_TEST=y, CONFIG_DEBUG_GENERIC_PT=y, CONFIG_IOMMU_PT_VTDSS=y, CONFIG_IOMMU_PT=y, CONFIG_IOMMU_PT_AMDV1=y, CONFIG_IOMMU_PT_X86_64=y, CONFIG_GENERIC_PT=y, CONFIG_IOMMU_PT_KUNIT_TEST=y > > Can you add this hunk and send a v2? > > --- a/drivers/iommu/generic_pt/.kunitconfig > +++ b/drivers/iommu/generic_pt/.kunitconfig > @@ -1,4 +1,5 @@ > CONFIG_KUNIT=y > +CONFIG_COMPILE_TEST=y > CONFIG_GENERIC_PT=y > CONFIG_DEBUG_GENERIC_PT=y > CONFIG_IOMMU_PT=y Do you really want to enable CONFIG_COMPILE_TEST in a .kunitconfig? Hm, that .kunitconfig already enables IOMMUFD_TEST, which is documented to be dangerous (why?), and already enabled by allyesconfig (except on GENERIC_ATOMIC64 architectures). IOMMUFD_TEST cannot select GENERIC_PT, as that would lead to a recursive dependency (and I am not a huge fan of test code auto-enabling extra attack surfaces^W^W functionality). Or perhaps: - bool "Generic Radix Page Table" + bool "Generic Radix Page Table" if COMPILE_TEST || KUNIT ? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds

1 week, 4 days

2
1
0 0

[PATCH v4 0/9] riscv: vector: misc ptrace fixes for debug use-cases

by Sergey Matyukevich

This patch series suggests fixes for several corner cases in the RISC-V vector ptrace implementation: - init vector context with proper vlenb, to avoid reading zero vlenb by an early attached debugger - follow gdbserver expectations and return ENODATA instead of EINVAL if vector extension is supported but not yet activated for the traced process - validate input vector csr registers in ptrace, to maintain an accurate view of the tracee's vector context across multiple halt/resume debug cycles For detailed description see the appropriate commit messages. A new test suite v_ptrace is added into the tools/testing/selftests/riscv/vector to verify some of the vector ptrace functionality and corner cases. Previous versions: - v3: https://lore.kernel.org/linux-riscv/20251025210655.43099-1-geomatsi@gmail.c… - v2: https://lore.kernel.org/linux-riscv/20250821173957.563472-1-geomatsi@gmail.… - v1: https://lore.kernel.org/linux-riscv/20251007115840.2320557-1-geomatsi@gmail… Changes in v4: The form 'vsetvli x0, x0, ...' can only be used if VLMAX remains unchanged, see spec 6.2. This condition was not met by the initial values in the selftests w.r.t. the initial zeroed context. QEMU accepted such values, but actual hardware (c908, BananaPi CanMV Zero board) did not, setting vill. So fix the selftests after testing on hardware: - replace 'vsetvli x0, x0, ...' by 'vsetvli rd, x0, ...' - fixed instruction returns VLMAX, so use it in checks as well - replace fixed vlenb == 16 in the syscall test Changes in v3: Address the review comments by Andy Chiu and rework the approach: - drop forced vector context save entirely - perform strict validation of vector csr regs in ptrace Changes in v2: - add thread_info flag to allow to force vector context save - force vector context save after vector ptrace to ensure valid vector context in the next ptrace operations - force vector context save on the first context switch after vector context init to get proper vlenb --- Ilya Mamay (1): riscv: ptrace: return ENODATA for inactive vector extension Sergey Matyukevich (8): selftests: riscv: test ptrace vector interface selftests: riscv: verify initial vector state with ptrace riscv: vector: init vector context with proper vlenb riscv: csr: define vtype registers elements riscv: ptrace: validate input vector csr registers selftests: riscv: verify ptrace rejects invalid vector csr inputs selftests: riscv: verify ptrace accepts valid vector csr values selftests: riscv: verify syscalls discard vector context arch/riscv/include/asm/csr.h | 11 + arch/riscv/kernel/ptrace.c | 72 +- arch/riscv/kernel/vector.c | 12 +- .../testing/selftests/riscv/vector/.gitignore | 1 + tools/testing/selftests/riscv/vector/Makefile | 5 +- .../testing/selftests/riscv/vector/v_ptrace.c | 754 ++++++++++++++++++ 6 files changed, 847 insertions(+), 8 deletions(-) create mode 100644 tools/testing/selftests/riscv/vector/v_ptrace.c base-commit: e811c33b1f137be26a20444b79db8cbc1fca1c89 -- 2.51.0

1 week, 4 days

2
11
0 0

[RFC PATCH 00/13] Introduce per-vCPU vLPI injection control API

by Maximilian Dittgen

At the moment, the ability to direct-inject vLPIs is only enableable on an all-or-nothing per-VM basis, causing unnecessary I/O performance loss in cases where a VM's vCPU count exceeds available vPEs. This RFC introduces per-vCPU control over vLPI injection to realize potential I/O performance gain in such situations. Background ---------- The value of dynamically enabling the direct injection of vLPIs on a per-vCPU basis is the ability to run guest VMs with simultaneous hardware-forwarded and software-forwarded message-signaled interrupts. Currently, hardware-forwarded vLPI direct injection on a KVM guest requires GICv4 and is enabled on a per-VM, all-or-nothing basis. vLPI injection enablment happens in two stages: 1) At vGIC initialization, allocate direct injection structures for each vCPU (doorbell IRQ, vPE table entry, virtual pending table, vPEID). 2) When a PCI device is configured for passthrough, map its MSIs to vLPIs using the structures allocated in step 1. Step 1 is all-or-nothing; if any vCPU cannot be configured with the vPE structures necessary for direct injection, the vPEs of all vCPUs are torn down and direct injection is disabled VM-wide. This universality of direct vLPI injection enablement sparks several issues, with the most pressing being performance degradation on overcommitted hosts. VM-wide vLPI enablement creates resource inefficiency when guest VMs have more vCPUs than the host has available vPEIDs. The amount of vPEIDs (and consequently, vPEs) a host can allocate is constrained by hardware and defined by GICD_TYPER2.VID + 1 (ITS_MAX_VPEID). Since direct injection requires a vCPU to be assigned a vPEID, at most ITS_MAX_VPEID vCPUs can be configured for direct injection at a time. Because vLPI direct injection is all-or-nothing on a VM, if a new guest VM would exhaust remaining vPEIDs, all vCPUs on that VM would fall back to hypervisor-forwarded LPIs, causing considerable I/O performance degradation. Such performance degradation is exemplified on hosts with CPU overcommitment. Overcommitting an arbitrarily high number of vCPUs enables a VM's vCPU count to easily exceed the host's available vPEIDs. Even with marginally more vCPUs than vPEIDs, the current all-or-nothing vLPI paradigm disables direct injection entirely. This creates two problems: first, a single many-vCPU overcommitted VM loses all direct injection despite having vPEIDs available; second, on multi-tenant hosts, VMs booted first consume all vPEIDs, leaving later VMs without direct injection regardless of their I/O intensity. Per-vCPU control would allow userspace to allocate available vPEIDs across VMs based on I/O workload rather than boot order or per-VM vCPU count. This per-vCPU granularity recovers most of the direct injection performance benefit instead of losing it completely. To allow this per-vCPU granularity, this RFC introduces three new ioctls to the KVM API that enables userspace the ability to activate/deactivate direct vLPI injection capability and resources to vCPUs ad-hoc during VM runtime. This RFC proposes userspace control, rather than kernel control, over vPEID allocation for simplicity of implementation, ease of testability, and autonomy over resource usage. In the future, the vLPI enable/disable building blocks from this RFC may be used to implement a full vPE allocation policy in the kernel. The solution comes in several parts ----------------------------------- 1) [P 1] General declarations (ioctl definitions/stubs, kconfig option) 2) [P 2] Conditionally disable auto vLPI injection init routines To prevent vCPUs from exceeding vPEID allocation limits upon VM boot, disable automatic vPEID allocation in the GICv4 initialization routine when the per-vCPU kconfig is active. Likewise, disable automatic hardware forwarding for PCI device-backed MSIs upon device registration. 3) [P 3-6] Implement per-vCPU vLPI enablement routine, which: a) Creates per-vCPU doorbell IRQ on new vCPU-scoped, rather than VM-scoped, interrupt domain hierarchies. b) Allocates per-vCPU vPE table entries and virtual pending table, linking them to the vCPU's doorbell IRQ. c) Iterates through interrupt translation table to set hardware forwarding for all PCI device–backed interrupts targeting the specific vCPU. 3) [P 7-8] Implement per-vCPU vLPI disablement routine, which a) Iterates through interrupt translation table to unset hardware forwarding for all interrupts targeting the specific vCPU. b) Frees per-vCPU vPE table entries, virtual pending table, and doorbell IRQ, then removes vgic_dist's pointer to the vCPU's freed vPE. 4) [P 9] Couple vSGI enablement with per-vCPU vPE allocation Since vSGIs cannot be direct-injected without an allocated vPE on the receiving vCPU, couple vSGI enablement with vLPI enablement on GICv4.1. 5) [P 10-13] Write selftests for vLPI direct injection PCI devices cannot be passed through to selftest guests, so define an ioctl that mocks a hardware source for software-defined MSI interrupts and sets vLPI "hardware" forwarding for the MSIs. Use these vLPIs to selftest per-vCPU vLPI enablement/disablement ioctls. Testing ------- Testing has been carried out via selftests and QEMU-emulated guests. Selftests have covered diverse vLPI configurations and race conditions. These include: 1) Stress testing LPI injection across multiple vCPUs while concurrently and repeatedly toggling the vCPUs' vLPI injection capability. 2) Enabling/disabling vLPI direct injection while scheduling or unscheduling a vCPU. 3) Allocating and freeing a single vPEID to multiple vCPUs, ensuring reusability. 4) Attempting to allocate a vPEID when all are already allocated, validating an error is thrown. 5) Calling enable/disable vLPI ioctls when GIC is not initialized. 6) Idempotent ioctl calls. PCI device passthrough and interrupt injection to QEMU guest demonstrated: 1) Complete hypervisor circumvention when vLPI injection is enabled on a vCPU, hypervisor forwarding when vLPI injection is disabled. 2) Interrupts are not lost when received during per-vCPU vLPI state transitions. Caveats ------- 1) Pending interrupts are flushed when vLPI injection is disabled for a vCPU; hardware pending state is not transfered to software. This may cause pending interrupts to be lost upon vPE disablement. Unlike vSGIs, vLPIs do not expose their pending state through a GICD_ISPENDR register. Thus, we would need to read the pending state of the vLPI from the vPT. To read the pending status of the vLPI from vPT, we would need to invalidate any vPT cache associated with the vCPU's vPE. This requires unmapping the vPE and halting the vCPU, which would be incredibly expensive and unecessary given that MSIs are usually recoverable by the driver. 2) Direct-injected vSGIs (GICv4.1) require vCPUs to have associated vPEs. Since disabling vLPI injection on a vCPU frees its vPE, vSGI direct injection must simultaenously be disabled as well. At the moment, we use the per-vCPU vSGI toggle mechanism introduced in commit bacf2c6 to enable/disable vSGI injection alongside vLPI injection. Maximilian Dittgen (13): KVM: Introduce config option for per-vCPU vLPI enablement KVM: arm64: Disable auto vCPU vPE assignment with per-vCPU vLPI config KVM: arm64: Refactor out locked section of kvm_vgic_v4_set_forwarding() KVM: arm64: Implement vLPI QUERY ioctl for per-vCPU vLPI injection API KVM: arm64: Implement vLPI ENABLE ioctl for per-vCPU vLPI injection API KVM: arm64: Resolve race between vCPU scheduling and vLPI enablement KVM: arm64: Implement vLPI DISABLE ioctl for per-vCPU vLPI Injection API KVM: arm64: Make per-vCPU vLPI control ioctls atomic KVM: arm64: Couple vSGI enablement with per-vCPU vPE allocation KVM: selftests: fix MAPC RDbase target formatting in vgic_lpi_stress KVM: Ioctl to set up userspace-injected MSIs as software-bypassing vLPIs KVM: arm64: selftests: Add support for stress testing direct-injected vLPIs KVM: arm64: selftests: Add test for per-vCPU vLPI control API Documentation/virt/kvm/api.rst | 56 +++ arch/arm64/kvm/arm.c | 89 +++++ arch/arm64/kvm/vgic/vgic-its.c | 142 ++++++- arch/arm64/kvm/vgic/vgic-v3.c | 14 +- arch/arm64/kvm/vgic/vgic-v4.c | 370 +++++++++++++++++- arch/arm64/kvm/vgic/vgic.h | 10 + drivers/irqchip/Kconfig | 13 + drivers/irqchip/irq-gic-v3-its.c | 58 ++- drivers/irqchip/irq-gic-v4.c | 75 +++- include/kvm/arm_vgic.h | 8 + include/linux/irqchip/arm-gic-v3.h | 5 + include/linux/irqchip/arm-gic-v4.h | 10 +- include/linux/kvm_host.h | 11 + include/uapi/linux/kvm.h | 22 ++ tools/testing/selftests/kvm/Makefile.kvm | 1 + .../selftests/kvm/arm64/per_vcpu_vlpi.c | 274 +++++++++++++ .../selftests/kvm/arm64/vgic_lpi_stress.c | 181 ++++++++- .../selftests/kvm/lib/arm64/gic_v3_its.c | 9 +- 18 files changed, 1307 insertions(+), 41 deletions(-) create mode 100644 tools/testing/selftests/kvm/arm64/per_vcpu_vlpi.c -- 2.50.1 (Apple Git-155) Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger, Christof Hellmis Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597

1 week, 4 days

2
15
0 0

[PATCH net-next v5 0/5] netconsole: support automatic target recovery

by Andre Carvalho

This patchset introduces target resume capability to netconsole allowing it to recover targets when underlying low-level interface comes back online. The patchset starts by refactoring netconsole state representation in order to allow representing deactivated targets (targets that are disabled due to interfaces going down). It then modifies netconsole to handle NETDEV_UP events for such targets and setups netpoll. Targets are matched with incoming interfaces depending on how they were initially bound in netconsole (by mac or interface name). The patchset includes a selftest that validates netconsole target state transitions and that target is functional after resumed. Signed-off-by: Andre Carvalho <asantostc(a)gmail.com> --- Changes in v5: - patch 3: Set (de)enslaved target as DISABLED instead of DEACTIVATED to prevent resuming it. - selftest: Fix test cleanup by moving trap line to outside of loop and remove unneeded 'local' keyword - Rename maybe_resume_target to resume_target, add netconsole_ prefix to process_resumable_targets. - Hold device reference before calling __netpoll_setup. - Link to v4: https://lore.kernel.org/r/20251116-netcons-retrigger-v4-0-5290b5f140c2@gmai… Changes in v4: - Simplify selftest cleanup, removing trap setup in loop. - Drop netpoll helper (__setup_netpoll_hold) and manage reference inside netconsole. - Move resume_list processing logic to separate function. - Link to v3: https://lore.kernel.org/r/20251109-netcons-retrigger-v3-0-1654c280bbe6@gmai… Changes in v3: - Resume by mac or interface name depending on how target was created. - Attempt to resume target without holding target list lock, by moving the target to a temporary list. This is required as netpoll may attempt to allocate memory. - Link to v2: https://lore.kernel.org/r/20250921-netcons-retrigger-v2-0-a0e84006237f@gmai… Changes in v2: - Attempt to resume target in the same thread, instead of using workqueue . - Add wrapper around __netpoll_setup (patch 4). - Renamed resume_target to maybe_resume_target and moved conditionals to inside its implementation, keeping code more clear. - Verify that device addr matches target mac address when target was setup using mac. - Update selftest to cover targets bound by mac and interface name. - Fix typo in selftest comment and sort tests alphabetically in Makefile. - Link to v1: https://lore.kernel.org/r/20250909-netcons-retrigger-v1-0-3aea904926cf@gmai… --- Andre Carvalho (3): netconsole: convert 'enabled' flag to enum for clearer state management netconsole: resume previously deactivated target selftests: netconsole: validate target resume Breno Leitao (2): netconsole: add target_state enum netconsole: add STATE_DEACTIVATED to track targets disabled by low level drivers/net/netconsole.c | 155 +++++++++++++++++---- tools/testing/selftests/drivers/net/Makefile | 1 + .../selftests/drivers/net/lib/sh/lib_netcons.sh | 35 ++++- .../selftests/drivers/net/netcons_resume.sh | 97 +++++++++++++ 4 files changed, 254 insertions(+), 34 deletions(-) --- base-commit: a057e8e4ac5b1ddd12be590e2e039fa08d0c8aa4 change-id: 20250816-netcons-retrigger-a4f547bfc867 Best regards, -- Andre Carvalho <asantostc(a)gmail.com>

1 week, 4 days

2
7
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror November 2025