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

by Sagi Shahar

This is v12 of the TDX selftests. This series is based on v6.18-rc3 Changes from v11 [1]: - Rebased on top of v6.18-rc3. - Hook vm_tdx_finalize() into kvm_arch_vm_finalize_vcpus instead of calling it as part of vm_tdx_create_with_one_vcpu. See "KVM: selftests: Finalize TD memory as part of kvm_arch_vm_finalize_vcpus" which was added to this series. - Replaced vm_tdx_create_with_one_vcpu with vm_create_shape_with_one_vcpu following Sean's patch to simplify creating VM shapes. [1] https://lore.kernel.org/lkml/20250925172851.606193-1-sagis@google.com/ Ackerley Tng (2): KVM: selftests: Add helpers to init TDX memory and finalize VM KVM: selftests: Add ucall support for TDX Erdem Aktas (2): KVM: selftests: Add TDX boot code KVM: selftests: Add support for TDX TDCALL from guest Isaku Yamahata (2): KVM: selftests: Update kvm_init_vm_address_properties() for TDX KVM: selftests: TDX: Use KVM_TDX_CAPABILITIES to validate TDs' attribute configuration Sagi Shahar (16): KVM: selftests: Allocate pgd in virt_map() as necessary KVM: selftests: Expose functions to get default sregs values KVM: selftests: Expose function to allocate guest vCPU stack KVM: selftests: Expose segment definitons to assembly files KVM: selftests: Add kbuild definitons KVM: selftests: Define structs to pass parameters to TDX boot code KVM: selftests: Set up TDX boot code region KVM: selftests: Set up TDX boot parameters region KVM: selftests: Add helper to initialize TDX VM KVM: selftests: Call TDX init when creating a new TDX vm KVM: selftests: Setup memory regions for TDX on vm creation KVM: selftests: Call KVM_TDX_INIT_VCPU when creating a new TDX vcpu KVM: selftests: Set entry point for TDX guest code KVM: selftests: Finalize TD memory as part of kvm_arch_vm_finalize_vcpus KVM: selftests: Add wrapper for TDX MMIO from guest KVM: selftests: Add TDX lifecycle test Sean Christopherson (1): KVM: selftests: Add macros so simplify creating VM shapes for non-default types tools/include/linux/kbuild.h | 18 + tools/testing/selftests/kvm/Makefile.kvm | 32 ++ .../testing/selftests/kvm/include/kvm_util.h | 14 + .../selftests/kvm/include/ucall_common.h | 1 + .../selftests/kvm/include/x86/processor.h | 40 +++ .../selftests/kvm/include/x86/processor_asm.h | 12 + tools/testing/selftests/kvm/include/x86/sev.h | 2 - .../selftests/kvm/include/x86/tdx/td_boot.h | 74 ++++ .../kvm/include/x86/tdx/td_boot_asm.h | 16 + .../selftests/kvm/include/x86/tdx/tdcall.h | 34 ++ .../selftests/kvm/include/x86/tdx/tdx.h | 14 + .../selftests/kvm/include/x86/tdx/tdx_util.h | 84 +++++ .../testing/selftests/kvm/include/x86/ucall.h | 6 - tools/testing/selftests/kvm/lib/kvm_util.c | 10 +- .../testing/selftests/kvm/lib/x86/processor.c | 99 ++++-- tools/testing/selftests/kvm/lib/x86/sev.c | 16 - .../selftests/kvm/lib/x86/tdx/td_boot.S | 60 ++++ .../kvm/lib/x86/tdx/td_boot_offsets.c | 21 ++ .../selftests/kvm/lib/x86/tdx/tdcall.S | 93 +++++ .../kvm/lib/x86/tdx/tdcall_offsets.c | 16 + tools/testing/selftests/kvm/lib/x86/tdx/tdx.c | 23 ++ .../selftests/kvm/lib/x86/tdx/tdx_util.c | 330 ++++++++++++++++++ tools/testing/selftests/kvm/lib/x86/ucall.c | 46 ++- .../selftests/kvm/x86/sev_smoke_test.c | 40 +-- tools/testing/selftests/kvm/x86/tdx_vm_test.c | 33 ++ 25 files changed, 1056 insertions(+), 78 deletions(-) create mode 100644 tools/include/linux/kbuild.h create mode 100644 tools/testing/selftests/kvm/include/x86/processor_asm.h create mode 100644 tools/testing/selftests/kvm/include/x86/tdx/td_boot.h create mode 100644 tools/testing/selftests/kvm/include/x86/tdx/td_boot_asm.h create mode 100644 tools/testing/selftests/kvm/include/x86/tdx/tdcall.h create mode 100644 tools/testing/selftests/kvm/include/x86/tdx/tdx.h create mode 100644 tools/testing/selftests/kvm/include/x86/tdx/tdx_util.h create mode 100644 tools/testing/selftests/kvm/lib/x86/tdx/td_boot.S create mode 100644 tools/testing/selftests/kvm/lib/x86/tdx/td_boot_offsets.c create mode 100644 tools/testing/selftests/kvm/lib/x86/tdx/tdcall.S create mode 100644 tools/testing/selftests/kvm/lib/x86/tdx/tdcall_offsets.c create mode 100644 tools/testing/selftests/kvm/lib/x86/tdx/tdx.c create mode 100644 tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c create mode 100644 tools/testing/selftests/kvm/x86/tdx_vm_test.c -- 2.51.1.851.g4ebd6896fd-goog

22 minutes

5
69
0 0

[PATCH bpf-next v12 0/7] bpf: Introduce BPF_F_CPU and BPF_F_ALL_CPUS flags for percpu maps

by Leon Hwang

This patch set introduces the BPF_F_CPU and BPF_F_ALL_CPUS flags for percpu maps, as the requirement of BPF_F_ALL_CPUS flag for percpu_array maps was discussed in the thread of "[PATCH bpf-next v3 0/4] bpf: Introduce global percpu data"[1]. The goal of BPF_F_ALL_CPUS flag is to reduce data caching overhead in light skeletons by allowing a single value to be reused to update values across all CPUs. This avoids the M:N problem where M cached values are used to update a map on N CPUs kernel. The BPF_F_CPU flag is accompanied by *flags*-embedded cpu info, which specifies the target CPU for the operation: * For lookup operations: the flag field alongside cpu info enable querying a value on the specified CPU. * For update operations: the flag field alongside cpu info enable updating value for specified CPU. Links: [1] https://lore.kernel.org/bpf/20250526162146.24429-1-leon.hwang@linux.dev/ Changes: v11 -> v12: * Dropped the v11 changes. * Stabilized the lru_percpu_hash map test by keeping an extra spare entry, which can be used temporarily during updates to avoid unintended LRU evictions. v10 -> v11: * Support the combination of BPF_EXIST and BPF_F_CPU/BPF_F_ALL_CPUS for update operations. * Fix unstable lru_percpu_hash map test using the combination of BPF_EXIST and BPF_F_CPU/BPF_F_ALL_CPUS to avoid LRU eviction (reported by Alexei). v9 -> v10: * Add tests to verify array and hash maps do not support BPF_F_CPU and BPF_F_ALL_CPUS flags. * Address comment from Andrii: * Copy map value using copy_map_value_long for percpu_cgroup_storage maps in a separate patch. v8 -> v9: * Change value type from u64 to u32 in selftests. * Address comments from Andrii: * Keep value_size unaligned and update everywhere for consistency when cpu flags are specified. * Update value by getting pointer for percpu hash and percpu cgroup_storage maps. v7 -> v8: * Address comments from Andrii: * Check BPF_F_LOCK when update percpu_array, percpu_hash and lru_percpu_hash maps. * Refactor flags check in __htab_map_lookup_and_delete_batch(). * Keep value_size unaligned and copy value using copy_map_value() in __htab_map_lookup_and_delete_batch() when BPF_F_CPU is specified. * Update warn message in libbpf's validate_map_op(). * Update comment of libbpf's bpf_map__lookup_elem(). v6 -> v7: * Get correct value size for percpu_hash and lru_percpu_hash in update_batch API. * Set 'count' as 'max_entries' in test cases for lookup_batch API. * Address comment from Alexei: * Move cpu flags check into bpf_map_check_op_flags(). v5 -> v6: * Move bpf_map_check_op_flags() from 'bpf.h' to 'syscall.c'. * Address comments from Alexei: * Drop the refactoring code of data copying logic for percpu maps. * Drop bpf_map_check_op_flags() wrappers. v4 -> v5: * Address comments from Andrii: * Refactor data copying logic for all percpu maps. * Drop this_cpu_ptr() micro-optimization. * Drop cpu check in libbpf's validate_map_op(). * Enhance bpf_map_check_op_flags() using *allowed flags* instead of 'extra_flags_mask'. v3 -> v4: * Address comments from Andrii: * Remove unnecessary map_type check in bpf_map_value_size(). * Reduce code churn. * Remove unnecessary do_delete check in __htab_map_lookup_and_delete_batch(). * Introduce bpf_percpu_copy_to_user() and bpf_percpu_copy_from_user(). * Rename check_map_flags() to bpf_map_check_op_flags() with extra_flags_mask. * Add human-readable pr_warn() explanations in validate_map_op(). * Use flags in bpf_map__delete_elem() and bpf_map__lookup_and_delete_elem(). * Drop "for alignment reasons". v3 link: https://lore.kernel.org/bpf/20250821160817.70285-1-leon.hwang@linux.dev/ v2 -> v3: * Address comments from Alexei: * Use BPF_F_ALL_CPUS instead of BPF_ALL_CPUS magic. * Introduce these two cpu flags for all percpu maps. * Address comments from Jiri: * Reduce some unnecessary u32 cast. * Refactor more generic map flags check function. * A code style issue. v2 link: https://lore.kernel.org/bpf/20250805163017.17015-1-leon.hwang@linux.dev/ v1 -> v2: * Address comments from Andrii: * Embed cpu info as high 32 bits of *flags* totally. * Use ERANGE instead of E2BIG. * Few format issues. Leon Hwang (7): bpf: Introduce BPF_F_CPU and BPF_F_ALL_CPUS flags bpf: Add BPF_F_CPU and BPF_F_ALL_CPUS flags support for percpu_array maps bpf: Add BPF_F_CPU and BPF_F_ALL_CPUS flags support for percpu_hash and lru_percpu_hash maps bpf: Copy map value using copy_map_value_long for percpu_cgroup_storage maps bpf: Add BPF_F_CPU and BPF_F_ALL_CPUS flags support for percpu_cgroup_storage maps libbpf: Add BPF_F_CPU and BPF_F_ALL_CPUS flags support for percpu maps selftests/bpf: Add cases to test BPF_F_CPU and BPF_F_ALL_CPUS flags include/linux/bpf-cgroup.h | 4 +- include/linux/bpf.h | 35 +- include/uapi/linux/bpf.h | 2 + kernel/bpf/arraymap.c | 29 +- kernel/bpf/hashtab.c | 94 +++-- kernel/bpf/local_storage.c | 27 +- kernel/bpf/syscall.c | 37 +- tools/include/uapi/linux/bpf.h | 2 + tools/lib/bpf/bpf.h | 8 + tools/lib/bpf/libbpf.c | 26 +- tools/lib/bpf/libbpf.h | 21 +- .../selftests/bpf/prog_tests/percpu_alloc.c | 328 ++++++++++++++++++ .../selftests/bpf/progs/percpu_alloc_array.c | 32 ++ 13 files changed, 560 insertions(+), 85 deletions(-) -- 2.51.2

35 minutes

4
15
0 0

[PATCH net-next v7 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 v7: - selftest: use ${EXIT_STATUS} instead of ${ksft_pass} to avoid shellcheck warning - Link to v6: https://lore.kernel.org/r/20251121-netcons-retrigger-v6-0-9c03f5a2bd6f@gmai… Changes in v6: - Rebase on top of net-next to resolve conflicts, no functional changes. - Link to v5: https://lore.kernel.org/r/20251119-netcons-retrigger-v5-0-2c7dda6055d6@gmai… 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: ab084f0b8d6d2ee4b1c6a28f39a2a7430bdfa7f0 change-id: 20250816-netcons-retrigger-a4f547bfc867 Best regards, -- Andre Carvalho <asantostc(a)gmail.com>

2 hours, 32 minutes

1
5
0 0

[PATCH 1/2 net-next] ipv6: use the right ifindex when replying to icmpv6 from localhost

by Fernando Fernandez Mancera

When replying to a ICMPv6 echo request that comes from localhost address the right output ifindex is 1 (lo) and not rt6i_idev dev index. Use the skb device ifindex instead. This fixes pinging to a local address from localhost source address. $ ping6 -I ::1 2001:1:1::2 -c 3 PING 2001:1:1::2 (2001:1:1::2) from ::1 : 56 data bytes 64 bytes from 2001:1:1::2: icmp_seq=1 ttl=64 time=0.037 ms 64 bytes from 2001:1:1::2: icmp_seq=2 ttl=64 time=0.069 ms 64 bytes from 2001:1:1::2: icmp_seq=3 ttl=64 time=0.122 ms 2001:1:1::2 ping statistics 3 packets transmitted, 3 received, 0% packet loss, time 2032ms rtt min/avg/max/mdev = 0.037/0.076/0.122/0.035 ms Fixes: 1b70d792cf67 ("ipv6: Use rt6i_idev index for echo replies to a local address") Signed-off-by: Fernando Fernandez Mancera <fmancera(a)suse.de> --- net/ipv6/icmp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c index 5d2f90babaa5..5de254043133 100644 --- a/net/ipv6/icmp.c +++ b/net/ipv6/icmp.c @@ -965,7 +965,9 @@ static enum skb_drop_reason icmpv6_echo_reply(struct sk_buff *skb) fl6.daddr = ipv6_hdr(skb)->saddr; if (saddr) fl6.saddr = *saddr; - fl6.flowi6_oif = icmp6_iif(skb); + fl6.flowi6_oif = ipv6_addr_type(&fl6.daddr) & IPV6_ADDR_LOOPBACK ? + skb->dev->ifindex : + icmp6_iif(skb); fl6.fl6_icmp_type = type; fl6.flowi6_mark = mark; fl6.flowi6_uid = sock_net_uid(net, NULL); -- 2.51.1

2 hours, 35 minutes

1
1
0 0

[PATCH net-next v6 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 v6: - Rebase on top of net-next to resolve conflicts, no functional changes. - Link to v5: https://lore.kernel.org/r/20251119-netcons-retrigger-v5-0-2c7dda6055d6@gmai… 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: e2c20036a8879476c88002730d8a27f4e3c32d4b change-id: 20250816-netcons-retrigger-a4f547bfc867 Best regards, -- Andre Carvalho <asantostc(a)gmail.com>

2 hours, 54 minutes

2
9
0 0

[PATCH v3 0/1] cpuset: relax the overlap check for cgroup-v2

by Sun Shaojie

In cgroup v2, a mutual overlap check is required when at least one of two cpusets is exclusive. However, this check should be relaxed and limited to cases where both cpusets are exclusive. This patch ensures that for sibling cpusets A1 (exclusive) and B1 (non-exclusive), change B1 cannot affect A1's exclusivity. for example. Assume a machine has 4 CPUs (0-3). root cgroup / \ A1 B1 Case 1: Table 1.1: Before applying the patch Step | A1's prstate | B1'sprstate | #1> echo "0-1" > A1/cpuset.cpus | member | member | #2> echo "root" > A1/cpuset.cpus.partition | root | member | #3> echo "0" > B1/cpuset.cpus | root invalid | member | After step #3, A1 changes from "root" to "root invalid" because its CPUs (0-1) overlap with those requested by B1 (0-3). However, B1 can actually use CPUs 2-3(from B1's parent), so it would be more reasonable for A1 to remain as "root." Table 1.2: After applying the patch Step | A1's prstate | B1'sprstate | #1> echo "0-1" > A1/cpuset.cpus | member | member | #2> echo "root" > A1/cpuset.cpus.partition | root | member | #3> echo "0" > B1/cpuset.cpus | root | member | Case 2: (This situation remains unchanged from before) Table 2.1: Before applying the patch Step | A1's prstate | B1'sprstate | #1> echo "0-1" > A1/cpuset.cpus | member | member | #3> echo "1-2" > B1/cpuset.cpus | member | member | #2> echo "root" > A1/cpuset.cpus.partition | root invalid | member | Table 2.2: After applying the patch Step | A1's prstate | B1'sprstate | #1> echo "0-1" > A1/cpuset.cpus | member | member | #3> echo "1-2" > B1/cpuset.cpus | member | member | #2> echo "root" > A1/cpuset.cpus.partition | root invalid | member | All other cases remain unaffected. For example, cgroup-v1, both A1 and B1 are exclusive or non-exlusive. --- v3 -> v4: - Adjust the test_cpuset_prt.sh test file to align with the current behavior. v2 -> v3: - Ensure compliance with constraints such as cpuset.cpus.exclusive. - Link: https://lore.kernel.org/cgroups/20251113131434.606961-1-sunshaojie@kylinos.… v1 -> v2: - Keeps the current cgroup v1 behavior unchanged - Link: https://lore.kernel.org/cgroups/c8e234f4-2c27-4753-8f39-8ae83197efd3@redhat… --- kernel/cgroup/cpuset-internal.h | 3 ++ kernel/cgroup/cpuset-v1.c | 20 +++++++++ kernel/cgroup/cpuset.c | 43 ++++++++++++++----- .../selftests/cgroup/test_cpuset_prs.sh | 5 ++- 4 files changed, 58 insertions(+), 13 deletions(-) -- 2.25.1

3 hours, 11 minutes

4
33
0 0

[PATCH 00/21] vfio/pci: Base support to preserve a VFIO device file across Live Update

by David Matlack

This series adds the base support to preserve a VFIO device file across a Live Update. "Base support" means that this allows userspace to safetly preserve a VFIO device file with LIVEUPDATE_SESSION_PRESERVE_FD and retrieve a preserved VFIO device file with LIVEUPDATE_SESSION_RETRIEVE_FD, but the device itself is not preserved in a fully running state across Live Update. This series unblocks 2 parallel but related streams of work: - iommufd preservation across Live Update. This work spans iommufd, the IOMMU subsystem, and IOMMU drivers [1] - Preservation of VFIO device state across Live Update (config space, BAR addresses, power state, SR-IOV state, etc.). This work spans both VFIO and the core PCI subsystem. While we need all of the above to fully preserve a VFIO device across a Live Update without disrupting the workload on the device, this series aims to be functional and safe enough to merge as the first incremental step toward that goal. Areas for Discussion -------------------- BDF Stability across Live Update The PCI support for tracking preserved devices across a Live Update to prevent auto-probing relies on PCI segment numbers and BDFs remaining stable. For now I have disallowed VFs, as the BDFs assigned to VFs can vary depending on how the kernel chooses to allocate bus numbers. For non-VFs I am wondering if there is any more needed to ensure BDF stability across Live Update. While we would like to support many different systems and configurations in due time (including preserving VFs), I'd like to keep this first serses constrained to simple use-cases. FLB Locking I don't see a way to properly synchronize pci_flb_finish() with pci_liveupdate_incoming_is_preserved() since the incoming FLB mutex is dropped by liveupdate_flb_get_incoming() when it returns the pointer to the object, and taking pci_flb_incoming_lock in pci_flb_finish() could result in a deadlock due to reversing the lock ordering. FLB Retrieving The first patch of this series includes a fix to prevent an FLB from being retrieved again it is finished. I am wondering if this is the right approach or if subsystems are expected to stop calling liveupdate_flb_get_incoming() after an FLB is finished. Testing ------- The patches at the end of this series provide comprehensive selftests for the new code added by this series. The selftests have been validated in both a VM environment using a virtio-net PCIe device, and in a baremetal environment on an Intel EMR server with an Intel DSA device. Here is an example of how to run the new selftests: vfio_pci_liveupdate_uapi_test: $ tools/testing/selftests/vfio/scripts/setup.sh 0000:00:04.0 $ tools/testing/selftests/vfio/vfio_pci_liveupdate_uapi_test 0000:00:04.0 $ tools/testing/selftests/vfio/scripts/cleanup.sh vfio_pci_liveupdate_kexec_test: $ tools/testing/selftests/vfio/scripts/setup.sh 0000:00:04.0 $ tools/testing/selftests/vfio/vfio_pci_liveupdate_kexec_test --stage 1 0000:00:04.0 $ kexec [...] # NOTE: distro-dependent $ tools/testing/selftests/vfio/scripts/setup.sh 0000:00:04.0 $ tools/testing/selftests/vfio/vfio_pci_liveupdate_kexec_test --stage 2 0000:00:04.0 $ tools/testing/selftests/vfio/scripts/cleanup.sh Dependencies ------------ This series was constructed on top of several in-flight series and on top of mm-nonmm-unstable [2]. +-- This series | +-- [PATCH v2 00/18] vfio: selftests: Support for multi-device tests | https://lore.kernel.org/kvm/20251112192232.442761-1-dmatlack@google.com/ | +-- [PATCH v3 0/4] vfio: selftests: update DMA mapping tests to use queried IOVA ranges | https://lore.kernel.org/kvm/20251111-iova-ranges-v3-0-7960244642c5@fb.com/ | +-- [PATCH v8 0/2] Live Update: File-Lifecycle-Bound (FLB) State | https://lore.kernel.org/linux-mm/20251125225006.3722394-1-pasha.tatashin@so… | +-- [PATCH v8 00/18] Live Update Orchestrator | https://lore.kernel.org/linux-mm/20251125165850.3389713-1-pasha.tatashin@so… | To simplify checking out the code, this series can be found on GitHub: https://github.com/dmatlack/linux/tree/liveupdate/vfio/cdev/v1 Changelog --------- v1: - Rebase series on top of LUOv8 and VFIO selftests improvements - Drop commits to preserve config space fields across Live Update. These changes require changes to the PCI layer. For exmaple, preserving rbars could lead to an inconsistent device state until device BARs addresses are preserved across Live Update. - Drop commits to preserve Bus Master Enable on the device. There's no reason to preserve this until iommufd preservation is fully working. Furthermore, preserving Bus Master Enable could lead to memory corruption when the device if the device is bound to the default identity-map domain after Live Update. - Drop commits to preserve saved PCI state. This work is not needed until we are ready to preserve the device's config space, and requires more thought to make the PCI state data layout ABI-friendly. - Add support to skip auto-probing devices that are preserved by VFIO to avoid them getting bound to a different driver by the next kernel. - Restrict device preservation further (no VFs, no intel-graphics). - Various refactoring and small edits to improve readability and eliminate code duplication. rfc: https://lore.kernel.org/kvm/20251018000713.677779-1-vipinsh@google.com/ Cc: Saeed Mahameed <saeedm(a)nvidia.com> Cc: Adithya Jayachandran <ajayachandra(a)nvidia.com> Cc: Jason Gunthorpe <jgg(a)nvidia.com> Cc: Parav Pandit <parav(a)nvidia.com> Cc: Leon Romanovsky <leonro(a)nvidia.com> Cc: William Tu <witu(a)nvidia.com> Cc: Jacob Pan <jacob.pan(a)linux.microsoft.com> Cc: Lukas Wunner <lukas(a)wunner.de> Cc: Pasha Tatashin <pasha.tatashin(a)soleen.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Pratyush Yadav <pratyush(a)kernel.org> Cc: Samiullah Khawaja <skhawaja(a)google.com> Cc: Chris Li <chrisl(a)kernel.org> Cc: Josh Hilke <jrhilke(a)google.com> Cc: David Rientjes <rientjes(a)google.com> [1] https://lore.kernel.org/linux-iommu/20250928190624.3735830-1-skhawaja@googl… [2] https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/log/?h=mm-nonmm… David Matlack (12): liveupdate: luo_flb: Prevent retrieve() after finish() PCI: Add API to track PCI devices preserved across Live Update PCI: Require driver_override for incoming Live Update preserved devices vfio/pci: Notify PCI subsystem about devices preserved across Live Update vfio: Enforce preserved devices are retrieved via LIVEUPDATE_SESSION_RETRIEVE_FD vfio/pci: Store Live Update state in struct vfio_pci_core_device vfio: selftests: Add Makefile support for TEST_GEN_PROGS_EXTENDED vfio: selftests: Add vfio_pci_liveupdate_uapi_test vfio: selftests: Expose iommu_modes to tests vfio: selftests: Expose low-level helper routines for setting up struct vfio_pci_device vfio: selftests: Verify that opening VFIO device fails during Live Update vfio: selftests: Add continuous DMA to vfio_pci_liveupdate_kexec_test Vipin Sharma (9): vfio/pci: Register a file handler with Live Update Orchestrator vfio/pci: Preserve vfio-pci device files across Live Update vfio/pci: Retrieve preserved device files after Live Update vfio/pci: Skip reset of preserved device after Live Update selftests/liveupdate: Move luo_test_utils.* into a reusable library selftests/liveupdate: Add helpers to preserve/retrieve FDs vfio: selftests: Build liveupdate library in VFIO selftests vfio: selftests: Initialize vfio_pci_device using a VFIO cdev FD vfio: selftests: Add vfio_pci_liveupdate_kexec_test MAINTAINERS | 1 + drivers/pci/Makefile | 1 + drivers/pci/liveupdate.c | 248 ++++++++++++++++ drivers/pci/pci-driver.c | 12 +- drivers/vfio/device_cdev.c | 25 +- drivers/vfio/group.c | 9 + drivers/vfio/pci/Makefile | 1 + drivers/vfio/pci/vfio_pci.c | 11 +- drivers/vfio/pci/vfio_pci_core.c | 23 +- drivers/vfio/pci/vfio_pci_liveupdate.c | 278 ++++++++++++++++++ drivers/vfio/pci/vfio_pci_priv.h | 16 + drivers/vfio/vfio.h | 13 - drivers/vfio/vfio_main.c | 22 +- include/linux/kho/abi/pci.h | 53 ++++ include/linux/kho/abi/vfio_pci.h | 45 +++ include/linux/liveupdate.h | 3 + include/linux/pci.h | 38 +++ include/linux/vfio.h | 51 ++++ include/linux/vfio_pci_core.h | 7 + kernel/liveupdate/luo_flb.c | 4 + tools/testing/selftests/liveupdate/.gitignore | 1 + tools/testing/selftests/liveupdate/Makefile | 14 +- .../include/libliveupdate.h} | 11 +- .../selftests/liveupdate/lib/libliveupdate.mk | 20 ++ .../{luo_test_utils.c => lib/liveupdate.c} | 43 ++- .../selftests/liveupdate/luo_kexec_simple.c | 2 +- .../selftests/liveupdate/luo_multi_session.c | 2 +- tools/testing/selftests/vfio/Makefile | 23 +- .../vfio/lib/include/libvfio/iommu.h | 2 + .../lib/include/libvfio/vfio_pci_device.h | 8 + tools/testing/selftests/vfio/lib/iommu.c | 4 +- .../selftests/vfio/lib/vfio_pci_device.c | 60 +++- .../vfio/vfio_pci_liveupdate_kexec_test.c | 255 ++++++++++++++++ .../vfio/vfio_pci_liveupdate_uapi_test.c | 93 ++++++ 34 files changed, 1313 insertions(+), 86 deletions(-) create mode 100644 drivers/pci/liveupdate.c create mode 100644 drivers/vfio/pci/vfio_pci_liveupdate.c create mode 100644 include/linux/kho/abi/pci.h create mode 100644 include/linux/kho/abi/vfio_pci.h rename tools/testing/selftests/liveupdate/{luo_test_utils.h => lib/include/libliveupdate.h} (80%) create mode 100644 tools/testing/selftests/liveupdate/lib/libliveupdate.mk rename tools/testing/selftests/liveupdate/{luo_test_utils.c => lib/liveupdate.c} (89%) create mode 100644 tools/testing/selftests/vfio/vfio_pci_liveupdate_kexec_test.c create mode 100644 tools/testing/selftests/vfio/vfio_pci_liveupdate_uapi_test.c -- 2.52.0.487.g5c8c507ade-goog

3 hours, 19 minutes

1
21
0 0

[PATCH v8 00/29] KVM: arm64: Implement support for SME

by Mark Brown

I've removed the RFC tag from this version of the series, but the items that I'm looking for feedback on remains the same: - The userspace ABI, in particular: - The vector length used for the SVE registers, access to the SVE registers and access to ZA and (if available) ZT0 depending on the current state of PSTATE.{SM,ZA}. - The use of a single finalisation for both SVE and SME. - The addition of control for enabling fine grained traps in a similar manner to FGU but without the UNDEF, I'm not clear if this is desired at all and at present this requires symmetric read and write traps like FGU. That seemed like it might be desired from an implementation point of view but we already have one case where we enable an asymmetric trap (for ARM64_WORKAROUND_AMPERE_AC03_CPU_38) and it seems generally useful to enable asymmetrically. This series implements support for SME use in non-protected KVM guests. Much of this is very similar to SVE, the main additional challenge that SME presents is that it introduces a new vector length similar to the SVE vector length and two new controls which change the registers seen by guests: - PSTATE.ZA enables the ZA matrix register and, if SME2 is supported, the ZT0 LUT register. - PSTATE.SM enables streaming mode, a new floating point mode which uses the SVE register set with the separately configured SME vector length. In streaming mode implementation of the FFR register is optional. It is also permitted to build systems which support SME without SVE, in this case when not in streaming mode no SVE registers or instructions are available. Further, there is no requirement that there be any overlap in the set of vector lengths supported by SVE and SME in a system, this is expected to be a common situation in practical systems. Since there is a new vector length to configure we introduce a new feature parallel to the existing SVE one with a new pseudo register for the streaming mode vector length. Due to the overlap with SVE caused by streaming mode rather than finalising SME as a separate feature we use the existing SVE finalisation to also finalise SME, a new define KVM_ARM_VCPU_VEC is provided to help make user code clearer. Finalising SVE and SME separately would introduce complication with register access since finalising SVE makes the SVE registers writeable by userspace and doing multiple finalisations results in an error being reported. Dealing with a state where the SVE registers are writeable due to one of SVE or SME being finalised but may have their VL changed by the other being finalised seems like needless complexity with minimal practical utility, it seems clearer to just express directly that only one finalisation can be done in the ABI. Access to the floating point registers follows the architecture: - When both SVE and SME are present: - If PSTATE.SM == 0 the vector length used for the Z and P registers is the SVE vector length. - If PSTATE.SM == 1 the vector length used for the Z and P registers is the SME vector length. - If only SME is present: - If PSTATE.SM == 0 the Z and P registers are inaccessible and the floating point state accessed via the encodings for the V registers. - If PSTATE.SM == 1 the vector length used for the Z and P registers - The SME specific ZA and ZT0 registers are only accessible if SVCR.ZA is 1. The VMM must understand this, in particular when loading state SVCR should be configured before other state. It should be noted that while the architecture refers to PSTATE.SM and PSTATE.ZA these PSTATE bits are not preserved in SPSR_ELx, they are only accessible via SVCR. There are a large number of subfeatures for SME, most of which only offer additional instructions but some of which (SME2 and FA64) add architectural state. These are configured via the ID registers as per usual. Protected KVM supported, with the implementation maintaining the existing restriction that the hypervisor will refuse to run if streaming mode or ZA is enabled. This both simplfies the code and avoids the need to allocate storage for host ZA and ZT0 state, there seems to be little practical use case for supporting this and the memory usage would be non-trivial. The new KVM_ARM_VCPU_VEC feature and ZA and ZT0 registers have not been added to the get-reg-list selftest, the idea of supporting additional features there without restructuring the program to generate all possible feature combinations has been rejected. I will post a separate series which does that restructuring. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Changes in v8: - Small fixes in ABI documentation. - Link to v7: https://lore.kernel.org/r/20250822-kvm-arm64-sme-v7-0-7a65d82b8b10@kernel.o… Changes in v7: - Rebase onto v6.17-rc1. - Handle SMIDR_EL1 as a VM wide ID register and use this in feat_sme_smps(). - Expose affinity fields in SMIDR_EL1. - Remove SMPRI_EL1 from vcpu_sysreg, the value is always 0 currently. - Prevent userspace writes to SMPRIMAP_EL2. - Link to v6: https://lore.kernel.org/r/20250625-kvm-arm64-sme-v6-0-114cff4ffe04@kernel.o… Changes in v6: - Rebase onto v6.16-rc3. - Link to v5: https://lore.kernel.org/r/20250417-kvm-arm64-sme-v5-0-f469a2d5f574@kernel.o… Changes in v5: - Rebase onto v6.15-rc2. - Add pKVM guest support. - Always restore SVCR. - Link to v4: https://lore.kernel.org/r/20250214-kvm-arm64-sme-v4-0-d64a681adcc2@kernel.o… Changes in v4: - Rebase onto v6.14-rc2 and Mark Rutland's fixes. - Expose SME to nested guests. - Additional cleanups and test fixes following on from the rebase. - Flush register state on VMM PSTATE.{SM,ZA}. - Link to v3: https://lore.kernel.org/r/20241220-kvm-arm64-sme-v3-0-05b018c1ffeb@kernel.o… Changes in v3: - Rebase onto v6.12-rc2. - Link to v2: https://lore.kernel.org/r/20231222-kvm-arm64-sme-v2-0-da226cb180bb@kernel.o… Changes in v2: - Rebase onto v6.7-rc3. - Configure subfeatures based on host system only. - Complete nVHE support. - There was some snafu with sending v1 out, it didn't make it to the lists but in case it hit people's inboxes I'm sending as v2. --- Mark Brown (29): arm64/sysreg: Update SMIDR_EL1 to DDI0601 2025-06 arm64/fpsimd: Update FA64 and ZT0 enables when loading SME state arm64/fpsimd: Decide to save ZT0 and streaming mode FFR at bind time arm64/fpsimd: Check enable bit for FA64 when saving EFI state arm64/fpsimd: Determine maximum virtualisable SME vector length KVM: arm64: Introduce non-UNDEF FGT control KVM: arm64: Pay attention to FFR parameter in SVE save and load KVM: arm64: Pull ctxt_has_ helpers to start of sysreg-sr.h KVM: arm64: Move SVE state access macros after feature test macros KVM: arm64: Rename SVE finalization constants to be more general KVM: arm64: Document the KVM ABI for SME KVM: arm64: Define internal features for SME KVM: arm64: Rename sve_state_reg_region KVM: arm64: Store vector lengths in an array KVM: arm64: Implement SME vector length configuration KVM: arm64: Support SME control registers KVM: arm64: Support TPIDR2_EL0 KVM: arm64: Support SME identification registers for guests KVM: arm64: Support SME priority registers KVM: arm64: Provide assembly for SME register access KVM: arm64: Support userspace access to streaming mode Z and P registers KVM: arm64: Flush register state on writes to SVCR.SM and SVCR.ZA KVM: arm64: Expose SME specific state to userspace KVM: arm64: Context switch SME state for guests KVM: arm64: Handle SME exceptions KVM: arm64: Expose SME to nested guests KVM: arm64: Provide interface for configuring and enabling SME for guests KVM: arm64: selftests: Add SME system registers to get-reg-list KVM: arm64: selftests: Add SME to set_id_regs test Documentation/virt/kvm/api.rst | 115 ++++++++--- arch/arm64/include/asm/fpsimd.h | 26 +++ arch/arm64/include/asm/kvm_emulate.h | 6 + arch/arm64/include/asm/kvm_host.h | 169 ++++++++++++--- arch/arm64/include/asm/kvm_hyp.h | 5 +- arch/arm64/include/asm/kvm_pkvm.h | 2 +- arch/arm64/include/asm/vncr_mapping.h | 2 + arch/arm64/include/uapi/asm/kvm.h | 33 +++ arch/arm64/kernel/cpufeature.c | 2 - arch/arm64/kernel/fpsimd.c | 89 ++++---- arch/arm64/kvm/arm.c | 10 + arch/arm64/kvm/config.c | 8 +- arch/arm64/kvm/fpsimd.c | 28 ++- arch/arm64/kvm/guest.c | 252 ++++++++++++++++++++--- arch/arm64/kvm/handle_exit.c | 14 ++ arch/arm64/kvm/hyp/fpsimd.S | 28 ++- arch/arm64/kvm/hyp/include/hyp/switch.h | 175 ++++++++++++++-- arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 110 ++++++---- arch/arm64/kvm/hyp/nvhe/hyp-main.c | 86 ++++++-- arch/arm64/kvm/hyp/nvhe/pkvm.c | 85 ++++++-- arch/arm64/kvm/hyp/nvhe/switch.c | 4 +- arch/arm64/kvm/hyp/nvhe/sys_regs.c | 6 + arch/arm64/kvm/hyp/vhe/switch.c | 17 +- arch/arm64/kvm/hyp/vhe/sysreg-sr.c | 7 + arch/arm64/kvm/nested.c | 3 +- arch/arm64/kvm/reset.c | 156 ++++++++++---- arch/arm64/kvm/sys_regs.c | 141 ++++++++++++- arch/arm64/tools/sysreg | 8 +- include/uapi/linux/kvm.h | 1 + tools/testing/selftests/kvm/arm64/get-reg-list.c | 15 +- tools/testing/selftests/kvm/arm64/set_id_regs.c | 27 ++- 31 files changed, 1327 insertions(+), 303 deletions(-) --- base-commit: 062b3e4a1f880f104a8d4b90b767788786aa7b78 change-id: 20230301-kvm-arm64-sme-06a1246d3636 Best regards, -- Mark Brown <broonie(a)kernel.org>

4 hours, 13 minutes

4
35
0 0

[PATCH v4 0/3] Support comma-separated symbols and :entry/:exit

by Seokwoo Chung (Ryan)

Extend fprobe to support list-style filters and explicit entry/exit suffixes. Currentyl, fprobe only supports a single symbol (or wildcard) per event. This patch allows users to specify a comma-separated list of symbols. New Syntax: - f:[GRP/][EVENT] func1,func2,func3:entry - f:[GRP/][EVENT] func1,func2,func3:exit Logic changes: - Refactor parsing logic into 'parse_fprobe_spec' - Support '!' prefix for exclusion - Disable BTF lookup ('ctx->funcname = NULL') when a list or wildcard is used, as a single function signature cannot apply to multiple functions. - Reject legacy '%return' suffix when used with lists or wildcards - Update tracefs/README Testing: Verified on x86_64 via QEMU. Checked registration of lists, exclusions, and explicit suffixes. Verified rejection of invalid syntax including trailing commas and mixed legacy/new syntax. Seokwoo Chung (Ryan) (3): docs: tracing/fprobe: Document list filters and :entry/:exit tracing/fprobe: Support comma-separated symbols and :entry/:exit selftests/ftrace: Add accept cases for fprobe list syntax Changes in v4: - Added validation to reject trailing commas (empty tokens) in symbol lists - Added vaildation to reject mixed of list syntax with %return suffix - Refactored parse_fprobe_spec to user __free(kfree) for automatic memory cleanup - Removed the now-unused parse_symbol_and_return function to avoid compiler warnings. - Tigtened %return detection to ensure it only matches as a strict suffix, not a substring - Link to v3: https://lore.kernel.org/lkml/20250904103219.f4937968362bfff1ecd3f004@kernel… Documentation/trace/fprobetrace.rst | 17 +- kernel/trace/trace.c | 3 +- kernel/trace/trace_fprobe.c | 209 ++++++++++++++---- .../ftrace/test.d/dynevent/fprobe_list.tc | 92 ++++++++ 4 files changed, 269 insertions(+), 52 deletions(-) create mode 100644 tools/testing/selftests/ftrace/test.d/dynevent/fprobe_list.tc -- 2.43.0

4 hours, 14 minutes

1
3
0 0

[PATCH v2 0/9] Initial DMABUF support for iommufd

by Jason Gunthorpe

This series is the start of adding full DMABUF support to iommufd. Currently it is limited to only work with VFIO's DMABUF exporter. It sits on top of Leon's series to add a DMABUF exporter to VFIO: https://lore.kernel.org/all/20251120-dmabuf-vfio-v9-0-d7f71607f371@nvidia.c… The existing IOMMU_IOAS_MAP_FILE is enhanced to detect DMABUF fd's, but otherwise works the same as it does today for a memfd. The user can select a slice of the FD to map into the ioas and if the underliyng alignment requirements are met it will be placed in the iommu_domain. Though limited, it is enough to allow a VMM like QEMU to connect MMIO BAR memory from VFIO to an iommu_domain controlled by iommufd. This is used for PCI Peer to Peer support in VMs, and is the last feature that the VFIO type 1 container has that iommufd couldn't do. The VFIO type1 version extracts raw PFNs from VMAs, which has no lifetime control and is a use-after-free security problem. Instead iommufd relies on revokable DMABUFs. Whenever VFIO thinks there should be no access to the MMIO it can shoot down the mapping in iommufd which will unmap it from the iommu_domain. There is no automatic remap, this is a safety protocol so the kernel doesn't get stuck. Userspace is expected to know it is doing something that will revoke the dmabuf and map/unmap it around the activity. Eg when QEMU goes to issue FLR it should do the map/unmap to iommufd. Since DMABUF is missing some key general features for this use case it relies on a "private interconnect" between VFIO and iommufd via the vfio_pci_dma_buf_iommufd_map() call. The call confirms the DMABUF has revoke semantics and delivers a phys_addr for the memory suitable for use with iommu_map(). Medium term there is a desire to expand the supported DMABUFs to include GPU drivers to support DPDK/SPDK type use cases so future series will work to add a general concept of revoke and a general negotiation of interconnect to remove vfio_pci_dma_buf_iommufd_map(). I also plan another series to modify iommufd's vfio_compat to transparently pull a dmabuf out of a VFIO VMA to emulate more of the uAPI of type1. The latest series for interconnect negotation to exchange a phys_addr is: https://lore.kernel.org/r/20251027044712.1676175-1-vivek.kasireddy@intel.com And the discussion for design of revoke is here: https://lore.kernel.org/dri-devel/20250114173103.GE5556@nvidia.com/ This is on github: https://github.com/jgunthorpe/linux/commits/iommufd_dmabuf v2: - Rebase on Leon's v9 - Fix mislocking in an iopt_fill_domain() error path - Revise the comments around how the sub page offset works - Remove a useless WARN_ON in iopt_pages_rw_access() - Fixed missed memory free in the selftest v1: https://patch.msgid.link/r/0-v1-64bed2430cdb+31b-iommufd_dmabuf_jgg@nvidia.… Jason Gunthorpe (9): vfio/pci: Add vfio_pci_dma_buf_iommufd_map() iommufd: Add DMABUF to iopt_pages iommufd: Do not map/unmap revoked DMABUFs iommufd: Allow a DMABUF to be revoked iommufd: Allow MMIO pages in a batch iommufd: Have pfn_reader process DMABUF iopt_pages iommufd: Have iopt_map_file_pages convert the fd to a file iommufd: Accept a DMABUF through IOMMU_IOAS_MAP_FILE iommufd/selftest: Add some tests for the dmabuf flow drivers/iommu/iommufd/io_pagetable.c | 78 +++- drivers/iommu/iommufd/io_pagetable.h | 54 ++- drivers/iommu/iommufd/ioas.c | 8 +- drivers/iommu/iommufd/iommufd_private.h | 14 +- drivers/iommu/iommufd/iommufd_test.h | 10 + drivers/iommu/iommufd/main.c | 10 + drivers/iommu/iommufd/pages.c | 414 ++++++++++++++++-- drivers/iommu/iommufd/selftest.c | 143 ++++++ drivers/vfio/pci/vfio_pci_dmabuf.c | 34 ++ include/linux/vfio_pci_core.h | 4 + tools/testing/selftests/iommu/iommufd.c | 43 ++ tools/testing/selftests/iommu/iommufd_utils.h | 44 ++ 12 files changed, 786 insertions(+), 70 deletions(-) base-commit: f836737ed56db9e2d5b047c56a31e05af0f3f116 -- 2.43.0

4 hours, 28 minutes

2
11
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror