January 2025 - Linux-kselftest-mirror

[PATCH v7 0/6] introduce PIDFD_SELF* sentinels

by Lorenzo Stoakes

If you wish to utilise a pidfd interface to refer to the current process or thread it is rather cumbersome, requiring something like: int pidfd = pidfd_open(getpid(), 0 or PIDFD_THREAD); ... close(pidfd); Or the equivalent call opening /proc/self. It is more convenient to use a sentinel value to indicate to an interface that accepts a pidfd that we simply wish to refer to the current process thread. This series introduces sentinels for this purposes which can be passed as the pidfd in this instance rather than having to establish a dummy fd for this purpose. It is useful to refer to both the current thread from the userland's perspective for which we use PIDFD_SELF, and the current process from the userland's perspective, for which we use PIDFD_SELF_PROCESS. There is unfortunately some confusion between the kernel and userland as to what constitutes a process - a thread from the userland perspective is a process in userland, and a userland process is a thread group (more specifically the thread group leader from the kernel perspective). We therefore alias things thusly: * PIDFD_SELF_THREAD aliased by PIDFD_SELF - use PIDTYPE_PID. * PIDFD_SELF_THREAD_GROUP alised by PIDFD_SELF_PROCESS - use PIDTYPE_TGID. In all of the kernel code we refer to PIDFD_SELF_THREAD and PIDFD_SELF_THREAD_GROUP. However we expect users to use PIDFD_SELF and PIDFD_SELF_PROCESS. This matters for cases where, for instance, a user unshare()'s FDs or does thread-specific signal handling and where the user would be hugely confused if the FDs referenced or signal processed referred to the thread group leader rather than the individual thread. For now we only adjust pidfd_get_task() and the pidfd_send_signal() system call with specific handling for this, implementing this functionality for process_madvise(), process_mrelease() (albeit, using it here wouldn't really make sense) and pidfd_send_signal(). We defer making further changes, as this would require a significant rework of the pidfd mechanism. The motivating case here is to support PIDFD_SELF in process_madvise(), so this suffices for immediate uses. Moving forward, this can be further expanded to other uses. v7: * Reworked implementation according to Christian's requirements. We now only support process_madvise() and pidfd_send_signal() system calls with PIDFD_SELF as specified. * Updated tests to account for broken pidfd_open_test.c implementation. * Fixed missing includes in pidfd self tests. * Removed tests relating to functionality no longer supported. * Update guard pages test to use PIDFD_SELF. v6: * Avoid static inline in UAPI header as suggested by Pedro. * Place PIDFD_SELF values out of range of errors and any other sentinel as suggested by Pedro. https://lore.kernel.org/linux-mm/cover.1729926229.git.lorenzo.stoakes@oracl… v5: * Fixup self test dependencies on pidfd/pidfd.h. https://lore.kernel.org/linux-mm/cover.1729848252.git.lorenzo.stoakes@oracl… v4: * Avoid returning an fd in the __pidfd_get_pid() function as pointed out by Christian, instead simply always pin the pid and maintain fd scope in the helper alone. * Add wrapper header file in tools/include/linux to allow for import of UAPI pidfd.h header without encountering the collision between system fcntl.h and linux/fcntl.h as discussed with Shuah and John. * Fixup tests to import the UAPI pidfd.h header working around conflicts between system fcntl.h and linux/fcntl.h which the UAPI pidfd.h imports, as reported by Shuah. * Use an int for pidfd_is_self_sentinel() to avoid any dependency on stdbool.h in userland. https://lore.kernel.org/linux-mm/cover.1729198898.git.lorenzo.stoakes@oracl… v3: * Do not fput() an invalid fd as reported by kernel test bot. * Fix unintended churn from moving variable declaration. https://lore.kernel.org/linux-mm/cover.1729073310.git.lorenzo.stoakes@oracl… v2: * Fix tests as reported by Shuah. * Correct RFC version lore link. https://lore.kernel.org/linux-mm/cover.1728643714.git.lorenzo.stoakes@oracl… Non-RFC v1: * Removed RFC tag - there seems to be general consensus that this change is a good idea, but perhaps some debate to be had on implementation. It seems sensible then to move forward with the RFC flag removed. * Introduced PIDFD_SELF_THREAD, PIDFD_SELF_THREAD_GROUP and their aliases PIDFD_SELF and PIDFD_SELF_PROCESS respectively. * Updated testing accordingly. https://lore.kernel.org/linux-mm/cover.1728578231.git.lorenzo.stoakes@oracl… RFC version: https://lore.kernel.org/linux-mm/cover.1727644404.git.lorenzo.stoakes@oracl… Lorenzo Stoakes (6): pidfd: add PIDFD_SELF* sentinels to refer to own thread/process selftests/pidfd: add missing system header imcludes to pidfd tests tools: testing: separate out wait_for_pid() into helper header selftests: pidfd: add pidfd.h UAPI wrapper selftests: pidfd: add tests for PIDFD_SELF_* selftests/mm: use PIDFD_SELF in guard pages test include/uapi/linux/pidfd.h | 24 ++++ kernel/pid.c | 24 +++- kernel/signal.c | 106 +++++++++++------- tools/include/linux/pidfd.h | 14 +++ tools/testing/selftests/cgroup/test_kill.c | 2 +- tools/testing/selftests/mm/Makefile | 4 + tools/testing/selftests/mm/guard-pages.c | 15 +-- .../pid_namespace/regression_enomem.c | 2 +- tools/testing/selftests/pidfd/Makefile | 3 +- tools/testing/selftests/pidfd/pidfd.h | 28 +---- .../selftests/pidfd/pidfd_fdinfo_test.c | 1 + tools/testing/selftests/pidfd/pidfd_helpers.h | 39 +++++++ .../testing/selftests/pidfd/pidfd_open_test.c | 6 +- .../selftests/pidfd/pidfd_setns_test.c | 1 + tools/testing/selftests/pidfd/pidfd_test.c | 76 +++++++++++-- 15 files changed, 242 insertions(+), 103 deletions(-) create mode 100644 tools/include/linux/pidfd.h create mode 100644 tools/testing/selftests/pidfd/pidfd_helpers.h -- 2.48.1

11 hours, 6 minutes

6
17
0 0

[PATCH net-next v18 00/25] Introducing OpenVPN Data Channel Offload

by Antonio Quartulli

Notable changes since v17: * fixed netdevice_tracker pointer assignment in netlink post_doit (triggered by kernel test robot on m86k) * renamed nla_get_uint() to ovpn_nla_get_uint() in ovpn-cli.c to avoid clashes with libnl-3.11.0 FTR, here are the notable changes since v16: * fixed usage of netdev tracker by removing dev_tracker member from ovpn_priv and adding it to ovpn_peer and ovpn_socket as those are the objects really holding a ref to the netdev * switched ovpn_get_dev_from_attrs() to GFP_ATOMIC to prevent sleep under rcu_read_lock * allocated netdevice_tracker in ovpn_nl_pre_doit() [stored in user_ptr[1]] to keep track of the netdev reference held during netlink handler calls * moved whole socket detaching routine to worker. This way the code is allowed to sleep and in turn it can be executed under lock_sock. This lock allows us to happily coordinate concurrent attach/detach calls. (note: lock is acquired everytime the refcnt for the socket is decremented, because this guarantees us that setting the refcnt to 0 and detaching the socket will happen atomically) * dropped kref_put_sock()/refcount handler as it's not required anymore, thanks to the point above * re-arranged ovpn_socket_new() in order to simplify error path by first allocating the new ovpn_sock and then attaching Please note that some patches were already reviewed/tested by a few people. iThese patches have retained the tags as they have hardly been touched. The latest code can also be found at: https://github.com/OpenVPN/linux-kernel-ovpn Thanks a lot! Best Regards, Antonio Quartulli OpenVPN Inc. --- Antonio Quartulli (25): net: introduce OpenVPN Data Channel Offload (ovpn) ovpn: add basic netlink support ovpn: add basic interface creation/destruction/management routines ovpn: keep carrier always on for MP interfaces ovpn: introduce the ovpn_peer object ovpn: introduce the ovpn_socket object ovpn: implement basic TX path (UDP) ovpn: implement basic RX path (UDP) ovpn: implement packet processing ovpn: store tunnel and transport statistics ipv6: export inet6_stream_ops via EXPORT_SYMBOL_GPL ovpn: implement TCP transport skb: implement skb_send_sock_locked_with_flags() ovpn: add support for MSG_NOSIGNAL in tcp_sendmsg ovpn: implement multi-peer support ovpn: implement peer lookup logic ovpn: implement keepalive mechanism ovpn: add support for updating local UDP endpoint ovpn: add support for peer floating ovpn: implement peer add/get/dump/delete via netlink ovpn: implement key add/get/del/swap via netlink ovpn: kill key and notify userspace in case of IV exhaustion ovpn: notify userspace when a peer is deleted ovpn: add basic ethtool support testing/selftests: add test tool and scripts for ovpn module Documentation/netlink/specs/ovpn.yaml | 372 +++ Documentation/netlink/specs/rt_link.yaml | 16 + MAINTAINERS | 11 + drivers/net/Kconfig | 15 + drivers/net/Makefile | 1 + drivers/net/ovpn/Makefile | 22 + drivers/net/ovpn/bind.c | 55 + drivers/net/ovpn/bind.h | 101 + drivers/net/ovpn/crypto.c | 211 ++ drivers/net/ovpn/crypto.h | 145 ++ drivers/net/ovpn/crypto_aead.c | 382 ++++ drivers/net/ovpn/crypto_aead.h | 33 + drivers/net/ovpn/io.c | 446 ++++ drivers/net/ovpn/io.h | 34 + drivers/net/ovpn/main.c | 350 +++ drivers/net/ovpn/main.h | 14 + drivers/net/ovpn/netlink-gen.c | 213 ++ drivers/net/ovpn/netlink-gen.h | 41 + drivers/net/ovpn/netlink.c | 1183 ++++++++++ drivers/net/ovpn/netlink.h | 18 + drivers/net/ovpn/ovpnstruct.h | 54 + drivers/net/ovpn/peer.c | 1269 +++++++++++ drivers/net/ovpn/peer.h | 164 ++ drivers/net/ovpn/pktid.c | 129 ++ drivers/net/ovpn/pktid.h | 87 + drivers/net/ovpn/proto.h | 118 + drivers/net/ovpn/skb.h | 60 + drivers/net/ovpn/socket.c | 204 ++ drivers/net/ovpn/socket.h | 49 + drivers/net/ovpn/stats.c | 21 + drivers/net/ovpn/stats.h | 47 + drivers/net/ovpn/tcp.c | 565 +++++ drivers/net/ovpn/tcp.h | 33 + drivers/net/ovpn/udp.c | 421 ++++ drivers/net/ovpn/udp.h | 22 + include/linux/skbuff.h | 2 + include/uapi/linux/if_link.h | 15 + include/uapi/linux/ovpn.h | 111 + include/uapi/linux/udp.h | 1 + net/core/skbuff.c | 18 +- net/ipv6/af_inet6.c | 1 + tools/testing/selftests/Makefile | 1 + tools/testing/selftests/net/ovpn/.gitignore | 2 + tools/testing/selftests/net/ovpn/Makefile | 17 + tools/testing/selftests/net/ovpn/config | 10 + tools/testing/selftests/net/ovpn/data64.key | 5 + tools/testing/selftests/net/ovpn/ovpn-cli.c | 2367 ++++++++++++++++++++ tools/testing/selftests/net/ovpn/tcp_peers.txt | 5 + .../testing/selftests/net/ovpn/test-chachapoly.sh | 9 + tools/testing/selftests/net/ovpn/test-float.sh | 9 + tools/testing/selftests/net/ovpn/test-tcp.sh | 9 + tools/testing/selftests/net/ovpn/test.sh | 185 ++ tools/testing/selftests/net/ovpn/udp_peers.txt | 5 + 53 files changed, 9673 insertions(+), 5 deletions(-) --- base-commit: 7d0da8f862340c5f42f0062b8560b8d0971a6ac4 change-id: 20241002-b4-ovpn-eeee35c694a2 Best regards, -- Antonio Quartulli <antonio(a)openvpn.net>

12 hours, 32 minutes

3
67
0 0

[PATCH RFCv2 00/13] iommu: Add MSI mapping support with nested SMMU

by Nicolin Chen

[ Background ] On ARM GIC systems and others, the target address of the MSI is translated by the IOMMU. For GIC, the MSI address page is called "ITS" page. When the IOMMU is disabled, the MSI address is programmed to the physical location of the GIC ITS page (e.g. 0x20200000). When the IOMMU is enabled, the ITS page is behind the IOMMU, so the MSI address is programmed to an allocated IO virtual address (a.k.a IOVA), e.g. 0xFFFF0000, which must be mapped to the physical ITS page: IOVA (0xFFFF0000) ===> PA (0x20200000). When a 2-stage translation is enabled, IOVA will be still used to program the MSI address, though the mappings will be in two stages: IOVA (0xFFFF0000) ===> IPA (e.g. 0x80900000) ===> PA (0x20200000) (IPA stands for Intermediate Physical Address). If the device that generates MSI is attached to an IOMMU_DOMAIN_DMA, the IOVA is dynamically allocated from the top of the IOVA space. If attached to an IOMMU_DOMAIN_UNMANAGED (e.g. a VFIO passthrough device), the IOVA is fixed to an MSI window reported by the IOMMU driver via IOMMU_RESV_SW_MSI, which is hardwired to MSI_IOVA_BASE (IOVA==0x8000000) for ARM IOMMUs. So far, this IOMMU_RESV_SW_MSI works well as kernel is entirely in charge of the IOMMU translation (1-stage translation), since the IOVA for the ITS page is fixed and known by kernel. However, with virtual machine enabling a nested IOMMU translation (2-stage), a guest kernel directly controls the stage-1 translation with an IOMMU_DOMAIN_DMA, mapping a vITS page (at an IPA 0x80900000) onto its own IOVA space (e.g. 0xEEEE0000). Then, the host kernel can't know that guest-level IOVA to program the MSI address. There have been two approaches to solve this problem: 1. Create an identity mapping in the stage-1. VMM could insert a few RMRs (Reserved Memory Regions) in guest's IORT. Then the guest kernel would fetch these RMR entries from the IORT and create an IOMMU_RESV_DIRECT region per iommu group for a direct mapping. Eventually, the mappings would look like: IOVA (0x8000000) === IPA (0x8000000) ===> 0x20200000 This requires an IOMMUFD ioctl for kernel and VMM to agree on the IPA. 2. Forward the guest-level MSI IOVA captured by VMM to the host-level GIC driver, to program the correct MSI IOVA. Forward the VMM-defined vITS page location (IPA) to the kernel for the stage-2 mapping. Eventually: IOVA (0xFFFF0000) ===> IPA (0x80900000) ===> PA (0x20200000) This requires a VFIO ioctl (for IOVA) and an IOMMUFD ioctl (for IPA). Worth mentioning that when Eric Auger was working on the same topic with the VFIO iommu uAPI, he had the approach (2) first, and then switched to the approach (1), suggested by Jean-Philippe for reduction of complexity. The approach (1) basically feels like the existing VFIO passthrough that has a 1-stage mapping for the unmanaged domain, yet only by shifting the MSI mapping from stage 1 (guest-has-no-iommu case) to stage 2 (guest-has- iommu case). So, it could reuse the existing IOMMU_RESV_SW_MSI piece, by sharing the same idea of "VMM leaving everything to the kernel". The approach (2) is an ideal solution, yet it requires additional effort for kernel to be aware of the 1-stage gIOVA(s) and 2-stage IPAs for vITS page(s), which demands VMM to closely cooperate. * It also brings some complicated use cases to the table where the host or/and guest system(s) has/have multiple ITS pages. [ Execution ] Though these two approaches feel very different on the surface, they can share some underlying common infrastructure. Currently, only one pair of sw_msi functions (prepare/compose) are provided by dma-iommu for irqchip drivers to directly use. There could be different versions of functions from different domain owners: for existing VFIO passthrough cases and in- kernel DMA domain cases, reuse the existing dma-iommu's version of sw_msi functions; for nested translation use cases, there can be another version of sw_msi functions to handle mapping and msi_msg(s) differently. To support both approaches, in this series - Get rid of the duplication in the "compose" function - Introduce a function pointer for the previously "prepare" function - Allow different domain owners to set their own "sw_msi" implementations - Implement an iommufd_sw_msi function to additionally support a nested translation use case using the approach (2), i.e. the RMR solution - Add a pair of IOMMUFD options for a SW_MSI window for kernel and VMM to agree on (for approach 1) - Add a new VFIO ioctl to set the MSI(x) vector(s) for iommufd_sw_msi() to update the msi_desc structure accordingly (for approach 2) A missing piece - Potentially another IOMMUFD_CMD_IOAS_MAP_MSI ioctl for VMM to map the IPAs of the vITS page(s) in the stage-2 io page table. (for approach 2) (in this RFC, conveniently reuse the new IOMMUFD SW_MSI options to set the vITS page's IPA, which works finely in a single-vITS-page case.) This is a joint effort that includes Jason's rework in irq/iommu/iommufd base level and my additional patches on top of that for new uAPIs. This series is on github: https://github.com/nicolinc/iommufd/commits/iommufd_msi-rfcv2 Pairing QEMU branch for testing (approach 1): https://github.com/nicolinc/qemu/commits/wip/for_iommufd_msi-rfcv2-rmr Pairing QEMU branch for testing (approach 2): https://github.com/nicolinc/qemu/commits/wip/for_iommufd_msi-rfcv2-vits Changelog v2 * Rebase on v6.13-rc6 * Drop all the irq/pci patches and rework the compose function instead * Add a new sw_msi op to iommu_domain for a per type implementation and let iommufd core has its own implementation to support both approaches * Add RMR-solution (approach 1) support since it is straightforward and have been used in some out-of-tree projects widely v1 https://lore.kernel.org/kvm/cover.1731130093.git.nicolinc@nvidia.com/ Thanks! Nicolin Jason Gunthorpe (5): genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie genirq/msi: Rename iommu_dma_compose_msi_msg() to msi_msg_set_msi_addr() iommu: Make iommu_dma_prepare_msi() into a generic operation irqchip: Have CONFIG_IRQ_MSI_IOMMU be selected by the irqchips that need it iommufd: Implement sw_msi support natively Nicolin Chen (8): iommu: Turn fault_data to iommufd private pointer iommufd: Make attach_handle generic iommu: Turn iova_cookie to dma-iommu private pointer iommufd: Add IOMMU_OPTION_SW_MSI_START/SIZE ioctls iommufd/selftes: Add coverage for IOMMU_OPTION_SW_MSI_START/SIZE iommufd/device: Allow setting IOVAs for MSI(x) vectors vfio-iommufd: Provide another layer of msi_iova helpers vfio/pci: Allow preset MSI IOVAs via VFIO_IRQ_SET_ACTION_PREPARE drivers/iommu/Kconfig | 1 - drivers/irqchip/Kconfig | 4 + kernel/irq/Kconfig | 1 + drivers/iommu/iommufd/iommufd_private.h | 69 ++-- include/linux/iommu.h | 58 ++-- include/linux/iommufd.h | 6 + include/linux/msi.h | 43 ++- include/linux/vfio.h | 25 ++ include/uapi/linux/iommufd.h | 18 +- include/uapi/linux/vfio.h | 8 +- drivers/iommu/dma-iommu.c | 63 ++-- drivers/iommu/iommu.c | 29 ++ drivers/iommu/iommufd/device.c | 312 ++++++++++++++++-- drivers/iommu/iommufd/fault.c | 122 +------ drivers/iommu/iommufd/hw_pagetable.c | 5 +- drivers/iommu/iommufd/io_pagetable.c | 4 +- drivers/iommu/iommufd/ioas.c | 34 ++ drivers/iommu/iommufd/main.c | 15 + drivers/irqchip/irq-gic-v2m.c | 5 +- drivers/irqchip/irq-gic-v3-its.c | 13 +- drivers/irqchip/irq-gic-v3-mbi.c | 12 +- drivers/irqchip/irq-ls-scfg-msi.c | 5 +- drivers/vfio/iommufd.c | 27 ++ drivers/vfio/pci/vfio_pci_intrs.c | 46 +++ drivers/vfio/vfio_main.c | 3 + tools/testing/selftests/iommu/iommufd.c | 53 +++ .../selftests/iommu/iommufd_fail_nth.c | 14 + 27 files changed, 712 insertions(+), 283 deletions(-) -- 2.43.0

15 hours, 48 minutes

8
54
0 0

[PATCH] bpf: Fix mix-up of 4096 and page size.

by Saket Kumar Bhaskar

For platforms on powerpc architecture with a default page size greater than 4096, there was an inconsistency in fragment size calculation. This caused the BPF selftest xdp_adjust_tail/xdp_adjust_frags_tail_grow to fail on powerpc. The issue occurred because the fragment buffer size in bpf_prog_test_run_xdp() was set to 4096, while the actual data size in the fragment within the shared skb was checked against PAGE_SIZE (65536 on powerpc) in min_t, causing it to exceed 4096 and be set accordingly. This discrepancy led to an overflow when bpf_xdp_frags_increase_tail() checked for tailroom, as skb_frag_size(frag) could be greater than rxq->frag_size (when PAGE_SIZE > 4096). This commit updates the page size references to 4096 to ensure consistency and prevent overflow issues in fragment size calculations. Fixes: 1c1949982524 ("bpf: introduce frags support to bpf_prog_test_run_xdp()") Signed-off-by: Saket Kumar Bhaskar <skb99(a)linux.ibm.com> --- net/bpf/test_run.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c index 501ec4249..eb5476184 100644 --- a/net/bpf/test_run.c +++ b/net/bpf/test_run.c @@ -124,7 +124,7 @@ struct xdp_test_data { * must be updated accordingly this gets changed, otherwise BPF selftests * will fail. */ -#define TEST_XDP_FRAME_SIZE (PAGE_SIZE - sizeof(struct xdp_page_head)) +#define TEST_XDP_FRAME_SIZE (4096 - sizeof(struct xdp_page_head)) #define TEST_XDP_MAX_BATCH 256 static void xdp_test_run_init_page(netmem_ref netmem, void *arg) @@ -660,7 +660,7 @@ static void *bpf_test_init(const union bpf_attr *kattr, u32 user_size, void __user *data_in = u64_to_user_ptr(kattr->test.data_in); void *data; - if (size < ETH_HLEN || size > PAGE_SIZE - headroom - tailroom) + if (size < ETH_HLEN || size > 4096 - headroom - tailroom) return ERR_PTR(-EINVAL); if (user_size > size) @@ -1297,7 +1297,7 @@ int bpf_prog_test_run_xdp(struct bpf_prog *prog, const union bpf_attr *kattr, frag = &sinfo->frags[sinfo->nr_frags++]; data_len = min_t(u32, kattr->test.data_size_in - size, - PAGE_SIZE); + 4096); skb_frag_fill_page_desc(frag, page, 0, data_len); if (copy_from_user(page_address(page), data_in + size, -- 2.43.5

16 hours, 5 minutes

3
4
0 0

[RFC PATCH 0/4] PMU partitioning driver support

by Colton Lewis

This series introduces support in the ARM PMUv3 driver for partitioning PMU counters into two separate ranges by taking advantage of the MDCR_EL2.HPMN register field. The advantage of a partitioned PMU would be to allow KVM guests direct access to a subset of PMU functionality, greatly reducing the overhead of performance monitoring in guests. While this series could be accepted on its own merits, practically there is a lot more to be done before it will be fully useful, so I'm sending as an RFC for now. This patch is based on v6.13-rc7. It needs a small additional change after Oliver's Debug cleanups series going into 6.14, specifically this patch [1], because it changes kvm_arm_setup_mdcr_el2() to initialize HPMN from a cached value read early in the boot process instead of reading from the register. The only sensible way I can see to deal with this is returning to reading the register. [1] https://lore.kernel.org/kvmarm/20241219224116.3941496-3-oliver.upton@linux.… Colton Lewis (4): perf: arm_pmuv3: Introduce module param to partition the PMU KVM: arm64: Make guests see only counters they can access perf: arm_pmuv3: Generalize counter bitmasks perf: arm_pmuv3: Keep out of guest counter partition arch/arm/include/asm/arm_pmuv3.h | 10 ++ arch/arm64/include/asm/arm_pmuv3.h | 10 ++ arch/arm64/kvm/pmu-emul.c | 8 +- drivers/perf/arm_pmuv3.c | 113 ++++++++++++++++-- include/linux/perf/arm_pmu.h | 2 + include/linux/perf/arm_pmuv3.h | 34 +++++- .../kvm/aarch64/vpmu_counter_access.c | 2 +- 7 files changed, 160 insertions(+), 19 deletions(-) base-commit: 5bc55a333a2f7316b58edc7573e8e893f7acb532 -- 2.48.1.262.g85cc9f2d1e-goog

1 day, 7 hours

4
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.

1 day, 8 hours

3
12
0 0

[PATCH 0/6] selftests/nolibc: wire up riscv32

by Thomas Weißschuh

Nolibc has support for riscv32. But the testsuite did not allow to test it so far. Add a test configuration. Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- Thomas Weißschuh (6): tools/nolibc: add support for waitid() selftests/nolibc: use waitid() over waitpid() selftests/nolibc: use a pipe to in vfprintf tests selftests/nolibc: skip tests for unimplemented syscalls selftests/nolibc: rename riscv to riscv64 selftests/nolibc: add configurations for riscv32 tools/include/nolibc/sys.h | 18 ++++++++++++ tools/testing/selftests/nolibc/Makefile | 11 +++++++ tools/testing/selftests/nolibc/nolibc-test.c | 44 ++++++++++++++++------------ tools/testing/selftests/nolibc/run-tests.sh | 2 +- 4 files changed, 56 insertions(+), 19 deletions(-) --- base-commit: 499551201b5f4fd3c0618a3e95e3d0d15ea18f31 change-id: 20241219-nolibc-rv32-cff8a3e22394 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

1 day, 9 hours

4
12
0 0

[PATCH 1/2] misc: pci_endpoint_test: Give disabled BARs a distinct error code

by Niklas Cassel

The current code returns -ENOMEM if test->bar[barno] is NULL. There can be two reasons why test->bar[barno] is NULL: 1) The pci_ioremap_bar() call in pci_endpoint_test_probe() failed. 2) The BAR was skipped, because it is disabled by the endpoint. Many PCI endpoint controller drivers will disable all BARs in their init function. A disabled BAR will have a size of 0. A PCI endpoint function driver will be able to enable any BAR that is not marked as BAR_RESERVED (which means that the BAR should not be touched by the EPF driver). Thus, perform check if the size is 0, before checking if test->bar[barno] is NULL, such that we can return different errors. This will allow the selftests to return SKIP instead of FAIL for disabled BARs. Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- Hello PCI maintainers. This patch might give a trivial conflict with: https://lore.kernel.org/linux-pci/20250123095906.3578241-2-cassel@kernel.or… because the context lines (lines that haven't been changed) might be different. If there is a conflict, simply look at this patch by itself, and resolution should be trivial. drivers/misc/pci_endpoint_test.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c index d5ac71a49386..b95980b29eb9 100644 --- a/drivers/misc/pci_endpoint_test.c +++ b/drivers/misc/pci_endpoint_test.c @@ -292,11 +292,13 @@ static int pci_endpoint_test_bar(struct pci_endpoint_test *test, void *read_buf __free(kfree) = NULL; struct pci_dev *pdev = test->pdev; + bar_size = pci_resource_len(pdev, barno); + if (!bar_size) + return -ENODATA; + if (!test->bar[barno]) return -ENOMEM; - bar_size = pci_resource_len(pdev, barno); - if (barno == test->test_reg_bar) bar_size = 0x4; -- 2.48.1

1 day, 12 hours

2
4
0 0

[PATCH RFC net-next] netconsole: selftest: Add test for fragmented messages

by Breno Leitao

Add a new selftest to verify netconsole's handling of messages that exceed the packet size limit and require fragmentation. The test sends messages with varying sizes and userdata, validating that: 1. Large messages are correctly fragmented and reassembled 2. Userdata fields are properly preserved across fragments 3. Messages work correctly with and without kernel release version appending The test creates a networking environment using netdevsim, sends messages through /dev/kmsg, and verifies the received fragments maintain message integrity. Signed-off-by: Breno Leitao <leitao(a)debian.org> --- tools/testing/selftests/drivers/net/Makefile | 1 + .../selftests/drivers/net/lib/sh/lib_netcons.sh | 7 ++ .../drivers/net/netcons_fragmented_msg.sh | 122 +++++++++++++++++++++ 3 files changed, 130 insertions(+) diff --git a/tools/testing/selftests/drivers/net/Makefile b/tools/testing/selftests/drivers/net/Makefile index 137470bdee0c7fd2517bd1baafc12d575de4b4ac..c7f1c443f2af091aa13f67dd1df9ae05d7a43f40 100644 --- a/tools/testing/selftests/drivers/net/Makefile +++ b/tools/testing/selftests/drivers/net/Makefile @@ -7,6 +7,7 @@ TEST_INCLUDES := $(wildcard lib/py/*.py) \ TEST_PROGS := \ netcons_basic.sh \ + netcons_fragmented_msg.sh \ netcons_overflow.sh \ ping.py \ queues.py \ diff --git a/tools/testing/selftests/drivers/net/lib/sh/lib_netcons.sh b/tools/testing/selftests/drivers/net/lib/sh/lib_netcons.sh index 3acaba41ac7b21aa2fd8457ed640a5ac8a41bc12..0c262b123fdd3082c40b2bd899ec626d223226ed 100644 --- a/tools/testing/selftests/drivers/net/lib/sh/lib_netcons.sh +++ b/tools/testing/selftests/drivers/net/lib/sh/lib_netcons.sh @@ -110,6 +110,13 @@ function create_dynamic_target() { echo 1 > "${NETCONS_PATH}"/enabled } +# Do not append the release to the header of the message +function disable_release_append() { + echo 0 > "${NETCONS_PATH}"/enabled + echo 0 > "${NETCONS_PATH}"/release + echo 1 > "${NETCONS_PATH}"/enabled +} + function cleanup() { local NSIM_DEV_SYS_DEL="/sys/bus/netdevsim/del_device" diff --git a/tools/testing/selftests/drivers/net/netcons_fragmented_msg.sh b/tools/testing/selftests/drivers/net/netcons_fragmented_msg.sh new file mode 100755 index 0000000000000000000000000000000000000000..d175d5b9db662ab9a6ee203794569cc620801a4f --- /dev/null +++ b/tools/testing/selftests/drivers/net/netcons_fragmented_msg.sh @@ -0,0 +1,122 @@ +#!/usr/bin/env bash +# SPDX-License-Identifier: GPL-2.0 + +# Test netconsole's message fragmentation functionality. +# +# When a message exceeds the maximum packet size, netconsole splits it into +# multiple fragments for transmission. This test verifies: +# - Correct fragmentation of large messages +# - Proper reassembly of fragments at the receiver +# - Preservation of userdata across fragments +# - Behavior with and without kernel release version appending +# +# Author: Breno Leitao <leitao(a)debian.org> + +set -euo pipefail + +SCRIPTDIR=$(dirname "$(readlink -e "${BASH_SOURCE[0]}")") + +source "${SCRIPTDIR}"/lib/sh/lib_netcons.sh + +modprobe netdevsim 2> /dev/null || true +modprobe netconsole 2> /dev/null || true + +# The content of kmsg will be save to the following file +OUTPUT_FILE="/tmp/${TARGET}" + +# set userdata to a long value. In this case, it is "1-2-3-4...50-" +USERDATA_VALUE=$(printf -- '%.2s-' {1..60}) + +# Convert the header string in a regexp, so, we can remove +# the second header as well. +# A header looks like "13,468,514729715,-,ncfrag=0/1135;". If +# release is appended, you might find something like:L +# "6.13.0-04048-g4f561a87745a,13,468,514729715,-,ncfrag=0/1135;" +function header_to_regex() { + # header is everything before ; + local HEADER="${1}" + REGEX=$(echo "${HEADER}" | cut -d'=' -f1) + echo "${REGEX}=[0-9]*\/[0-9]*;" +} + +# We have two headers in the message. Remove both to get the full message, +# and extract the full message. +function extract_msg() { + local MSGFILE="${1}" + # Extract the header, which is the very first thing that arrives in the + # first list. + HEADER=$(sed -n '1p' "${MSGFILE}" | cut -d';' -f1) + HEADER_REGEX=$(header_to_regex "${HEADER}") + + # Remove the two headers from the received message + # This will return the message without any header, similarly to what + # was sent. + sed "s/""${HEADER_REGEX}""//g" "${MSGFILE}" +} + +# Validate the message, which has two messages glued together. +# unwrap them to make sure all the characters were transmitted. +# File will look like the following: +# 13,468,514729715,-,ncfrag=0/1135;MSG1=MSG2=MSG3=MSG4=MSG5=MSG6=MSG7=MSG8=MSG9=MSG10=MSG11=MSG12=MSG13=MSG14=MSG15=MSG16=MSG17=MSG18=MSG19=MSG20=MSG21=MSG22=MSG23=MSG24=MSG25=MSG26=MSG27=MSG28=MSG29=MSG30=MSG31=MSG32=MSG33=MSG34=MSG35=MSG36=MSG37=MSG38=MSG39=MSG40=MSG41=MSG42=MSG43=MSG44=MSG45=MSG46=MSG47=MSG48=MSG49=MSG50=MSG51=MSG52=MSG53=MSG54=MSG55=MSG56=MSG57=MSG58=MSG59=MSG60=MSG61=MSG62=MSG63=MSG64=MSG65=MSG66=MSG67=MSG68=MSG69=MSG70=MSG71=MSG72=MSG73=MSG74=MSG75=MSG76=MSG77=MSG78=MSG79=MSG80=MSG81=MSG82=MSG83=MSG84=MSG85=MSG86=MSG87=MSG88=MSG89=MSG90=MSG91=MSG92=MSG93=MSG94=MSG95=MSG96=MSG97=MSG98=MSG99=MSG100=MSG101=MSG102=MSG103=MSG104=MSG105=MSG106=MSG107=MSG108=MSG109=MSG110=MSG111=MSG112=MSG113=MSG114=MSG115=MSG116=MSG117=MSG118=MSG119=MSG120=MSG121=MSG122=MSG123=MSG124=MSG125=MSG126=MSG127=MSG128=MSG129=MSG130=MSG131=MSG132=MSG133=MSG134=MSG135=MSG136=MSG137=MSG138=MSG139=MSG140=MSG141=MSG142=MSG143=MSG144=MSG145=MSG146=MSG147=MSG148=MSG149=MSG150=: netcons_nzmJQ +# key=1-2-13,468,514729715,-,ncfrag=967/1135;3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25-26-27-28-29-30-31-32-33-34-35-36-37-38-39-40-41-42-43-44-45-46-47-48-49-50-51-52-53-54-55-56-57-58-59-60- +function validate_fragmented_result() { + # Discard the netconsole headers, and assemble the full message + RCVMSG=$(extract_msg "${1}") + + # check for the main message + if ! echo "${RCVMSG}" | grep -q "${MSG}"; then + echo "Message body doesn't match." >&2 + echo "msg received=" "${RCVMSG}" >&2 + exit "${ksft_fail}" + fi + + # check userdata + if ! echo "${RCVMSG}" | grep -q "${USERDATA_VALUE}"; then + echo "message userdata doesn't match" >&2 + echo "msg received=" "${RCVMSG}" >&2 + exit "${ksft_fail}" + fi + # test passed. hooray +} + +# Check for basic system dependency and exit if not found +check_for_dependencies +# Set current loglevel to KERN_INFO(6), and default to KERN_NOTICE(5) +echo "6 5" > /proc/sys/kernel/printk +# Remove the namespace, interfaces and netconsole target on exit +trap cleanup EXIT +# Create one namespace and two interfaces +set_network +# Create a dynamic target for netconsole +create_dynamic_target +# Set userdata "key" with the "value" value +set_user_data + + +# TEST 1: Send message and userdata. They will fragment +# ======= +MSG=$(printf -- 'MSG%.3s=' {1..150}) + +# Listen for netconsole port inside the namespace and destination interface +listen_port_and_save_to "${OUTPUT_FILE}" & +# Wait for socat to start and listen to the port. +wait_local_port_listen "${NAMESPACE}" "${PORT}" udp +# Send the message +echo "${MSG}: ${TARGET}" > /dev/kmsg +# Wait until socat saves the file to disk +busywait "${BUSYWAIT_TIMEOUT}" test -s "${OUTPUT_FILE}" +# Check if the message was not corrupted +validate_fragmented_result "${OUTPUT_FILE}" + +# TEST 2: Test with smaller message, and without release appended +# ======= +MSG=$(printf -- 'FOOBAR%.3s=' {1..100}) +# Let's disable release and test again. +disable_release_append + +listen_port_and_save_to "${OUTPUT_FILE}" & +wait_local_port_listen "${NAMESPACE}" "${PORT}" udp +echo "${MSG}: ${TARGET}" > /dev/kmsg +busywait "${BUSYWAIT_TIMEOUT}" test -s "${OUTPUT_FILE}" +validate_fragmented_result "${OUTPUT_FILE}" +exit "${ksft_pass}" --- base-commit: 0ad9617c78acbc71373fb341a6f75d4012b01d69 change-id: 20250129-netcons_frag_msgs-91506d136f50 Best regards, -- Breno Leitao <leitao(a)debian.org>

1 day, 12 hours

2
4
0 0

[PATCH bpf-next v4 00/14] selftests/bpf: Migrate test_xdp_redirect_multi.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 framework. test_xdp_redirect_multi.sh tests the XDP redirections done through bpf_redirect_map(). This is already partly covered by test_xdp_veth.c that already tests map redirections at XDP level. What isn't covered yet by test_xdp_veth is the use of the broadcast flags (BPF_F_BROADCAST or BPF_F_EXCLUDE_INGRESS) and XDP egress programs. Hence, this patch series add test cases to test_xdp_veth.c to get rid of the test_xdp_redirect_multi.sh: - PATCH 1 Add an helper to generate unique names - PATCH 2 to 9 rework test_xdp_veth to make it more generic and allow to configure different test cases - PATCH 10 adds test cases for 'classic' bpf_redirect_map() - PATCH 11 and 12 cover the broadcast flags - PATCH 13 covers the XDP egress programs - PATCH 14 removes test_xdp_redirect_multi.sh Signed-off-by: Bastien Curutchet (eBPF Foundation) <bastien.curutchet(a)bootlin.com> --- Changes in v4: - Remove the NO_IP #define - append_tid() takes string's size as input to ensure there is enough space to fit the thread ID at the end - Fix PATCH 12's commit log - Link to v3: https://lore.kernel.org/r/20250128-redirect-multi-v3-0-c1ce69997c01@bootlin… Changes in v3: - Add append_tid() helper and use unique names to allow parallel testing - Check create_network()'s return value through ASSERT_OK() - Remove check_ping() and unused defines - Change next_veth type (from string to int) - Link to v2: https://lore.kernel.org/r/20250121-redirect-multi-v2-0-fc9cacabc6b2@bootlin… Changes in v2: - Use serial_test_* to avoid conflict between tests - Link to v1: https://lore.kernel.org/r/20250121-redirect-multi-v1-0-b215e35ff505@bootlin… --- Bastien Curutchet (eBPF Foundation) (14): selftests/bpf: helpers: Add append_tid() selftests/bpf: test_xdp_veth: Remove unused defines selftests/bpf: test_xdp_veth: Remove unecessarry check_ping() selftests/bpf: test_xdp_veth: Use int to describe next veth selftests/bpf: test_xdp_veth: Split network configuration selftests/bpf: test_xdp_veth: Rename config[] selftests/bpf: test_xdp_veth: Add prog_config[] table selftests/bpf: test_xdp_veth: Add XDP flags to prog_configuration selftests/bpf: test_xdp_veth: Use unique names selftests/bpf: test_xdp_veth: Add new test cases for XDP flags selftests/bpf: Optionally select broadcasting flags selftests/bpf: test_xdp_veth: Add XDP broadcast redirection tests selftests/bpf: test_xdp_veth: Add XDP program on egress test selftests/bpf: Remove test_xdp_redirect_multi.sh tools/testing/selftests/bpf/Makefile | 2 - tools/testing/selftests/bpf/network_helpers.c | 17 + tools/testing/selftests/bpf/network_helpers.h | 12 + .../selftests/bpf/prog_tests/test_xdp_veth.c | 588 ++++++++++++++++----- .../testing/selftests/bpf/progs/xdp_redirect_map.c | 89 ++++ .../selftests/bpf/progs/xdp_redirect_multi_kern.c | 41 +- .../selftests/bpf/test_xdp_redirect_multi.sh | 214 -------- tools/testing/selftests/bpf/xdp_redirect_multi.c | 226 -------- 8 files changed, 615 insertions(+), 574 deletions(-) --- base-commit: 421ec9c8f46a25743870a8cbaff76de293752e00 change-id: 20250103-redirect-multi-245d6eafb5d1 Best regards, -- Bastien Curutchet (eBPF Foundation) <bastien.curutchet(a)bootlin.com>

1 day, 15 hours

3
16
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror January 2025