January 2025 - Linux-kselftest-mirror

[PATCH 0/6] ptrace: introduce PTRACE_SET_SYSCALL_INFO API

by Dmitry V. Levin

PTRACE_SET_SYSCALL_INFO is a generic ptrace API that complements PTRACE_GET_SYSCALL_INFO by letting the ptracer modify details of system calls the tracee is blocked in. This API allows ptracers to obtain and modify system call details in a straightforward and architecture-agnostic way. Current implementation supports changing only those bits of system call information that are used by strace, namely, syscall number, syscall arguments, and syscall return value. Support of changing additional details returned by PTRACE_GET_SYSCALL_INFO, such as instruction pointer and stack pointer, could be added later if needed, by re-using struct ptrace_syscall_info.reserved to specify the additional details that should be set. Currently, the reserved field of struct ptrace_syscall_info must be initialized with zeroes; arch, instruction_pointer, and stack_pointer fields are ignored. PTRACE_SET_SYSCALL_INFO currently supports only PTRACE_SYSCALL_INFO_ENTRY, PTRACE_SYSCALL_INFO_EXIT, and PTRACE_SYSCALL_INFO_SECCOMP operations. Other operations could be added later if needed. Ideally, PTRACE_SET_SYSCALL_INFO should have been introduced along with PTRACE_GET_SYSCALL_INFO, but it didn't happen. The last straw that convinced me to implement PTRACE_SET_SYSCALL_INFO was apparent failure to provide an API of changing the first system call argument on riscv architecture [1]. ptrace(2) man page: long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data); ... PTRACE_SET_SYSCALL_INFO Modify information about the system call that caused the stop. The "data" argument is a pointer to struct ptrace_syscall_info that specifies the system call information to be set. The "addr" argument should be set to sizeof(struct ptrace_syscall_info)). [1] https://lore.kernel.org/all/59505464-c84a-403d-972f-d4b2055eeaac@gmail.com/ Dmitry V. Levin (6): Revert "arch: remove unused function syscall_set_arguments()" syscall.h: add syscall_set_arguments() on remaining HAVE_ARCH_TRACEHOOK arches syscall.h: introduce syscall_set_nr() ptrace_get_syscall_info: factor out ptrace_get_syscall_info_op ptrace: introduce PTRACE_SET_SYSCALL_INFO request selftests/ptrace: add a test case for PTRACE_SET_SYSCALL_INFO arch/arc/include/asm/syscall.h | 20 + arch/arm/include/asm/syscall.h | 25 + arch/arm64/include/asm/syscall.h | 20 + arch/csky/include/asm/syscall.h | 13 + arch/hexagon/include/asm/syscall.h | 14 + arch/loongarch/include/asm/syscall.h | 15 + arch/m68k/include/asm/syscall.h | 7 + arch/microblaze/include/asm/syscall.h | 7 + arch/mips/include/asm/syscall.h | 53 +++ arch/nios2/include/asm/syscall.h | 16 + arch/openrisc/include/asm/syscall.h | 13 + arch/parisc/include/asm/syscall.h | 19 + arch/powerpc/include/asm/syscall.h | 15 + arch/riscv/include/asm/syscall.h | 16 + arch/s390/include/asm/syscall.h | 19 + arch/sh/include/asm/syscall_32.h | 19 + arch/sparc/include/asm/syscall.h | 17 + arch/um/include/asm/syscall-generic.h | 19 + arch/x86/include/asm/syscall.h | 43 ++ arch/xtensa/include/asm/syscall.h | 18 + include/asm-generic/syscall.h | 30 ++ include/linux/ptrace.h | 3 + include/uapi/linux/ptrace.h | 3 +- kernel/ptrace.c | 154 ++++++- tools/testing/selftests/ptrace/Makefile | 2 +- .../selftests/ptrace/set_syscall_info.c | 436 ++++++++++++++++++ 26 files changed, 994 insertions(+), 22 deletions(-) create mode 100644 tools/testing/selftests/ptrace/set_syscall_info.c -- ldv

3 hours, 37 minutes

1
1
0 0

[PATCH v5 0/5] arm64: Support 2024 dpISA extensions

by Mark Brown

The 2024 architecture release includes a number of data processing extensions, mostly SVE and SME additions with a few others. These are all very straightforward extensions which add instructions but no architectural state so only need hwcaps and exposing of the ID registers to KVM guests and userspace. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Changes in v5: - Rebase onto arm64/for-next/cpufeature, which incorporates most of the sysreg updates from earlier versions. - Remove SF8MM8 and SF8MM4 register defintitions which were removed from the ISA in the 2024-12 XML release, along with their associated hwcaps. - Incorporate Marc's fix for SVE hwcaps on SME only systems and update the hwcaps for the newly added features to follow the same pattern. - Link to v4: https://lore.kernel.org/r/20241211-arm64-2024-dpisa-v4-0-0fd403876df2@kerne… Changes in v4: - Fix encodings for ID_AA64ISAR3_EL1. - Link to v3: https://lore.kernel.org/r/20241203-arm64-2024-dpisa-v3-0-a6c78b1aa297@kerne… Changes in v3: - Commit log update for the hwcap test. - Link to v2: https://lore.kernel.org/r/20241030-arm64-2024-dpisa-v2-0-b6601a15d2a5@kerne… Changes in v2: - Filter KVM guest visible bitfields in ID_AA64ISAR3_EL1 to only those we make writeable. - Link to v1: https://lore.kernel.org/r/20241028-arm64-2024-dpisa-v1-0-a38d08b008a8@kerne… --- Marc Zyngier (1): arm64: Filter out SVE hwcaps when FEAT_SVE isn't implemented Mark Brown (4): arm64/sysreg: Update ID_AA64SMFR0_EL1 to DDI0601 2024-12 arm64/hwcap: Describe 2024 dpISA extensions to userspace KVM: arm64: Allow control of dpISA extensions in ID_AA64ISAR3_EL1 kselftest/arm64: Add 2024 dpISA extensions to hwcap test Documentation/arch/arm64/elf_hwcaps.rst | 89 +++++++++-- arch/arm64/include/asm/hwcap.h | 15 ++ arch/arm64/include/uapi/asm/hwcap.h | 15 ++ arch/arm64/kernel/cpufeature.c | 71 +++++++-- arch/arm64/kernel/cpuinfo.c | 15 ++ arch/arm64/kvm/sys_regs.c | 6 +- arch/arm64/tools/sysreg | 26 +++- tools/testing/selftests/arm64/abi/hwcap.c | 235 +++++++++++++++++++++++++++++- 8 files changed, 441 insertions(+), 31 deletions(-) --- base-commit: d66e21d59ed0e043e68ef8c6541c1e9f1a962614 change-id: 20241008-arm64-2024-dpisa-8091074a7f48 Best regards, -- Mark Brown <broonie(a)kernel.org>

3 hours, 42 minutes

1
5
0 0

[PATCH v7 00/30] NT synchronization primitive driver

by Elizabeth Figura

This patch series implements a new char misc driver, /dev/ntsync, which is used to implement Windows NT synchronization primitives. NT synchronization primitives are unique in that the wait functions both are vectored, operate on multiple types of object with different behaviour (mutex, semaphore, event), and affect the state of the objects they wait on. This model is not compatible with existing kernel synchronization objects or interfaces, and therefore the ntsync driver implements its own wait queues and locking. This patch series is rebased against the "char-misc-next" branch of gregkh/char-misc.git. == Background == The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated "kernel" process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck. The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel. This driver was presented at Linux Plumbers Conference 2023. For those further interested in the history of synchronization in Wine and past attempts to solve this problem in user space, a recording of the presentation can be viewed here: https://www.youtube.com/watch?v=NjU4nyWyhU8 == Performance == The performance measurements described below are copied from earlier versions of the patch set. While some of the code has changed, I do not currently anticipate that it has changed drastically enough to affect those measurements. The gain in performance varies wildly depending on the application in question and the user's hardware. For some games NT synchronization is not a bottleneck and no change can be observed, but for others frame rate improvements of 50 to 150 percent are not atypical. The following table lists frame rate measurements from a variety of games on a variety of hardware, taken by users Dmitry Skvortsov, FuzzyQuils, OnMars, and myself: Game Upstream ntsync improvement =========================================================================== Anger Foot 69 99 43% Call of Juarez 99.8 224.1 125% Dirt 3 110.6 860.7 678% Forza Horizon 5 108 160 48% Lara Croft: Temple of Osiris 141 326 131% Metro 2033 164.4 199.2 21% Resident Evil 2 26 77 196% The Crew 26 51 96% Tiny Tina's Wonderlands 130 360 177% Total War Saga: Troy 109 146 34% =========================================================================== == Patches == The intended semantics of the patches are broadly intended to match those of the corresponding Windows functions. For those not already familiar with the Windows functions (or their undocumented behaviour), patch 27/28 provides a detailed specification, and individual patches also include a brief description of the API they are implementing. The patches making use of this driver in Wine can be retrieved or browsed here: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync7 == Previous versions == Changes from v6: * rename NTSYNC_IOC_SEM_POST to NTSYNC_IOC_SEM_RELEASE (matching the NT terminology instead of POSIX), * change object creation ioctls to return the fds directly in the return value instead of through the args struct, which simplifies the API a bit. * Link to v6: https://lore.kernel.org/lkml/20241209185904.507350-1-zfigura@codeweavers.co… * Link to v5: https://lore.kernel.org/lkml/20240519202454.1192826-1-zfigura@codeweavers.c… * Link to v4: https://lore.kernel.org/lkml/20240416010837.333694-1-zfigura@codeweavers.co… * Link to v3: https://lore.kernel.org/lkml/20240329000621.148791-1-zfigura@codeweavers.co… * Link to v2: https://lore.kernel.org/lkml/20240219223833.95710-1-zfigura@codeweavers.com/ * Link to v1: https://lore.kernel.org/lkml/20240214233645.9273-1-zfigura@codeweavers.com/ * Link to RFC v2: https://lore.kernel.org/lkml/20240131021356.10322-1-zfigura@codeweavers.com/ * Link to RFC v1: https://lore.kernel.org/lkml/20240124004028.16826-1-zfigura@codeweavers.com/ Elizabeth Figura (30): ntsync: Return the fd from NTSYNC_IOC_CREATE_SEM. ntsync: Rename NTSYNC_IOC_SEM_POST to NTSYNC_IOC_SEM_RELEASE. ntsync: Introduce NTSYNC_IOC_WAIT_ANY. ntsync: Introduce NTSYNC_IOC_WAIT_ALL. ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX. ntsync: Introduce NTSYNC_IOC_MUTEX_UNLOCK. ntsync: Introduce NTSYNC_IOC_MUTEX_KILL. ntsync: Introduce NTSYNC_IOC_CREATE_EVENT. ntsync: Introduce NTSYNC_IOC_EVENT_SET. ntsync: Introduce NTSYNC_IOC_EVENT_RESET. ntsync: Introduce NTSYNC_IOC_EVENT_PULSE. ntsync: Introduce NTSYNC_IOC_SEM_READ. ntsync: Introduce NTSYNC_IOC_MUTEX_READ. ntsync: Introduce NTSYNC_IOC_EVENT_READ. ntsync: Introduce alertable waits. selftests: ntsync: Add some tests for semaphore state. selftests: ntsync: Add some tests for mutex state. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for manual-reset event state. selftests: ntsync: Add some tests for auto-reset event state. selftests: ntsync: Add some tests for wakeup signaling with events. selftests: ntsync: Add tests for alertable waits. selftests: ntsync: Add some tests for wakeup signaling via alerts. selftests: ntsync: Add a stress test for contended waits. maintainers: Add an entry for ntsync. docs: ntsync: Add documentation for the ntsync uAPI. ntsync: No longer depend on BROKEN. Documentation/userspace-api/index.rst | 1 + Documentation/userspace-api/ntsync.rst | 385 +++++ MAINTAINERS | 9 + drivers/misc/Kconfig | 1 - drivers/misc/ntsync.c | 992 +++++++++++- include/uapi/linux/ntsync.h | 42 +- tools/testing/selftests/Makefile | 1 + .../selftests/drivers/ntsync/.gitignore | 1 + .../testing/selftests/drivers/ntsync/Makefile | 7 + tools/testing/selftests/drivers/ntsync/config | 1 + .../testing/selftests/drivers/ntsync/ntsync.c | 1343 +++++++++++++++++ 11 files changed, 2767 insertions(+), 16 deletions(-) create mode 100644 Documentation/userspace-api/ntsync.rst create mode 100644 tools/testing/selftests/drivers/ntsync/.gitignore create mode 100644 tools/testing/selftests/drivers/ntsync/Makefile create mode 100644 tools/testing/selftests/drivers/ntsync/config create mode 100644 tools/testing/selftests/drivers/ntsync/ntsync.c base-commit: cdd30ebb1b9f36159d66f088b61aee264e649d7a -- 2.45.2

5 hours, 31 minutes

3
33
0 0

[PATCH net-next v7 00/11] net: Improve netns handling in rtnetlink

by Xiao Liang

This patch series includes some netns-related improvements and fixes for rtnetlink, to make link creation more intuitive: 1) Creating link in another net namespace doesn't conflict with link names in current one. 2) Refector rtnetlink link creation. Create link in target namespace directly. So that # ip link add netns ns1 link-netns ns2 tun0 type gre ... will create tun0 in ns1, rather than create it in ns2 and move to ns1. And don't conflict with another interface named "tun0" in current netns. Patch 01 serves for 1) to avoids link name conflict in different netns. To achieve 2), there're mainly 3 steps: - Patch 02 packs newlink() parameters into a struct, including the original "src_net" along with more netns context. No semantic changes are introduced. - Patch 03 ~ 07 converts device drivers to use the explicit netns extracted from params. - Patch 08 ~ 09 removes the old netns parameter, and converts rtnetlink to create device in target netns directly. Patch 10 ~ 11 adds some tests for link name and link netns. BTW please note there're some issues found in current code: - In amt_newlink() drivers/net/amt.c: amt->net = net; ... amt->stream_dev = dev_get_by_index(net, ... Uses net, but amt_lookup_upper_dev() only searches in dev_net. So the AMT device may not be properly deleted if it's in a different netns from lower dev. - In gtp_newlink() in drivers/net/gtp.c: gtp->net = src_net; ... gn = net_generic(dev_net(dev), gtp_net_id); list_add_rcu(&gtp->list, &gn->gtp_dev_list); Uses src_net, but priv is linked to list in dev_net. So it may not be properly deleted on removal of link netns. - In pfcp_newlink() in drivers/net/pfcp.c: pfcp->net = net; ... pn = net_generic(dev_net(dev), pfcp_net_id); list_add_rcu(&pfcp->list, &pn->pfcp_dev_list); Same as above. - In lowpan_newlink() in net/ieee802154/6lowpan/core.c: wdev = dev_get_by_index(dev_net(ldev), nla_get_u32(tb[IFLA_LINK])); Looks for IFLA_LINK in dev_net, but in theory the ifindex is defined in link netns. --- v7: - Add selftest kconfig. - Remove a duplicated test of ip6gre. v6: link: https://lore.kernel.org/all/20241218130909.2173-1-shaw.leon@gmail.com/ - Split prototype, driver and rtnetlink changes. - Add more tests for link netns. - Fix IPv6 tunnel net overwriten in ndo_init(). - Reorder variable declarations. - Exclude a ip_tunnel-specific patch. v5: link: https://lore.kernel.org/all/20241209140151.231257-1-shaw.leon@gmail.com/ - Fix function doc in batman-adv. - Include peer_net in rtnl newlink parameters. v4: link: https://lore.kernel.org/all/20241118143244.1773-1-shaw.leon@gmail.com/ - Pack newlink() parameters to a single struct. - Use ynl async_msg_queue.empty() in selftest. v3: link: https://lore.kernel.org/all/20241113125715.150201-1-shaw.leon@gmail.com/ - Drop "netns_atomic" flag and module parameter. Add netns parameter to newlink() instead, and convert drivers accordingly. - Move python NetNSEnter helper to net selftest lib. v2: link: https://lore.kernel.org/all/20241107133004.7469-1-shaw.leon@gmail.com/ - Check NLM_F_EXCL to ensure only link creation is affected. - Add self tests for link name/ifindex conflict and notifications in different netns. - Changes in dummy driver and ynl in order to add the test case. v1: link: https://lore.kernel.org/all/20241023023146.372653-1-shaw.leon@gmail.com/ Xiao Liang (11): rtnetlink: Lookup device in target netns when creating link rtnetlink: Pack newlink() params into struct net: Use link netns in newlink() of rtnl_link_ops ieee802154: 6lowpan: Use link netns in newlink() of rtnl_link_ops net: ip_tunnel: Use link netns in newlink() of rtnl_link_ops net: ipv6: Use link netns in newlink() of rtnl_link_ops net: xfrm: Use link netns in newlink() of rtnl_link_ops rtnetlink: Remove "net" from newlink params rtnetlink: Create link directly in target net namespace selftests: net: Add python context manager for netns entering selftests: net: Add test cases for link and peer netns drivers/infiniband/ulp/ipoib/ipoib_netlink.c | 11 +- drivers/net/amt.c | 16 +- drivers/net/bareudp.c | 11 +- drivers/net/bonding/bond_netlink.c | 8 +- drivers/net/can/dev/netlink.c | 4 +- drivers/net/can/vxcan.c | 9 +- .../ethernet/qualcomm/rmnet/rmnet_config.c | 11 +- drivers/net/geneve.c | 11 +- drivers/net/gtp.c | 9 +- drivers/net/ipvlan/ipvlan.h | 4 +- drivers/net/ipvlan/ipvlan_main.c | 15 +- drivers/net/ipvlan/ipvtap.c | 10 +- drivers/net/macsec.c | 15 +- drivers/net/macvlan.c | 8 +- drivers/net/macvtap.c | 11 +- drivers/net/netkit.c | 9 +- drivers/net/pfcp.c | 11 +- drivers/net/ppp/ppp_generic.c | 10 +- drivers/net/team/team_core.c | 7 +- drivers/net/veth.c | 9 +- drivers/net/vrf.c | 11 +- drivers/net/vxlan/vxlan_core.c | 11 +- drivers/net/wireguard/device.c | 11 +- drivers/net/wireless/virtual/virt_wifi.c | 14 +- drivers/net/wwan/wwan_core.c | 25 +++- include/net/ip_tunnels.h | 5 +- include/net/rtnetlink.h | 44 +++++- net/8021q/vlan_netlink.c | 15 +- net/batman-adv/soft-interface.c | 16 +- net/bridge/br_netlink.c | 12 +- net/caif/chnl_net.c | 6 +- net/core/rtnetlink.c | 35 +++-- net/hsr/hsr_netlink.c | 14 +- net/ieee802154/6lowpan/core.c | 9 +- net/ipv4/ip_gre.c | 27 ++-- net/ipv4/ip_tunnel.c | 10 +- net/ipv4/ip_vti.c | 10 +- net/ipv4/ipip.c | 14 +- net/ipv6/ip6_gre.c | 42 ++++-- net/ipv6/ip6_tunnel.c | 20 ++- net/ipv6/ip6_vti.c | 16 +- net/ipv6/sit.c | 18 ++- net/xfrm/xfrm_interface_core.c | 15 +- tools/testing/selftests/net/Makefile | 1 + tools/testing/selftests/net/config | 5 + .../testing/selftests/net/lib/py/__init__.py | 2 +- tools/testing/selftests/net/lib/py/netns.py | 18 +++ tools/testing/selftests/net/link_netns.py | 141 ++++++++++++++++++ tools/testing/selftests/net/netns-name.sh | 10 ++ 49 files changed, 550 insertions(+), 226 deletions(-) create mode 100755 tools/testing/selftests/net/link_netns.py -- 2.47.1

6 hours, 4 minutes

3
16
0 0

[PATCH 0/3] selftests: bpf: Migrate test_xdp_redirect.sh to test_progs

by Bastien Curutchet (eBPF Foundation)

Hi all, This patch series continues the work to migrate the *.sh tests into prog_tests. test_xdp_redirect.sh tests the XDP redirections done through bpf_redirect(). These XDP redirections are already tested by prog_tests/xdp_do_redirect.c but IMO it doesn't cover the exact same code path because xdp_do_redirect.c uses bpf_prog_test_run_opts() to trigger redirections of 'fake packets' while test_xdp_redirect.sh redirects packets coming from the network. Also, the test_xdp_redirect.sh script tests the redirections with both SKB and DRV modes while xdp_do_redirect.c only tests the DRV mode. The patch series adds two new test cases in prog_tests/xdp_do_redirect.c to replace the test_xdp_redirect.sh script. Signed-off-by: Bastien Curutchet (eBPF Foundation) <bastien.curutchet(a)bootlin.com> --- Bastien Curutchet (eBPF Foundation) (3): selftests/bpf: test_xdp_redirect: Rename BPF sections selftests/bpf: Migrate test_xdp_redirect.sh to xdp_do_redirect.c selftests/bpf: Migrate test_xdp_redirect.c to test_xdp_do_redirect.c tools/testing/selftests/bpf/Makefile | 1 - .../selftests/bpf/prog_tests/xdp_do_redirect.c | 192 +++++++++++++++++++++ .../selftests/bpf/progs/test_xdp_do_redirect.c | 12 ++ .../selftests/bpf/progs/test_xdp_redirect.c | 26 --- tools/testing/selftests/bpf/test_xdp_redirect.sh | 79 --------- 5 files changed, 204 insertions(+), 106 deletions(-) --- base-commit: da86bde1e6d1b887efc46af5ee1f9bbccd27233e change-id: 20241219-xdp_redirect-2b8ec79dc24e Best regards, -- Bastien Curutchet (eBPF Foundation) <bastien.curutchet(a)bootlin.com>

6 hours, 53 minutes

4
10
0 0

[PATCH v4 0/9] arm64: Support 2024 dpISA extensions

by Mark Brown

The 2024 architecture release includes a number of data processing extensions, mostly SVE and SME additions with a few others. These are all very straightforward extensions which add instructions but no architectural state so only need hwcaps and exposing of the ID registers to KVM guests and userspace. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Changes in v4: - Fix encodings for ID_AA64ISAR3_EL1. - Link to v3: https://lore.kernel.org/r/20241203-arm64-2024-dpisa-v3-0-a6c78b1aa297@kerne… Changes in v3: - Commit log update for the hwcap test. - Link to v2: https://lore.kernel.org/r/20241030-arm64-2024-dpisa-v2-0-b6601a15d2a5@kerne… Changes in v2: - Filter KVM guest visible bitfields in ID_AA64ISAR3_EL1 to only those we make writeable. - Link to v1: https://lore.kernel.org/r/20241028-arm64-2024-dpisa-v1-0-a38d08b008a8@kerne… --- Mark Brown (9): arm64/sysreg: Update ID_AA64PFR2_EL1 to DDI0601 2024-09 arm64/sysreg: Update ID_AA64ISAR3_EL1 to DDI0601 2024-09 arm64/sysreg: Update ID_AA64FPFR0_EL1 to DDI0601 2024-09 arm64/sysreg: Update ID_AA64ZFR0_EL1 to DDI0601 2024-09 arm64/sysreg: Update ID_AA64SMFR0_EL1 to DDI0601 2024-09 arm64/sysreg: Update ID_AA64ISAR2_EL1 to DDI0601 2024-09 arm64/hwcap: Describe 2024 dpISA extensions to userspace KVM: arm64: Allow control of dpISA extensions in ID_AA64ISAR3_EL1 kselftest/arm64: Add 2024 dpISA extensions to hwcap test Documentation/arch/arm64/elf_hwcaps.rst | 51 ++++++ arch/arm64/include/asm/hwcap.h | 17 ++ arch/arm64/include/uapi/asm/hwcap.h | 17 ++ arch/arm64/kernel/cpufeature.c | 35 ++++ arch/arm64/kernel/cpuinfo.c | 17 ++ arch/arm64/kvm/sys_regs.c | 6 +- arch/arm64/tools/sysreg | 87 +++++++++- tools/testing/selftests/arm64/abi/hwcap.c | 273 +++++++++++++++++++++++++++++- 8 files changed, 493 insertions(+), 10 deletions(-) --- base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37 change-id: 20241008-arm64-2024-dpisa-8091074a7f48 Best regards, -- Mark Brown <broonie(a)kernel.org>

9 hours, 23 minutes

3
15
0 0

[PATCH v5 00/14] iommufd: Add vIOMMU infrastructure (Part-3: vEVENTQ)

by Nicolin Chen

As the vIOMMU infrastructure series part-3, this introduces a new vEVENTQ object. The existing FAULT object provides a nice notification pathway to the user space with a queue already, so let vEVENTQ reuse that. Mimicing the HWPT structure, add a common EVENTQ structure to support its derivatives: IOMMUFD_OBJ_FAULT (existing) and IOMMUFD_OBJ_VEVENTQ (new). An IOMMUFD_CMD_VEVENTQ_ALLOC is introduced to allocate vEVENTQ object for vIOMMUs. One vIOMMU can have multiple vEVENTQs in different types but can not support multiple vEVENTQs in the same type. The forwarding part is fairly simple but might need to replace a physical device ID with a virtual device ID in a driver-level event data structure. So, this also adds some helpers for drivers to use. As usual, this series comes with the selftest coverage for this new ioctl and with a real world use case in the ARM SMMUv3 driver. This is on Github: https://github.com/nicolinc/iommufd/commits/iommufd_veventq-v5 Testing with RMR patches for MSI: https://github.com/nicolinc/iommufd/commits/iommufd_veventq-v5-with-rmr Paring QEMU branch for testing: https://github.com/nicolinc/qemu/commits/wip/for_iommufd_veventq-v5 Changelog v5 * Add Reviewed-by from Baolu * Reorder the OBJ list as well * Fix alphabetical order after renaming in v4 * Add supports_veventq viommu op for vEVENTQ type validation v4 https://lore.kernel.org/all/cover.1735933254.git.nicolinc@nvidia.com/ * Rename "vIRQ" to "vEVENTQ" * Use flexible array in struct iommufd_vevent * Add the new ioctl command to union ucmd_buffer * Fix the alphabetical order in union ucmd_buffer too * Rename _TYPE_NONE to _TYPE_DEFAULT aligning with vIOMMU naming v3 https://lore.kernel.org/all/cover.1734477608.git.nicolinc@nvidia.com/ * Rebase on Will's for-joerg/arm-smmu/updates for arm_smmu_event series * Add "Reviewed-by" lines from Kevin * Fix typos in comments, kdocs, and jump tags * Add a patch to sort struct iommufd_ioctl_op * Update iommufd's userpsace-api documentation * Update uAPI kdoc to quote SMMUv3 offical spec * Drop the unused workqueue in struct iommufd_virq * Drop might_sleep() in iommufd_viommu_report_irq() helper * Add missing "break" in iommufd_viommu_get_vdev_id() helper * Shrink the scope of the vmaster's read lock in SMMUv3 driver * Pass in two arguments to iommufd_eventq_virq_handler() helper * Move "!ops || !ops->read" validation into iommufd_eventq_init() * Move "fault->ictx = ictx" closer to iommufd_ctx_get(fault->ictx) * Update commit message for arm_smmu_attach_prepare/commit_vmaster() * Keep "iommufd_fault" as-is and rename "iommufd_eventq_virq" to just "iommufd_virq" v2 https://lore.kernel.org/all/cover.1733263737.git.nicolinc@nvidia.com/ * Rebase on v6.13-rc1 * Add IOPF and vIRQ in iommufd.rst (userspace-api) * Add a proper locking in iommufd_event_virq_destroy * Add iommufd_event_virq_abort with a lockdep_assert_held * Rename "EVENT_*" to "EVENTQ_*" to describe the objects better * Reorganize flows in iommufd_eventq_virq_alloc for abort() to work * Adde struct arm_smmu_vmaster to store vSID upon attaching to a nested domain, calling a newly added iommufd_viommu_get_vdev_id helper * Adde an arm_vmaster_report_event helper in arm-smmu-v3-iommufd file to simplify the routine in arm_smmu_handle_evt() of the main driver v1 https://lore.kernel.org/all/cover.1724777091.git.nicolinc@nvidia.com/ Thanks! Nicolin Nicolin Chen (14): iommufd: Keep OBJ/IOCTL lists in an alphabetical order iommufd/fault: Add an iommufd_fault_init() helper iommufd/fault: Move iommufd_fault_iopf_handler() to header iommufd: Abstract an iommufd_eventq from iommufd_fault iommufd: Rename fault.c to eventq.c iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC iommufd/viommu: Add iommufd_viommu_get_vdev_id helper iommufd/viommu: Add iommufd_viommu_report_event helper iommufd/selftest: Require vdev_id when attaching to a nested domain iommufd/selftest: Add IOMMU_TEST_OP_TRIGGER_VEVENT for vEVENTQ coverage iommufd/selftest: Add IOMMU_VEVENTQ_ALLOC test coverage Documentation: userspace-api: iommufd: Update FAULT and VEVENTQ iommu/arm-smmu-v3: Introduce struct arm_smmu_vmaster iommu/arm-smmu-v3: Report events that belong to devices attached to vIOMMU drivers/iommu/iommufd/Makefile | 2 +- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 30 ++ drivers/iommu/iommufd/iommufd_private.h | 116 ++++++- drivers/iommu/iommufd/iommufd_test.h | 10 + include/linux/iommufd.h | 24 ++ include/uapi/linux/iommufd.h | 46 +++ tools/testing/selftests/iommu/iommufd_utils.h | 65 ++++ .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 71 ++++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 90 ++++-- drivers/iommu/iommufd/driver.c | 63 ++++ drivers/iommu/iommufd/{fault.c => eventq.c} | 303 ++++++++++++++---- drivers/iommu/iommufd/hw_pagetable.c | 6 +- drivers/iommu/iommufd/main.c | 37 ++- drivers/iommu/iommufd/selftest.c | 53 +++ drivers/iommu/iommufd/viommu.c | 2 + tools/testing/selftests/iommu/iommufd.c | 27 ++ .../selftests/iommu/iommufd_fail_nth.c | 7 + Documentation/userspace-api/iommufd.rst | 16 + 18 files changed, 843 insertions(+), 125 deletions(-) rename drivers/iommu/iommufd/{fault.c => eventq.c} (54%) base-commit: e94dc6ddda8dd3770879a132d577accd2cce25f9 -- 2.43.0

9 hours, 32 minutes

1
14
0 0

Re: [PATCH 2/3] KVM: x86: Add support for VMware guest specific hypercalls

by Doug Covelli

On Wed, Nov 13, 2024 at 2:31 AM Paolo Bonzini <pbonzini(a)redhat.com> wrote: > > > > Il mar 12 nov 2024, 21:44 Doug Covelli <doug.covelli(a)broadcom.com> ha scritto: >> >> > Split irqchip should be the best tradeoff. Without it, moves from cr8 >> > stay in the kernel, but moves to cr8 always go to userspace with a >> > KVM_EXIT_SET_TPR exit. You also won't be able to use Intel >> > flexpriority (in-processor accelerated TPR) because KVM does not know >> > which bits are set in IRR. So it will be *really* every move to cr8 >> > that goes to userspace. >> >> Sorry to hijack this thread but is there a technical reason not to allow CR8 >> based accesses to the TPR (not MMIO accesses) when the in-kernel local APIC is >> not in use? > > > No worries, you're not hijacking :) The only reason is that it would be more code for a seldom used feature and anyway with worse performance. (To be clear, CR8 based accesses are allowed, but stores cause an exit in order to check the new TPR against IRR. That's because KVM's API does not have an equivalent of the TPR threshold as you point out below). I have not really looked at the code but it seems like it could also simplify things as CR8 would be handled more uniformly regardless of who is virtualizing the local APIC. >> Also I could not find these documented anywhere but with MSFT's APIC our monitor >> relies on extensions for trapping certain events such as INIT/SIPI plus LINT0 >> and SVR writes: >> >> UINT64 X64ApicInitSipiExitTrap : 1; // WHvRunVpExitReasonX64ApicInitSipiTrap >> UINT64 X64ApicWriteLint0ExitTrap : 1; // WHvRunVpExitReasonX64ApicWriteTrap >> UINT64 X64ApicWriteLint1ExitTrap : 1; // WHvRunVpExitReasonX64ApicWriteTrap >> UINT64 X64ApicWriteSvrExitTrap : 1; // WHvRunVpExitReasonX64ApicWriteTrap > > > There's no need for this in KVM's in-kernel APIC model. INIT and SIPI are handled in the hypervisor and you can get the current state of APs via KVM_GET_MPSTATE. LINT0 and LINT1 are injected with KVM_INTERRUPT and KVM_NMI respectively, and they obey IF/PPR and NMI blocking respectively, plus the interrupt shadow; so there's no need for userspace to know when LINT0/LINT1 themselves change. The spurious interrupt vector register is also handled completely in kernel. I realize that KVM can handle LINT0/SVR updates themselves but our interrupt subsystem relies on knowing the current values of these registers even when not virtualizing the local APIC. I suppose we could use KVM_GET_LAPIC to sync things up on demand but that seems like it might nor be great from a performance point of view. >> I did not see any similar functionality for KVM. Does anything like that exist? >> In any case we would be happy to add support for handling CR8 accesses w/o >> exiting w/o the in-kernel APIC along with some sort of a way to configure the >> TPR threshold if folks are not opposed to that. > > > As far I know everybody who's using KVM (whether proprietary or open source) has had no need for that, so I don't think it's a good idea to make the API more complex. Performance of Windows guests is going to be bad anyway with userspace APIC. From what I have seen the exit cost with KVM is significantly lower than with WHP/Hyper-V. I don't think performance of Windows guests with userspace APIC emulation would be bad if CR8 exits could be avoided (Linux guests perf isn't bad from what I have observed and the main difference is the astronomical number of CR8 exits). It seems like it would be pretty decent although I agree if you want the absolute best performance then you would want to use the in kernel APIC to speed up handling of ICR/EOI writes but those are relatively infrequent compared to CR8 accesses . Anyway I just saw Sean's response while writing this and it seems he is not in favor of avoiding CR8 exits w/o the in kernel APIC either so I suppose we will have to look into making use of the in kernel APIC. Doug > Paolo > >> Doug >> >> > > For now I think it makes sense to handle BDOOR_CMD_GET_VCPU_INFO at userlevel >> > > like we do on Windows and macOS. >> > > >> > > BDOOR_CMD_GETTIME/BDOOR_CMD_GETTIMEFULL are similar with the former being >> > > deprecated in favor of the latter. Both do essentially the same thing which is >> > > to return the host OS's time - on Linux this is obtained via gettimeofday. I >> > > believe this is mainly used by tools to fix up the VM's time when resuming from >> > > suspend. I think it is fine to continue handling these at userlevel. >> > >> > As long as the TSC is not involved it should be okay. >> > >> > Paolo >> > >> > > > >> Anyway, one question apart from this: is the API the same for the I/O >> > > > >> port and hypercall backdoors? >> > > > > >> > > > > Yeah the calls and arguments are the same. The hypercall based >> > > > > interface is an attempt to modernize the backdoor since as you pointed >> > > > > out the I/O based interface is kind of hacky as it bypasses the normal >> > > > > checks for an I/O port access at CPL3. It would be nice to get rid of >> > > > > it but unfortunately I don't think that will happen in the foreseeable >> > > > > future as there are a lot of existing VMs out there with older SW that >> > > > > still uses this interface. >> > > > >> > > > Yeah, but I think it still justifies that the KVM_ENABLE_CAP API can >> > > > enable the hypercall but not the I/O port. >> > > > >> > > > Paolo >> > >> >> -- >> This electronic communication and the information and any files transmitted >> with it, or attached to it, are confidential and are intended solely for >> the use of the individual or entity to whom it is addressed and may contain >> information that is confidential, legally privileged, protected by privacy >> laws, or otherwise restricted from disclosure to anyone else. If you are >> not the intended recipient or the person responsible for delivering the >> e-mail to the intended recipient, you are hereby notified that any use, >> copying, distributing, dissemination, forwarding, printing, or copying of >> this e-mail is strictly prohibited. If you received this e-mail in error, >> please return the e-mail to the sender, delete it from your computer, and >> destroy any printed copy of it. >> -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

9 hours, 32 minutes

3
5
0 0

[PATCH bpf-next v4 3/4] net: stmmac: Add launch time support to XDP ZC

by Song Yoong Siang

Enable launch time (Time-Based Scheduling) support to XDP zero copy via XDP Tx metadata framework. This patch is tested with tools/testing/selftests/bpf/xdp_hw_metadata on Intel Tiger Lake platform. Below are the test steps and result. Test Steps: 1. Add mqprio qdisc: $ sudo tc qdisc add dev enp0s30f4 handle 8001: parent root mqprio num_tc 4 map 0 1 2 3 3 3 3 3 3 3 3 3 3 3 3 3 queues 1@0 1@1 1@2 1@3 hw 0 2. Enable launch time hardware offload on hardware queue 1: $ sudo tc qdisc replace dev enp0s30f4 parent 8001:2 etf offload clockid CLOCK_TAI delta 500000 3. Add an ingress qdisc: $ sudo tc qdisc add dev enp0s30f4 ingress 4. Add a flower filter to route incoming packet with VLAN priority 1 into hardware queue 1: $ sudo tc filter add dev enp0s30f4 parent ffff: protocol 802.1Q flower vlan_prio 1 hw_tc 1 5. Enable VLAN tag stripping: $ sudo ethtool -K enp0s30f4 rxvlan on 6. Start xdp_hw_metadata selftest application: $ sudo ./xdp_hw_metadata enp0s30f4 -l 1000000000 7. Send an UDP packet with VLAN priority 1 to port 9091 of DUT. When launch time is set to 1s in the future, the delta between launch time and transmit hardware timestamp is equal to 16.963us, as shown in result below: 0x55b5864717a8: rx_desc[4]->addr=88100 addr=88100 comp_addr=88100 EoP No rx_hash, err=-95 HW RX-time: 1734579065767717328 (sec:1734579065.7677) delta to User RX-time sec:0.0004 (375.624 usec) XDP RX-time: 1734579065768004454 (sec:1734579065.7680) delta to User RX-time sec:0.0001 (88.498 usec) No rx_vlan_tci or rx_vlan_proto, err=-95 0x55b5864717a8: ping-pong with csum=5619 (want 0000) csum_start=34 csum_offset=6 HW RX-time: 1734579065767717328 (sec:1734579065.7677) delta to HW Launch-time sec:1.0000 (1000000.000 usec) 0x55b5864717a8: complete tx idx=4 addr=4018 HW Launch-time: 1734579066767717328 (sec:1734579066.7677) delta to HW TX-complete-time sec:0.0000 (16.963 usec) HW TX-complete-time: 1734579066767734291 (sec:1734579066.7677) delta to User TX-complete-time sec:0.0001 (130.408 usec) XDP RX-time: 1734579065768004454 (sec:1734579065.7680) delta to User TX-complete-time sec:0.9999 (999860.245 usec) HW RX-time: 1734579065767717328 (sec:1734579065.7677) delta to HW TX-complete-time sec:1.0000 (1000016.963 usec) 0x55b5864717a8: complete rx idx=132 addr=88100 Signed-off-by: Song Yoong Siang <yoong.siang.song(a)intel.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 ++ drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 +++++++++++++ 2 files changed, 15 insertions(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h index 1d86439b8a14..c80462d42989 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h @@ -106,6 +106,8 @@ struct stmmac_metadata_request { struct stmmac_priv *priv; struct dma_desc *tx_desc; bool *set_ic; + struct dma_edesc *edesc; + int tbs; }; struct stmmac_xsk_tx_complete { diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index c81ea8cdfe6e..3a083e3684ed 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -2445,9 +2445,20 @@ static u64 stmmac_xsk_fill_timestamp(void *_priv) return 0; } +static void stmmac_xsk_request_launch_time(u64 launch_time, void *_priv) +{ + struct stmmac_metadata_request *meta_req = _priv; + struct timespec64 ts = ns_to_timespec64(launch_time); + + if (meta_req->tbs & STMMAC_TBS_EN) + stmmac_set_desc_tbs(meta_req->priv, meta_req->edesc, ts.tv_sec, + ts.tv_nsec); +} + static const struct xsk_tx_metadata_ops stmmac_xsk_tx_metadata_ops = { .tmo_request_timestamp = stmmac_xsk_request_timestamp, .tmo_fill_timestamp = stmmac_xsk_fill_timestamp, + .tmo_request_launch_time = stmmac_xsk_request_launch_time, }; static bool stmmac_xdp_xmit_zc(struct stmmac_priv *priv, u32 queue, u32 budget) @@ -2531,6 +2542,8 @@ static bool stmmac_xdp_xmit_zc(struct stmmac_priv *priv, u32 queue, u32 budget) meta_req.priv = priv; meta_req.tx_desc = tx_desc; meta_req.set_ic = &set_ic; + meta_req.tbs = tx_q->tbs; + meta_req.edesc = &tx_q->dma_entx[entry]; xsk_tx_metadata_request(meta, &stmmac_xsk_tx_metadata_ops, &meta_req); if (set_ic) { -- 2.34.1

9 hours, 34 minutes

2
1
0 0

[PATCH 00/14] pkeys kselftests improvements

by Kevin Brodsky

This series brings various cleanups and fixes for the mm (mostly pkeys) kselftests. The original goal was to make the pkeys tests work out of the box and without build warning - it turned out to be more involved than expected. The most important change is enabling -O2 when building all mm kselftests (patch 5). This is actually needed for the pkeys tests to run successfully (see gcc command line at the top of protection_keys.c and pkey_sighandler_tests.c), and seems to have no negative impact on the other tests. It certainly can't hurt performance! The following patches address a few obvious issues in the pkeys tests (unused code, bad scope for functions/variables, etc.) and finally make a couple of small improvements. There is one ugliness that this series does not fix: some functions in pkey-<arch>.h call functions that are actually defined in protection_keys.c. For instance, expect_fault_on_read_execonly_key() in pkey-x86.h calls expected_pkey_fault(). This means that other test programs that use pkey-helpers.h (namely pkey_sighandler_tests) would fail to link if they called such functions defined in pkey-<arch>.h. Fixing this would require a more comprehensive reorganisation of the pkey-* headers, which doesn't seem worth it (patch 9 adds a comment to pkey-helpers.h to clarify the situation). Some more details on the patches: - Patch 1 is an unrelated fix that was revealed by inspecting a warning. It seems fairly harmless though, so I thought I'd just post it as part of this series. - Patch 2-5 fix various warnings that come up by building the mm tests at -O2 and finally enable -O2. - Patch 6-12 are various cleanups for the pkeys tests. Patch 11 in particular enables is_pkeys_supported() to be called from outside protection_keys.c (patch 13 relies on this). - Patch 13-14 are small improvements to pkey_sighandler_tests.c. Many thanks to Ryan Roberts for checking that the mm tests still run fine on arm64 with those patches applied. I've also checked that the pkeys tests run fine on arm64 and x86. - Kevin --- Cc: akpm(a)linux-foundation.org Cc: aruna.ramakrishna(a)oracle.com Cc: catalin.marinas(a)arm.com Cc: dave.hansen(a)linux.intel.com Cc: joey.gouly(a)arm.com Cc: keith.lucas(a)oracle.com Cc: ryan.roberts(a)arm.com Cc: shuah(a)kernel.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kselftest(a)vger.kernel.org Cc: x86(a)kernel.org --- Kevin Brodsky (14): selftests/mm: Fix condition in uffd_move_test_common() selftests/mm: Fix -Wmaybe-uninitialized warnings selftests/mm: Fix strncpy() length selftests/mm: Fix -Warray-bounds warnings in pkey_sighandler_tests selftests/mm: Build with -O2 selftests/mm: Remove unused pkey helpers selftests/mm: Define types using typedef in pkey-helpers.h selftests/mm: Ensure pkey-*.h define inline functions only selftests/mm: Remove empty pkey helper definition selftests/mm: Ensure non-global pkey symbols are marked static selftests/mm: Use sys_pkey helpers consistently selftests/mm: Rename pkey register macro selftests/mm: Skip pkey_sighandler_tests if support is missing selftests/mm: Remove X permission from sigaltstack mapping tools/testing/selftests/mm/Makefile | 6 +- tools/testing/selftests/mm/ksm_tests.c | 2 +- tools/testing/selftests/mm/mremap_test.c | 2 +- tools/testing/selftests/mm/pkey-arm64.h | 6 +- tools/testing/selftests/mm/pkey-helpers.h | 61 ++--- tools/testing/selftests/mm/pkey-powerpc.h | 4 +- tools/testing/selftests/mm/pkey-x86.h | 6 +- .../selftests/mm/pkey_sighandler_tests.c | 32 +-- tools/testing/selftests/mm/pkey_util.c | 40 ++++ tools/testing/selftests/mm/protection_keys.c | 212 +++++++----------- tools/testing/selftests/mm/soft-dirty.c | 2 +- tools/testing/selftests/mm/uffd-unit-tests.c | 4 +- .../testing/selftests/mm/write_to_hugetlbfs.c | 2 +- 13 files changed, 163 insertions(+), 216 deletions(-) create mode 100644 tools/testing/selftests/mm/pkey_util.c -- 2.47.0

9 hours, 41 minutes

2
18
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror January 2025