November 2023 - Linux-kselftest-mirror

[PATCH v3 00/25] Permission Overlay Extension

by Joey Gouly

Hello everyone, This series implements the Permission Overlay Extension introduced in 2022 VMSA enhancements [1]. It is based on v6.7-rc2. Changes since v2[2]: # Added ptrace support and selftest # Add missing POR_EL0 initialisation in fork/clone # Rebase onto v6.7-rc2 # Add r-bs The Permission Overlay Extension allows to constrain permissions on memory regions. This can be used from userspace (EL0) without a system call or TLB invalidation. POE is used to implement the Memory Protection Keys [3] Linux syscall. The first few patches add the basic framework, then the PKEYS interface is implemented, and then the selftests are made to work on arm64. There was discussion about what the 'default' protection key value should be, I used disallow-all (apart from pkey 0), which matches what x86 does. I have tested the modified protection_keys test on x86_64, but not PPC. I haven't build tested the x86/ppc arch changes. Thanks, Joey [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processor… [2] https://lore.kernel.org/linux-arm-kernel/20231027180850.1068089-1-joey.goul… [3] Documentation/core-api/protection-keys.rst Joey Gouly (25): arm64/sysreg: add system register POR_EL{0,1} arm64/sysreg: update CPACR_EL1 register arm64: cpufeature: add Permission Overlay Extension cpucap arm64: disable trapping of POR_EL0 to EL2 arm64: context switch POR_EL0 register KVM: arm64: Save/restore POE registers arm64: enable the Permission Overlay Extension for EL0 arm64: add POIndex defines arm64: define VM_PKEY_BIT* for arm64 arm64: mask out POIndex when modifying a PTE arm64: enable ARCH_HAS_PKEYS on arm64 arm64: handle PKEY/POE faults arm64: stop using generic mm_hooks.h arm64: implement PKEYS support arm64: add POE signal support arm64: enable PKEY support for CPUs with S1POE arm64: enable POE and PIE to coexist arm64/ptrace: add support for FEAT_POE kselftest/arm64: move get_header() selftests: mm: move fpregs printing selftests: mm: make protection_keys test work on arm64 kselftest/arm64: add HWCAP test for FEAT_S1POE kselftest/arm64: parse POE_MAGIC in a signal frame kselftest/arm64: Add test case for POR_EL0 signal frame records KVM: selftests: get-reg-list: add Permission Overlay registers Documentation/arch/arm64/elf_hwcaps.rst | 3 + arch/arm64/Kconfig | 18 +++ arch/arm64/include/asm/cpufeature.h | 6 + arch/arm64/include/asm/el2_setup.h | 10 +- arch/arm64/include/asm/hwcap.h | 1 + arch/arm64/include/asm/kvm_arm.h | 4 +- arch/arm64/include/asm/kvm_host.h | 4 + arch/arm64/include/asm/mman.h | 8 +- arch/arm64/include/asm/mmu.h | 2 + arch/arm64/include/asm/mmu_context.h | 51 ++++++- arch/arm64/include/asm/page.h | 10 ++ arch/arm64/include/asm/pgtable-hwdef.h | 10 ++ arch/arm64/include/asm/pgtable-prot.h | 8 +- arch/arm64/include/asm/pgtable.h | 26 +++- arch/arm64/include/asm/pkeys.h | 110 ++++++++++++++ arch/arm64/include/asm/por.h | 33 +++++ arch/arm64/include/asm/processor.h | 1 + arch/arm64/include/asm/sysreg.h | 16 ++ arch/arm64/include/asm/traps.h | 1 + arch/arm64/include/uapi/asm/hwcap.h | 1 + arch/arm64/include/uapi/asm/sigcontext.h | 7 + arch/arm64/kernel/cpufeature.c | 23 +++ arch/arm64/kernel/cpuinfo.c | 1 + arch/arm64/kernel/process.c | 22 +++ arch/arm64/kernel/ptrace.c | 46 ++++++ arch/arm64/kernel/signal.c | 51 +++++++ arch/arm64/kernel/traps.c | 12 +- arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 10 ++ arch/arm64/kvm/sys_regs.c | 2 + arch/arm64/mm/fault.c | 44 +++++- arch/arm64/mm/mmap.c | 9 ++ arch/arm64/mm/mmu.c | 40 +++++ arch/arm64/tools/cpucaps | 1 + arch/arm64/tools/sysreg | 15 +- arch/powerpc/include/asm/page.h | 11 ++ arch/x86/include/asm/page.h | 10 ++ fs/proc/task_mmu.c | 2 + include/linux/mm.h | 13 -- include/uapi/linux/elf.h | 1 + tools/testing/selftests/arm64/abi/hwcap.c | 14 ++ .../testing/selftests/arm64/signal/.gitignore | 1 + .../arm64/signal/testcases/poe_siginfo.c | 86 +++++++++++ .../arm64/signal/testcases/testcases.c | 27 +--- .../arm64/signal/testcases/testcases.h | 28 +++- .../selftests/kvm/aarch64/get-reg-list.c | 14 ++ tools/testing/selftests/mm/Makefile | 2 +- tools/testing/selftests/mm/pkey-arm64.h | 139 ++++++++++++++++++ tools/testing/selftests/mm/pkey-helpers.h | 8 + tools/testing/selftests/mm/pkey-powerpc.h | 3 + tools/testing/selftests/mm/pkey-x86.h | 4 + tools/testing/selftests/mm/protection_keys.c | 109 ++++++++++++-- 51 files changed, 1011 insertions(+), 67 deletions(-) create mode 100644 arch/arm64/include/asm/pkeys.h create mode 100644 arch/arm64/include/asm/por.h create mode 100644 tools/testing/selftests/arm64/signal/testcases/poe_siginfo.c create mode 100644 tools/testing/selftests/mm/pkey-arm64.h -- 2.25.1

1 year

5
60
0 0

[PATCH v3 4/4] KVM: riscv: selftests: Add Svadu Extension to get-reg-list testt

by Yong-Xuan Wang

Update the get-reg-list test to test the Svadu Extension is available for guest OS. Signed-off-by: Yong-Xuan Wang <yongxuan.wang(a)sifive.com> --- .../testing/selftests/kvm/riscv/get-reg-list.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/tools/testing/selftests/kvm/riscv/get-reg-list.c b/tools/testing/selftests/kvm/riscv/get-reg-list.c index 9f99ea42f45f..972538d76f48 100644 --- a/tools/testing/selftests/kvm/riscv/get-reg-list.c +++ b/tools/testing/selftests/kvm/riscv/get-reg-list.c @@ -49,6 +49,7 @@ bool filter_reg(__u64 reg) case KVM_REG_RISCV_ISA_EXT | KVM_RISCV_ISA_EXT_ZICSR: case KVM_REG_RISCV_ISA_EXT | KVM_RISCV_ISA_EXT_ZIFENCEI: case KVM_REG_RISCV_ISA_EXT | KVM_RISCV_ISA_EXT_ZIHPM: + case KVM_REG_RISCV_ISA_EXT | KVM_RISCV_ISA_EXT_SVADU: return true; /* AIA registers are always available when Ssaia can't be disabled */ case KVM_REG_RISCV_CSR | KVM_REG_RISCV_CSR_AIA | KVM_REG_RISCV_CSR_AIA_REG(siselect): @@ -340,6 +341,7 @@ static const char *isa_ext_id_to_str(__u64 id) "KVM_RISCV_ISA_EXT_ZICSR", "KVM_RISCV_ISA_EXT_ZIFENCEI", "KVM_RISCV_ISA_EXT_ZIHPM", + "KVM_RISCV_ISA_EXT_SVADU", }; if (reg_off >= ARRAY_SIZE(kvm_isa_ext_reg_name)) { @@ -700,6 +702,10 @@ static __u64 fp_d_regs[] = { KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_ISA_EXT | KVM_RISCV_ISA_EXT_D, }; +static __u64 svadu_regs[] = { + KVM_REG_RISCV | KVM_REG_SIZE_ULONG | KVM_REG_RISCV_ISA_EXT | KVM_RISCV_ISA_EXT_SVADU, +}; + #define BASE_SUBLIST \ {"base", .regs = base_regs, .regs_n = ARRAY_SIZE(base_regs), \ .skips_set = base_skips_set, .skips_set_n = ARRAY_SIZE(base_skips_set),} @@ -739,6 +745,9 @@ static __u64 fp_d_regs[] = { #define FP_D_REGS_SUBLIST \ {"fp_d", .feature = KVM_RISCV_ISA_EXT_D, .regs = fp_d_regs, \ .regs_n = ARRAY_SIZE(fp_d_regs),} +#define SVADU_REGS_SUBLIST \ + {"svadu", .feature = KVM_RISCV_ISA_EXT_SVADU, .regs = svadu_regs, \ + .regs_n = ARRAY_SIZE(svadu_regs),} static struct vcpu_reg_list h_config = { .sublists = { @@ -876,6 +885,14 @@ static struct vcpu_reg_list fp_d_config = { }, }; +static struct vcpu_reg_list svadu_config = { + .sublists = { + BASE_SUBLIST, + SVADU_REGS_SUBLIST, + {0}, + }, +}; + struct vcpu_reg_list *vcpu_configs[] = { &h_config, &zicbom_config, @@ -894,5 +911,6 @@ struct vcpu_reg_list *vcpu_configs[] = { &aia_config, &fp_f_config, &fp_d_config, + &svadu_config, }; int vcpu_configs_n = ARRAY_SIZE(vcpu_configs); -- 2.17.1

1 year

2
1
0 0

[PATCH] kselftest/arm64: Improve output for skipped TPIDR2 ABI test

by Mark Brown

When TPIDR2 is not supported the tpidr2 ABI test prints the same message for each skipped test: ok 1 skipped, TPIDR2 not supported which isn't ideal for test automation software since it tracks kselftest results based on the string used to describe the test. This is also not standard KTAP output, the expected format is: ok 1 # SKIP default_value Updated the program to generate this, using the same set of test names that we would run if the test actually executed. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- tools/testing/selftests/arm64/abi/tpidr2.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/tools/testing/selftests/arm64/abi/tpidr2.c b/tools/testing/selftests/arm64/abi/tpidr2.c index 351a098b503a..02ee3a91b780 100644 --- a/tools/testing/selftests/arm64/abi/tpidr2.c +++ b/tools/testing/selftests/arm64/abi/tpidr2.c @@ -254,6 +254,12 @@ static int write_clone_read(void) putnum(++tests_run); \ putstr(" " #name "\n"); +#define skip_test(name) \ + tests_skipped++; \ + putstr("ok "); \ + putnum(++tests_run); \ + putstr(" # SKIP " #name "\n"); + int main(int argc, char **argv) { int ret, i; @@ -283,13 +289,11 @@ int main(int argc, char **argv) } else { putstr("# SME support not present\n"); - for (i = 0; i < EXPECTED_TESTS; i++) { - putstr("ok "); - putnum(i); - putstr(" skipped, TPIDR2 not supported\n"); - } - - tests_skipped += EXPECTED_TESTS; + skip_test(default_value); + skip_test(write_read); + skip_test(write_sleep_read); + skip_test(write_fork_read); + skip_test(write_clone_read); } print_summary(); --- base-commit: 98b1cc82c4affc16f5598d4fa14b1858671b2263 change-id: 20231124-kselftest-arm64-tpidr2-skip-43764f4ff4f4 Best regards, -- Mark Brown <broonie(a)kernel.org>

1 year

2
1
0 0

[RFC PATCH v2 0/7] tun: Introduce virtio-net hashing feature

by Akihiko Odaki

virtio-net have two usage of hashes: one is RSS and another is hash reporting. Conventionally the hash calculation was done by the VMM. However, computing the hash after the queue was chosen defeats the purpose of RSS. Another approach is to use eBPF steering program. This approach has another downside: it cannot report the calculated hash due to the restrictive nature of eBPF. Extend the steering program feature by introducing a dedicated program type: BPF_PROG_TYPE_VNET_HASH. This program type is capable to report the hash value and the queue to use at the same time. This is a rewrite of a RFC patch series submitted by Yuri Benditovich that incorporates feedbacks for the series and V1 of this series: https://lore.kernel.org/lkml/20210112194143.1494-1-yuri.benditovich@daynix.… QEMU patched to use this new feature is available at: https://github.com/daynix/qemu/tree/akihikodaki/bpf The QEMU patches will soon be submitted to the upstream as RFC too. V1 -> V2: Changed to introduce a new BPF program type. Akihiko Odaki (7): bpf: Introduce BPF_PROG_TYPE_VNET_HASH bpf: Add vnet_hash members to __sk_buff skbuff: Introduce SKB_EXT_TUN_VNET_HASH virtio_net: Add virtio_net_hdr_v1_hash_from_skb() tun: Support BPF_PROG_TYPE_VNET_HASH selftests/bpf: Test BPF_PROG_TYPE_VNET_HASH vhost_net: Support VIRTIO_NET_F_HASH_REPORT Documentation/bpf/bpf_prog_run.rst | 1 + Documentation/bpf/libbpf/program_types.rst | 2 + drivers/net/tun.c | 158 +++++-- drivers/vhost/net.c | 16 +- include/linux/bpf_types.h | 2 + include/linux/filter.h | 7 + include/linux/skbuff.h | 10 + include/linux/virtio_net.h | 22 + include/uapi/linux/bpf.h | 5 + kernel/bpf/verifier.c | 6 + net/core/filter.c | 86 +++- net/core/skbuff.c | 3 + tools/include/uapi/linux/bpf.h | 5 + tools/lib/bpf/libbpf.c | 2 + tools/testing/selftests/bpf/config | 1 + tools/testing/selftests/bpf/config.aarch64 | 1 - .../selftests/bpf/prog_tests/vnet_hash.c | 385 ++++++++++++++++++ tools/testing/selftests/bpf/progs/vnet_hash.c | 16 + 18 files changed, 681 insertions(+), 47 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/vnet_hash.c create mode 100644 tools/testing/selftests/bpf/progs/vnet_hash.c -- 2.42.0

1 year

5
25
0 0

[PATCH] kselftests: add per_test_log support

by Hangbin Liu

By default, all the test output will be printed to stdout or output.log if -s supplied. The kselftest/runner.sh also supports per test log if the variable per_test_logging is set. So add new option -p to set this veriable. Note the -p option is conflict with -s option. Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> --- tools/testing/selftests/run_kselftest.sh | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/run_kselftest.sh b/tools/testing/selftests/run_kselftest.sh index 92743980e553..965220a314ce 100755 --- a/tools/testing/selftests/run_kselftest.sh +++ b/tools/testing/selftests/run_kselftest.sh @@ -20,7 +20,8 @@ usage() { cat <<EOF Usage: $0 [OPTIONS] - -s | --summary Print summary with detailed log in output.log + -s | --summary Print summary with detailed log in output.log (conflict with -p) + -p | --per_test_log Print test log in /tmp with each test name (conflict with -s) -t | --test COLLECTION:TEST Run TEST from COLLECTION -c | --collection COLLECTION Run all tests from COLLECTION -l | --list List the available collection:test entries @@ -41,6 +42,9 @@ while true; do logfile="$BASE_DIR"/output.log cat /dev/null > $logfile shift ;; + -p | --per_test_log) + per_test_logging=1 + shift ;; -t | --test) TESTS="$TESTS $2" shift 2 ;; -- 2.41.0

1 year

1
2
0 0

[PATCH v3 00/11] A minor flurry of selftest/mm fixes

by John Hubbard

Hi, Changes since v2 [1]: * Added a new patch (sent separately earlier) at the end, to error out if "make headers" has not yet been run. * Reworked and simplified the uffd movement patch. Now it only moves some uffd*() routines, not all, and doesn't have to touch the Makefile at all. This lighter touch also allowed me to drop the "move psize(), pshift() into vm_utils.c" entirely. I expect Peter Xu will be a little happier with this new approach. * Fixed the commit description for the MADV_COLLAPSE patch. * Added more Reviewed-by tags from David Hildenbrand and Peter Xu. [1] https://lore.kernel.org/all/20230603021558.95299-1-jhubbard@nvidia.com/ John Hubbard (11): selftests/mm: fix uffd-stress unused function warning selftests/mm: fix unused variable warnings in hugetlb-madvise.c, migration.c selftests/mm: fix "warning: expression which evaluates to zero..." in mlock2-tests.c selftests/mm: fix invocation of tests that are run via shell scripts selftests/mm: .gitignore: add mkdirty, va_high_addr_switch selftests/mm: fix two -Wformat-security warnings in uffd builds selftests/mm: fix a "possibly uninitialized" warning in pkey-x86.h selftests/mm: fix build failures due to missing MADV_COLLAPSE selftests/mm: move certain uffd*() routines from vm_util.c to uffd-common.c Documentation: kselftest: "make headers" is a prerequisite selftests: error out if kernel header files are not yet built Documentation/dev-tools/kselftest.rst | 1 + tools/testing/selftests/lib.mk | 36 +++++++++++- tools/testing/selftests/mm/.gitignore | 2 + tools/testing/selftests/mm/cow.c | 7 --- tools/testing/selftests/mm/hugetlb-madvise.c | 8 ++- tools/testing/selftests/mm/khugepaged.c | 10 ---- tools/testing/selftests/mm/migration.c | 5 +- tools/testing/selftests/mm/mlock2-tests.c | 1 - tools/testing/selftests/mm/pkey-x86.h | 2 +- tools/testing/selftests/mm/run_vmtests.sh | 6 +- tools/testing/selftests/mm/uffd-common.c | 59 ++++++++++++++++++++ tools/testing/selftests/mm/uffd-common.h | 5 ++ tools/testing/selftests/mm/uffd-stress.c | 10 ---- tools/testing/selftests/mm/uffd-unit-tests.c | 16 ++---- tools/testing/selftests/mm/vm_util.c | 59 -------------------- tools/testing/selftests/mm/vm_util.h | 14 +++-- 16 files changed, 130 insertions(+), 111 deletions(-) base-commit: f8dba31b0a826e691949cd4fdfa5c30defaac8c5 -- 2.40.1

1 year

6
38
0 0

[PATCH RFT v4 0/5] fork: Support shadow stacks in clone3()

by Mark Brown

The kernel has recently added support for shadow stacks, currently x86 only using their CET feature but both arm64 and RISC-V have equivalent features (GCS and Zicfiss respectively), I am actively working on GCS[1]. With shadow stacks the hardware maintains an additional stack containing only the return addresses for branch instructions which is not generally writeable by userspace and ensures that any returns are to the recorded addresses. This provides some protection against ROP attacks and making it easier to collect call stacks. These shadow stacks are allocated in the address space of the userspace process. Our API for shadow stacks does not currently offer userspace any flexiblity for managing the allocation of shadow stacks for newly created threads, instead the kernel allocates a new shadow stack with the same size as the normal stack whenever a thread is created with the feature enabled. The stacks allocated in this way are freed by the kernel when the thread exits or shadow stacks are disabled for the thread. This lack of flexibility and control isn't ideal, in the vast majority of cases the shadow stack will be over allocated and the implicit allocation and deallocation is not consistent with other interfaces. As far as I can tell the interface is done in this manner mainly because the shadow stack patches were in development since before clone3() was implemented. Since clone3() is readily extensible let's add support for specifying a shadow stack when creating a new thread or process in a similar manner to how the normal stack is specified, keeping the current implicit allocation behaviour if one is not specified either with clone3() or through the use of clone(). Unlike normal stacks only the shadow stack size is specified, similar issues to those that lead to the creation of map_shadow_stack() apply. Please note that the x86 portions of this code are build tested only, I don't appear to have a system that can run CET avaible to me, I have done testing with an integration into my pending work for GCS. There is some possibility that the arm64 implementation may require the use of clone3() and explicit userspace allocation of shadow stacks, this is still under discussion. A new architecture feature Kconfig option for shadow stacks is added as here, this was suggested as part of the review comments for the arm64 GCS series and since we need to detect if shadow stacks are supported it seemed sensible to roll it in here. [1] https://lore.kernel.org/r/20231009-arm64-gcs-v6-0-78e55deaa4dd@kernel.org/ Signed-off-by: Mark Brown <broonie(a)kernel.org> --- Changes in v4: - Formatting changes. - Use a define for minimum shadow stack size and move some basic validation to fork.c. - Link to v3: https://lore.kernel.org/r/20231120-clone3-shadow-stack-v3-0-a7b8ed3e2acc@ke… Changes in v3: - Rebase onto v6.7-rc2. - Remove stale shadow_stack in internal kargs. - If a shadow stack is specified unconditionally use it regardless of CLONE_ parameters. - Force enable shadow stacks in the selftest. - Update changelogs for RISC-V feature rename. - Link to v2: https://lore.kernel.org/r/20231114-clone3-shadow-stack-v2-0-b613f8681155@ke… Changes in v2: - Rebase onto v6.7-rc1. - Remove ability to provide preallocated shadow stack, just specify the desired size. - Link to v1: https://lore.kernel.org/r/20231023-clone3-shadow-stack-v1-0-d867d0b5d4d0@ke… --- Mark Brown (5): mm: Introduce ARCH_HAS_USER_SHADOW_STACK fork: Add shadow stack support to clone3() selftests/clone3: Factor more of main loop into test_clone3() selftests/clone3: Allow tests to flag if -E2BIG is a valid error code kselftest/clone3: Test shadow stack support arch/x86/Kconfig | 1 + arch/x86/include/asm/shstk.h | 11 +- arch/x86/kernel/process.c | 2 +- arch/x86/kernel/shstk.c | 56 ++++-- fs/proc/task_mmu.c | 2 +- include/linux/mm.h | 2 +- include/linux/sched/task.h | 1 + include/uapi/linux/sched.h | 4 + kernel/fork.c | 53 ++++-- mm/Kconfig | 6 + tools/testing/selftests/clone3/clone3.c | 200 +++++++++++++++++----- tools/testing/selftests/clone3/clone3_selftests.h | 7 + 12 files changed, 268 insertions(+), 77 deletions(-) --- base-commit: 98b1cc82c4affc16f5598d4fa14b1858671b2263 change-id: 20231019-clone3-shadow-stack-15d40d2bf536 Best regards, -- Mark Brown <broonie(a)kernel.org>

1 year

6
27
0 0

[PATCH v1 00/23] Enable FRED with KVM VMX

by Xin Li

This patch set enables the Intel flexible return and event delivery (FRED) architecture with KVM VMX to allow guests to utilize FRED. The FRED architecture defines simple new transitions that change privilege level (ring transitions). The FRED architecture was designed with the following goals: 1) Improve overall performance and response time by replacing event delivery through the interrupt descriptor table (IDT event delivery) and event return by the IRET instruction with lower latency transitions. 2) Improve software robustness by ensuring that event delivery establishes the full supervisor context and that event return establishes the full user context. The new transitions defined by the FRED architecture are FRED event delivery and, for returning from events, two FRED return instructions. FRED event delivery can effect a transition from ring 3 to ring 0, but it is used also to deliver events incident to ring 0. One FRED instruction (ERETU) effects a return from ring 0 to ring 3, while the other (ERETS) returns while remaining in ring 0. Collectively, FRED event delivery and the FRED return instructions are FRED transitions. Intel VMX architecture is extended to run FRED guests, and the changes are majorly: 1) New VMCS fields for FRED context management, which includes two new event data VMCS fields, eight new guest FRED context VMCS fields and eight new host FRED context VMCS fields. 2) VMX nested-Exception support for proper virtualization of stack levels introduced with FRED architecture. Search for the latest FRED spec in most search engines with this search pattern: site:intel.com FRED (flexible return and event delivery) specification We want to send out the FRED VMX patch set for review while the FRED native patch set v12 is being reviewed @ https://lkml.kernel.org/kvm/20231003062458.23552-1-xin3.li@intel.com/. For easier review, I have set up a base tree with the latest FRED native patch set on top of tip tree in the 'fred_v12' branch of repo https://github.com/xinli-intel/linux-fred-public.git. Patch 1-2 are cleanups to VMX basic and misc MSRs, which were sent out earlier as a preparation for FRED changes: https://lore.kernel.org/kvm/20231030233940.438233-1-xin@zytor.com/. Patch 3-14 add FRED support to VMX. Patch 15-18 add FRED support to nested VMX. Patch 19 exposes FRED to KVM guests to complete the enabling. Patch 20-23 adds FRED selftests. Shan Kang (1): KVM: selftests: Add fred exception tests Xin Li (22): KVM: VMX: Cleanup VMX basic information defines and usages KVM: VMX: Cleanup VMX misc information defines and usages KVM: VMX: Add support for the secondary VM exit controls KVM: x86: Mark CR4.FRED as not reserved KVM: VMX: Initialize FRED VM entry/exit controls in vmcs_config KVM: VMX: Defer enabling FRED MSRs save/load until after set CPUID KVM: VMX: Disable intercepting FRED MSRs KVM: VMX: Initialize VMCS FRED fields KVM: VMX: Switch FRED RSP0 between host and guest KVM: VMX: Add support for FRED context save/restore KVM: x86: Add kvm_is_fred_enabled() KVM: VMX: Handle FRED event data KVM: VMX: Handle VMX nested exception for FRED KVM: VMX: Dump FRED context in dump_vmcs() KVM: nVMX: Add support for the secondary VM exit controls KVM: nVMX: Add FRED VMCS fields KVM: nVMX: Add support for VMX FRED controls KVM: nVMX: Add VMCS FRED states checking KVM: x86: Allow FRED/LKGS/WRMSRNS to be exposed to guests KVM: selftests: Add FRED VMCS fields to evmcs KVM: selftests: Run debug_regs test with FRED enabled KVM: selftests: Add a new VM guest mode to run user level code Documentation/virt/kvm/x86/nested-vmx.rst | 19 + arch/x86/include/asm/hyperv-tlfs.h | 19 + arch/x86/include/asm/kvm_host.h | 9 +- arch/x86/include/asm/msr-index.h | 15 +- arch/x86/include/asm/vmx.h | 57 ++- arch/x86/kvm/cpuid.c | 4 +- arch/x86/kvm/kvm_cache_regs.h | 10 + arch/x86/kvm/svm/svm.c | 4 +- arch/x86/kvm/vmx/capabilities.h | 20 +- arch/x86/kvm/vmx/hyperv.c | 61 ++- arch/x86/kvm/vmx/nested.c | 315 ++++++++++++-- arch/x86/kvm/vmx/nested.h | 2 +- arch/x86/kvm/vmx/vmcs.h | 1 + arch/x86/kvm/vmx/vmcs12.c | 19 + arch/x86/kvm/vmx/vmcs12.h | 38 ++ arch/x86/kvm/vmx/vmcs_shadow_fields.h | 6 +- arch/x86/kvm/vmx/vmx.c | 404 ++++++++++++++++-- arch/x86/kvm/vmx/vmx.h | 14 +- arch/x86/kvm/x86.c | 55 ++- arch/x86/kvm/x86.h | 5 +- tools/testing/selftests/kvm/Makefile | 1 + .../selftests/kvm/include/kvm_util_base.h | 1 + .../selftests/kvm/include/x86_64/evmcs.h | 146 +++++++ .../selftests/kvm/include/x86_64/processor.h | 33 ++ .../selftests/kvm/include/x86_64/vmx.h | 20 + tools/testing/selftests/kvm/lib/kvm_util.c | 5 +- .../selftests/kvm/lib/x86_64/processor.c | 15 +- tools/testing/selftests/kvm/lib/x86_64/vmx.c | 4 +- .../testing/selftests/kvm/x86_64/debug_regs.c | 50 ++- .../testing/selftests/kvm/x86_64/fred_test.c | 262 ++++++++++++ 30 files changed, 1464 insertions(+), 150 deletions(-) create mode 100644 tools/testing/selftests/kvm/x86_64/fred_test.c base-commit: d49b86c24e836941c85c4906e9519fca9426a6e0 -- 2.42.0

1 year

7
69
0 0

[RFC PATCH v3 00/12] Device Memory TCP

by Mina Almasry

Changes in RFC v3: ------------------ 1. Pulled in the memory-provider dependency from Jakub's RFC[1] to make the series reviewable and mergable. 2. Implemented multi-rx-queue binding which was a todo in v2. 3. Fix to cmsg handling. The sticking point in RFC v2[2] was the device reset required to refill the device rx-queues after the dmabuf bind/unbind. The solution suggested as I understand is a subset of the per-queue management ops Jakub suggested or similar: https://lore.kernel.org/netdev/20230815171638.4c057dcd@kernel.org/ This is not addressed in this revision, because: 1. This point was discussed at netconf & netdev and there is openness to using the current approach of requiring a device reset. 2. Implementing individual queue resetting seems to be difficult for my test bed with GVE. My prototype to test this ran into issues with the rx-queues not coming back up properly if reset individually. At the moment I'm unsure if it's a mistake in the POC or a genuine issue in the virtualization stack behind GVE, which currently doesn't test individual rx-queue restart. 3. Our usecases are not bothered by requiring a device reset to refill the buffer queues, and we'd like to support NICs that run into this limitation with resetting individual queues. My thought is that drivers that have trouble with per-queue configs can use the support in this series, while drivers that support new netdev ops to reset individual queues can automatically reset the queue as part of the dma-buf bind/unbind. The same approach with device resets is presented again for consideration with other sticking points addressed. This proposal includes the rx devmem path only proposed for merge. For a snapshot of my entire tree which includes the GVE POC page pool support & device memory support: https://github.com/torvalds/linux/compare/master...mina:linux:tcpdevmem-v3 [1] https://lore.kernel.org/netdev/f8270765-a27b-6ccf-33ea-cda097168d79@redhat.… [2] https://lore.kernel.org/netdev/CAHS8izOVJGJH5WF68OsRWFKJid1_huzzUK+hpKbLcL4… Cc: Shakeel Butt <shakeelb(a)google.com> Cc: Jeroen de Borst <jeroendb(a)google.com> Cc: Praveen Kaligineedi <pkaligineedi(a)google.com> Changes in RFC v2: ------------------ The sticking point in RFC v1[1] was the dma-buf pages approach we used to deliver the device memory to the TCP stack. RFC v2 is a proof-of-concept that attempts to resolve this by implementing scatterlist support in the networking stack, such that we can import the dma-buf scatterlist directly. This is the approach proposed at a high level here[2]. Detailed changes: 1. Replaced dma-buf pages approach with importing scatterlist into the page pool. 2. Replace the dma-buf pages centric API with a netlink API. 3. Removed the TX path implementation - there is no issue with implementing the TX path with scatterlist approach, but leaving out the TX path makes it easier to review. 4. Functionality is tested with this proposal, but I have not conducted perf testing yet. I'm not sure there are regressions, but I removed perf claims from the cover letter until they can be re-confirmed. 5. Added Signed-off-by: contributors to the implementation. 6. Fixed some bugs with the RX path since RFC v1. Any feedback welcome, but specifically the biggest pending questions needing feedback IMO are: 1. Feedback on the scatterlist-based approach in general. 2. Netlink API (Patch 1 & 2). 3. Approach to handle all the drivers that expect to receive pages from the page pool (Patch 6). [1] https://lore.kernel.org/netdev/dfe4bae7-13a0-3c5d-d671-f61b375cb0b4@gmail.c… [2] https://lore.kernel.org/netdev/CAHS8izPm6XRS54LdCDZVd0C75tA1zHSu6jLVO8nzTLX… ---------------------- * TL;DR: Device memory TCP (devmem TCP) is a proposal for transferring data to and/or from device memory efficiently, without bouncing the data to a host memory buffer. * Problem: A large amount of data transfers have device memory as the source and/or destination. Accelerators drastically increased the volume of such transfers. Some examples include: - ML accelerators transferring large amounts of training data from storage into GPU/TPU memory. In some cases ML training setup time can be as long as 50% of TPU compute time, improving data transfer throughput & efficiency can help improving GPU/TPU utilization. - Distributed training, where ML accelerators, such as GPUs on different hosts, exchange data among them. - Distributed raw block storage applications transfer large amounts of data with remote SSDs, much of this data does not require host processing. Today, the majority of the Device-to-Device data transfers the network are implemented as the following low level operations: Device-to-Host copy, Host-to-Host network transfer, and Host-to-Device copy. The implementation is suboptimal, especially for bulk data transfers, and can put significant strains on system resources, such as host memory bandwidth, PCIe bandwidth, etc. One important reason behind the current state is the kernel’s lack of semantics to express device to network transfers. * Proposal: In this patch series we attempt to optimize this use case by implementing socket APIs that enable the user to: 1. send device memory across the network directly, and 2. receive incoming network packets directly into device memory. Packet _payloads_ go directly from the NIC to device memory for receive and from device memory to NIC for transmit. Packet _headers_ go to/from host memory and are processed by the TCP/IP stack normally. The NIC _must_ support header split to achieve this. Advantages: - Alleviate host memory bandwidth pressure, compared to existing network-transfer + device-copy semantics. - Alleviate PCIe BW pressure, by limiting data transfer to the lowest level of the PCIe tree, compared to traditional path which sends data through the root complex. * Patch overview: ** Part 1: netlink API Gives user ability to bind dma-buf to an RX queue. ** Part 2: scatterlist support Currently the standard for device memory sharing is DMABUF, which doesn't generate struct pages. On the other hand, networking stack (skbs, drivers, and page pool) operate on pages. We have 2 options: 1. Generate struct pages for dmabuf device memory, or, 2. Modify the networking stack to process scatterlist. Approach #1 was attempted in RFC v1. RFC v2 implements approach #2. ** part 3: page pool support We piggy back on page pool memory providers proposal: https://github.com/kuba-moo/linux/tree/pp-providers It allows the page pool to define a memory provider that provides the page allocation and freeing. It helps abstract most of the device memory TCP changes from the driver. ** part 4: support for unreadable skb frags Page pool iovs are not accessible by the host; we implement changes throughput the networking stack to correctly handle skbs with unreadable frags. ** Part 5: recvmsg() APIs We define user APIs for the user to send and receive device memory. Not included with this RFC is the GVE devmem TCP support, just to simplify the review. Code available here if desired: https://github.com/mina/linux/tree/tcpdevmem This RFC is built on top of net-next with Jakub's pp-providers changes cherry-picked. * NIC dependencies: 1. (strict) Devmem TCP require the NIC to support header split, i.e. the capability to split incoming packets into a header + payload and to put each into a separate buffer. Devmem TCP works by using device memory for the packet payload, and host memory for the packet headers. 2. (optional) Devmem TCP works better with flow steering support & RSS support, i.e. the NIC's ability to steer flows into certain rx queues. This allows the sysadmin to enable devmem TCP on a subset of the rx queues, and steer devmem TCP traffic onto these queues and non devmem TCP elsewhere. The NIC I have access to with these properties is the GVE with DQO support running in Google Cloud, but any NIC that supports these features would suffice. I may be able to help reviewers bring up devmem TCP on their NICs. * Testing: The series includes a udmabuf kselftest that show a simple use case of devmem TCP and validates the entire data path end to end without a dependency on a specific dmabuf provider. ** Test Setup Kernel: net-next with this RFC and memory provider API cherry-picked locally. Hardware: Google Cloud A3 VMs. NIC: GVE with header split & RSS & flow steering support. Jakub Kicinski (2): net: page_pool: factor out releasing DMA from releasing the page net: page_pool: create hooks for custom page providers Mina Almasry (10): net: netdev netlink api to bind dma-buf to a net device netdev: support binding dma-buf to netdevice netdev: netdevice devmem allocator memory-provider: dmabuf devmem memory provider page-pool: device memory support net: support non paged skb frags net: add support for skbs with unreadable frags tcp: RX path for devmem TCP net: add SO_DEVMEM_DONTNEED setsockopt to release RX pages selftests: add ncdevmem, netcat for devmem TCP Documentation/netlink/specs/netdev.yaml | 28 ++ include/linux/netdevice.h | 93 ++++ include/linux/skbuff.h | 56 ++- include/linux/socket.h | 1 + include/net/netdev_rx_queue.h | 1 + include/net/page_pool/helpers.h | 151 ++++++- include/net/page_pool/types.h | 55 +++ include/net/sock.h | 2 + include/net/tcp.h | 5 +- include/uapi/asm-generic/socket.h | 6 + include/uapi/linux/netdev.h | 10 + include/uapi/linux/uio.h | 10 + net/core/datagram.c | 6 + net/core/dev.c | 240 +++++++++++ net/core/gro.c | 7 +- net/core/netdev-genl-gen.c | 14 + net/core/netdev-genl-gen.h | 1 + net/core/netdev-genl.c | 118 +++++ net/core/page_pool.c | 209 +++++++-- net/core/skbuff.c | 80 +++- net/core/sock.c | 36 ++ net/ipv4/tcp.c | 205 ++++++++- net/ipv4/tcp_input.c | 13 +- net/ipv4/tcp_ipv4.c | 7 + net/ipv4/tcp_output.c | 5 +- net/packet/af_packet.c | 4 +- tools/include/uapi/linux/netdev.h | 10 + tools/net/ynl/generated/netdev-user.c | 42 ++ tools/net/ynl/generated/netdev-user.h | 47 ++ tools/testing/selftests/net/.gitignore | 1 + tools/testing/selftests/net/Makefile | 5 + tools/testing/selftests/net/ncdevmem.c | 546 ++++++++++++++++++++++++ 32 files changed, 1950 insertions(+), 64 deletions(-) create mode 100644 tools/testing/selftests/net/ncdevmem.c -- 2.42.0.869.gea05f2083d-goog

1 year

12
125
0 0

[PATCH v3 0/3] Add a test to catch unprobed Devicetree devices

by Nícolas F. R. A. Prado

Regressions that cause a device to no longer be probed by a driver can have a big impact on the platform's functionality, and despite being relatively common there isn't currently any generic test to detect them. As an example, bootrr [1] does test for device probe, but it requires defining the expected probed devices for each platform. Given that the Devicetree already provides a static description of devices on the system, it is a good basis for building such a test on top. This series introduces a test to catch regressions that prevent devices from probing. Patches 1 and 2 extend the existing dt-extract-compatibles to be able to output only the compatibles that can be expected to match a Devicetree node to a driver. Patch 2 adds a kselftest that walks over the Devicetree nodes on the current platform and compares the compatibles to the ones on the list, and on an ignore list, to point out devices that failed to be probed. A compatible list is needed because not all compatibles that can show up in a Devicetree node can be used to match to a driver, for example the code for that compatible might use "OF_DECLARE" type macros and avoid the driver framework, or the node might be controlled by a driver that was bound to a different node. An ignore list is needed for the few cases where it's common for a driver to match a device but not probe, like for the "simple-mfd" compatible, where the driver only probes if that compatible is the node's first compatible. The reason for parsing the kernel source instead of relying on information exposed by the kernel at runtime (say, looking at modaliases or introducing some other mechanism), is to be able to catch issues where a config was renamed or a driver moved across configs, and the .config used by the kernel not updated accordingly. We need to parse the source to find all compatibles present in the kernel independent of the current config being run. [1] https://github.com/kernelci/bootrr Changes in v3: - Added DT selftest path to MAINTAINERS - Enabled device probe test for nodes with 'status = "ok"' - Added pass/fail/skip totals to end of test output Changes in v2: - Extended dt-extract-compatibles script to be able to extract driver matching compatibles, instead of adding a new one in Coccinelle - Made kselftest output in the KTAP format Nícolas F. R. A. Prado (3): dt: dt-extract-compatibles: Handle cfile arguments in generator function dt: dt-extract-compatibles: Add flag for driver matching compatibles kselftest: Add new test for detecting unprobed Devicetree devices MAINTAINERS | 1 + scripts/dtc/dt-extract-compatibles | 74 +++++++++++++---- tools/testing/selftests/Makefile | 1 + tools/testing/selftests/dt/.gitignore | 1 + tools/testing/selftests/dt/Makefile | 21 +++++ .../selftests/dt/compatible_ignore_list | 1 + tools/testing/selftests/dt/ktap_helpers.sh | 70 ++++++++++++++++ .../selftests/dt/test_unprobed_devices.sh | 83 +++++++++++++++++++ 8 files changed, 236 insertions(+), 16 deletions(-) create mode 100644 tools/testing/selftests/dt/.gitignore create mode 100644 tools/testing/selftests/dt/Makefile create mode 100644 tools/testing/selftests/dt/compatible_ignore_list create mode 100644 tools/testing/selftests/dt/ktap_helpers.sh create mode 100755 tools/testing/selftests/dt/test_unprobed_devices.sh -- 2.42.0

1 year

6
12
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror November 2023