November 2021 - Linux-kselftest-mirror

[RFC PATCH 00/13] x86 User Interrupts support

by Sohil Mehta

User Interrupts Introduction ============================ User Interrupts (Uintr) is a hardware technology that enables delivering interrupts directly to user space. Today, virtually all communication across privilege boundaries happens by going through the kernel. These include signals, pipes, remote procedure calls and hardware interrupt based notifications. User interrupts provide the foundation for more efficient (low latency and low CPU utilization) versions of these common operations by avoiding transitions through the kernel. In the User Interrupts hardware architecture, a receiver is always expected to be a user space task. However, a user interrupt can be sent by another user space task, kernel or an external source (like a device). In addition to the general infrastructure to receive user interrupts, this series introduces a single source: interrupts from another user task. These are referred to as User IPIs. The first implementation of User IPIs will be in the Intel processor code-named Sapphire Rapids. Refer Chapter 11 of the Intel Architecture instruction set extensions for details of the hardware architecture [1]. Series-reviewed-by: Tony Luck <tony.luck(a)intel.com> Main goals of this RFC ====================== - Introduce this upcoming technology to the community. This cover letter includes a hardware architecture summary along with the software architecture and kernel design choices. This post is a bit long as a result. Hopefully, it helps answer more questions than it creates :) I am also planning to talk about User Interrupts next week at the LPC Kernel summit. - Discuss potential use cases. We are starting to look at actual usages and libraries (like libevent[2] and liburing[3]) that can take advantage of this technology. Unfortunately, we don't have much to share on this right now. We need some help from the community to identify usages that can benefit from this. We would like to make sure the proposed APIs work for the eventual consumers. - Get early feedback on the software architecture. We are hoping to get some feedback on the direction of overall software architecture - starting with User IPI, extending it for kernel-to-user interrupt notifications and external interrupts in the future. - Discuss some of the main architecture opens. There is lot of work that still needs to happen to enable this technology. We are looking for some input on future patches that would be of interest. Here are some of the big opens that we are looking to resolve. * Should Uintr interrupt all blocking system calls like sleep(), read(), poll(), etc? If so, should we implement an SA_RESTART type of mechanism similar to signals? - Refer Blocking for interrupts section below. * Should the User Interrupt Target table (UITT) be shared between threads of a multi-threaded application or maybe even across processes? - Refer Sharing the UITT section below. Why care about this? - Micro benchmark performance ================================================== There is a ~9x or higher performance improvement using User IPI over other IPC mechanisms for event signaling. Below is the average normalized latency for a 1M ping-pong IPC notifications with message size=1. +------------+-------------------------+ | IPC type | Relative Latency | | |(normalized to User IPI) | +------------+-------------------------+ | User IPI | 1.0 | | Signal | 14.8 | | Eventfd | 9.7 | | Pipe | 16.3 | | Domain | 17.3 | +------------+-------------------------+ Results have been estimated based on tests on internal hardware with Linux v5.14 + User IPI patches. Original benchmark: https://github.com/goldsborough/ipc-bench Updated benchmark: https://github.com/intel/uintr-ipc-bench/tree/linux-rfc-v1 *Performance varies by use, configuration and other factors. How it works underneath? - Hardware Summary =========================================== User Interrupts is a posted interrupt delivery mechanism. The interrupts are first posted to a memory location and then delivered to the receiver when they are running with CPL=3. Kernel managed architectural data structures -------------------------------------------- UPID: User Posted Interrupt Descriptor - Holds receiver interrupt vector information and notification state (like an ongoing notification, suppressed notifications). UITT: User Interrupt Target Table - Stores UPID pointer and vector information for interrupt routing on the sender side. Referred by the senduipi instruction. The interrupt state of each task is referenced via MSRs which are saved and restored by the kernel during context switch. Instructions ------------ senduipi <index> - send a user IPI to a target task based on the UITT index. clui - Mask user interrupts by clearing UIF (User Interrupt Flag). stui - Unmask user interrupts by setting UIF. testui - Test current value of UIF. uiret - return from a user interrupt handler. User IPI -------- When a User IPI sender executes 'senduipi <index>', the hardware refers the UITT table entry pointed by the index and posts the interrupt vector (63-0) into the receiver's UPID. If the receiver is running (CPL=3), the sender cpu would send a physical IPI to the receiver's cpu. On the receiver side this IPI is detected as a User Interrupt. The User Interrupt handler for the receiver is invoked and the vector number (63-0) is pushed onto the stack. Upon execution of 'uiret' in the interrupt handler, the control is transferred back to instruction that was interrupted. Refer Chapter 11 of the Intel Architecture instruction set extensions [1] for more details. Application interface - Software Architecture ============================================= User Interrupts (Uintr) is an opt-in feature (unlike signals). Applications wanting to use Uintr are expected to register themselves with the kernel using the Uintr related system calls. A Uintr receiver is always a userspace task. A Uintr sender can be another userspace task, kernel or a device. 1) A receiver can register/unregister an interrupt handler using the Uintr receiver related syscalls. uintr_register_handler(handler, flags) uintr_unregister_handler(flags) 2) A syscall also allows a receiver to register a vector and create a user interrupt file descriptor - uintr_fd. uintr_fd = uintr_create_fd(vector, flags) Uintr can be useful in some of the usages where eventfd or signals are used for frequent userspace event notifications. The semantics of uintr_fd are somewhat similar to an eventfd() or the write end of a pipe. 3) Any sender with access to uintr_fd can use it to deliver events (in this case - interrupts) to a receiver. A sender task can manage its connection with the receiver using the sender related syscalls based on uintr_fd. uipi_index = uintr_register_sender(uintr_fd, flags) Using an FD abstraction provides a secure mechanism to connect with a receiver. The FD sharing and isolation mechanisms put in place by the kernel would extend to Uintr as well. 4a) After the initial setup, a sender task can use the SENDUIPI instruction along with the uipi_index to generate user IPIs without any kernel intervention. SENDUIPI <uipi_index> If the receiver is running (CPL=3), then the user interrupt is delivered directly without a kernel transition. If the receiver isn't running the interrupt is delivered when the receiver gets context switched back. If the receiver is blocked in the kernel, the user interrupt is delivered to the kernel which then unblocks the intended receiver to deliver the interrupt. 4b) If the sender is the kernel or a device, the uintr_fd can be passed onto the related kernel entity to allow them to setup a connection and then generate a user interrupt for event delivery. <The exact details of this API are still being worked upon.> For details of the user interface and associated system calls refer the Uintr man-pages draft: https://github.com/intel/uintr-linux-kernel/tree/rfc-v1/tools/uintr/manpages. We have also included the same content as patch 1 of this series to make it easier to review. Refer the Uintr compiler programming guide [4] for details on Uintr integration with GCC and Binutils. Kernel design choices ===================== Here are some of the reasons and trade-offs for the current design of the APIs. System call interface --------------------- Why a system call interface?: The 2 options we considered are using a char device at /dev or use system calls (current approach). A syscall approach avoids exposing a core cpu feature through a driver model. Also, we want to have a user interrupt FD per vector and share a single common interrupt handler among all vectors. This seems easier for the kernel and userspace to accomplish using a syscall based approach. Data sharing using user interrupts: Uintr doesn't include a mechanism to share/transmit data. The expectation is applications use existing data sharing mechanisms to share data and use Uintr only for signaling. An FD for each vector: A uintr_fd is assigned to each vector to allow fine grained priority and event management by the receiver. The alternative we considered was to allocate an FD to the interrupt handler and having that shared with the sender. However, that approach relies on the sender selecting the vector and moves the vector priority management to the sender. Also, if multiple senders want to send unique user interrupts they would need to coordinate the vector selection amongst them. Extending the APIs: Currently, the system calls are only extendable using the flags argument. We can add a variable size struct to some of the syscalls if needed. Extending existing mechanisms ----------------------------- Uintr can be beneficial in some of the usages where eventfd() or signals are used. Since Uintr is hardware-dependent, thread-specific and bypasses the kernel in the fast path, it makes extending existing mechanisms harder. Main issues with extending signals: Signal handlers are defined significantly differently than a User interrupt handler. An application needs to save/restore registers in a user interrupt handler and call uiret to return from it. Also, signals can be process directed (or thread directed) but user interrupts are always thread directed. Comparison of signals with User Interrupts: +=====================+===========================+===========================+ | | Signals | User Interrupts | +=====================+===========================+===========================+ | Stacks | Has alt stacks | Uses application stack | | | | (alternate stack option | | | | not yet enabled) | +---------------------+---------------------------+---------------------------+ | Registers state | Kernel manages incl. | App responsible (Use GCC | | | FPU/XSTATE area | 'interrupt' attribute for | | | | general purpose registers)| +---------------------+---------------------------+---------------------------+ | Blocking/Masking | sigprocmask(2)/sa_mask | CLUI instruction (No per | | | | vector masking) | +---------------------+---------------------------+---------------------------+ | Direction | Uni-directional | Uni-directional | +---------------------+---------------------------+---------------------------+ | Post event | kill(), signal(), | SENDUIPI <index> - index | | | sigqueue(), etc. | derived from uintr_fd | +---------------------+---------------------------+---------------------------+ | Target | Process-directed or | Thread-directed | | | thread-directed | | +---------------------+---------------------------+---------------------------+ | Fork/inheritance | Empty signal set | Nothing is inherited | +---------------------+---------------------------+---------------------------+ | Execv | Pending signals preserved | Nothing is inherited | +---------------------+---------------------------+---------------------------+ | Order of delivery | Undetermined | High to low vector numbers| | for multiple signals| | | +---------------------+---------------------------+---------------------------+ | Handler re-entry | All signals except the | No interrupts can cause | | | one being handled | handler re-entry. | +---------------------+---------------------------+---------------------------+ | Delivery feedback | 0 or -1 based on whether | No feedback on whether the| | | the signal was sent | interrupt was sent or | | | | received. | +---------------------+---------------------------+---------------------------+ Main issues with extending eventfd(): eventfd() has a counter value that is core to the API. User interrupts can't have an associated counter since the signaling happens at the user level and the hardware doesn't have a memory counter mechanism. Also, eventfd can be used for bi-directional signaling where as uintr_fd is uni-directional. Comparison of eventfd with uintr_fd: +====================+======================+==============================+ | | Eventfd | uintr_fd (User Interrupt FD) | +====================+======================+==============================+ | Object | Counter - uint64 | Receiver vector information | +--------------------+----------------------+------------------------------+ | Post event | write() to eventfd | SENDUIPI <index> - index | | | | derived from uintr_fd | +--------------------+----------------------+------------------------------+ | Receive event | read() on eventfd | Implicit - Handler is | | | | invoked with associated | | | | vector. | +--------------------+----------------------+------------------------------+ | Direction | Bi-directional | Uni-directional | +--------------------+----------------------+------------------------------+ | Data transmitted | Counter - uint64 | None | +--------------------+----------------------+------------------------------+ | Waiting for events | Poll() family of | No per vector wait. | | | syscalls | uintr_wait() allows waiting | | | | for all user interrupts | +--------------------+----------------------+------------------------------+ Security Model ============== User Interrupts is designed as an opt-in feature (unlike signals). The security model for user interrupts is intended to be similar to eventfd(). The general idea is that any sender with access to uintr_fd would be able to generate the associated interrupt vector for the receiver task that created the fd. Untrusted processes ------------------- The current implementation expects only trusted and cooperating processes to communicate using user interrupts. Coordination is expected between processes for a connection teardown. In situations where coordination doesn't happen (say, due to abrupt process exit), the kernel would end up keeping shared resources (like UPID) allocated to avoid faults. Currently, a sender can easily cause a denial of service for the receiver by generating a storm of user interrupts. A user interrupt handler is invoked with interrupts disabled, but upon execution of uiret, interrupts get enabled again by the hardware. This can lead to the handler being invoked again before normal execution can resume. There isn't a hardware mechanism to mask specific interrupt vectors. To enable untrusted processes to communicate, we need to add a per-vector masking option through another syscall (or maybe IOCTL). However, this can add some complexity to the kernel code. A vector can only be masked by modifying the UITT entries at the source. We need to be careful about races while removing and restoring the UPID from the UITT. Resource limits --------------- The maximum number of receiver-sender connections would be limited by the maximum number of open file descriptors and the size of the UITT. The UITT size is chosen as 4kB fixed size arbitrarily right now. We plan to make it dynamic and configurable in size. RLIMIT_MEMLOCK or ENOMEM should be triggered when the size limits have been hit. Main Opens ========== Blocking for interrupts ----------------------- User interrupts are delivered to applications immediately if they are running in userspace. If a receiver task has blocked in the kernel using the placeholder uintr_wait() syscall, the task would be woken up to deliver the user interrupt. However, if the task is blocked due to any other blocking calls like read(), sleep(), etc; the interrupt will only get delivered when the application gets scheduled again. We need to consider if applications need to receive User Interrupts as soon as they are posted (similar to signals) when they are blocked due to some other reason. Adding this capability would likely make the kernel implementation more complex. Interrupting system calls using User Interrupts would also mean we need to consider an SA_RESTART type of mechanism. We also need to evaluate if some of the signal handler related semantics in the kernel can be reused for User Interrupts. Sharing the User Interrupt Target Table (UITT) ---------------------------------------------- The current implementation assigns a unique UITT to each task. This assumes that User interrupts are used for point-to-point communication between 2 tasks. Also, this keeps the kernel implementation relatively simple. However, there are of benefits to sharing the UITT between threads of a multi-threaded application. One, they would see a consistent view of the UITT. i.e. SENDUIPI <index> would mean the same on all threads of the application. Also, each thread doesn't have to register itself using the common uintr_fd. This would simplify the userspace setup and make efficient use of kernel memory. The potential downside is that the kernel implementation to allocate, modify, expand and free the UITT would be more complex. A similar argument can be made for a set of processes that do a lot of IPC amongst them. They would prefer to have a shared UITT that lets them target any process from any process. With the current file descriptor based approach, the connection setup can be time consuming and somewhat cumbersome. We need to evaluate if this can be made simpler as well. Kernel page table isolation (KPTI) ---------------------------------- SENDUIPI is a special ring-3 instruction that makes a supervisor mode memory access to the UPID and UITT memory. The current patches need KPTI to be disabled for User IPIs to work. To make User IPI work with KPTI, we need to allocate these structures from a special memory region that has supervisor access but it is mapped into userspace. The plan is to implement a mechanism similar to LDT. Processors that support user interrupts are not affected by Meltdown so the auto mode of KPTI will default to off. Users who want to force enable KPTI will need to wait for a later version of this patch series to use user interrupts. Please let us know if you want the development of these patches to be prioritized (or deprioritized). FAQs ==== Q: What happens if a process is "surprised" by a user interrupt? A: For tasks that haven't registered with the kernel and requested for user interrupts aren't expected or able to receive to user interrupts. Q: Do user interrupts affect kernel scheduling? A: No. If a task is blocked waiting for user interrupts, when the kernel receives a notification on behalf of that task we only put it back on the runqueue. Delivery of a user interrupt in no way changes the scheduling priorities of a task. Q: Does the sender get to know if the interrupt was delivered? A: No. User interrupts only provides a posted interrupt delivery mechanism. If applications need to rely on whether the interrupt was delivered they should consider a userspace mechanism for feedback (like a shared memory counter or a user interrupt back to the sender). Q: Why is there no feedback on interrupt delivery? A: Being a posted interrupt delivery mechanism, the interrupt delivery happens in 2 steps: 1) The interrupt information is stored in a memory location (UPID). 2) The physical interrupt is delivered to the interrupt receiver. The 2nd step could happen immediately, after an extended period, or it might never happen based on the state of the receiver after step 1. (The receiver could have disabled interrupts, have been context switched out or it might have crashed during that time.) This makes it very hard for the hardware to reliably provide feedback upon execution of SENDUIPI. Q: Can user interrupts be nested? A: Yes. Using STUI instruction in the interrupt handler would allow new user interrupts to be delivered. However, there no TPR(thread priority register) like mechanism to allow only higher priority interrupts. Any user interrupt can be taken when nesting is enabled. Q: Can a task receive all pending user interrupts in one go? A: No. The hardware allows only one vector to be processed at a time. If a task is interested in knowing all the interrupts that are pending then we could add a syscall that provides the pending interrupts information. Q: Do the processes need to be pinned to a cpu? A: No. User interrupts will be routed correctly to whichever cpu the receiver is running on. The kernel updates the cpu information in the UPID during context switch. Q: Why are UPID and UITT allocated by the kernel? A: If allocated by user space, applications could misuse the UPID and UITT to write to unauthorized memory and generate interrupts on any cpu. The UPID and UITT are allocated by the kernel and accessed by the hardware with supervisor privilege. Patch structure for this series =============================== - Man-pages and Kernel documentation (patch 1,2) - Hardware enumeration (patch 3, 4) - User IPI kernel vector reservation (patch 5) - Syscall interface for interrupt receiver, sender and vector management(uintr_fd) (patch 6-12) - Basic selftests (patch 13) Along with the patches in this RFC, there are additional tests and samples that are available at: https://github.com/intel/uintr-linux-kernel/tree/rfc-v1 Links ===== [1]: https://software.intel.com/content/www/us/en/develop/download/intel-archite… [2]: https://libevent.org/ [3]: https://github.com/axboe/liburing [4]: https://github.com/intel/uintr-compiler-guide/blob/uintr-gcc-11.1/UINTR-com… Sohil Mehta (13): x86/uintr/man-page: Include man pages draft for reference Documentation/x86: Add documentation for User Interrupts x86/cpu: Enumerate User Interrupts support x86/fpu/xstate: Enumerate User Interrupts supervisor state x86/irq: Reserve a user IPI notification vector x86/uintr: Introduce uintr receiver syscalls x86/process/64: Add uintr task context switch support x86/process/64: Clean up uintr task fork and exit paths x86/uintr: Introduce vector registration and uintr_fd syscall x86/uintr: Introduce user IPI sender syscalls x86/uintr: Introduce uintr_wait() syscall x86/uintr: Wire up the user interrupt syscalls selftests/x86: Add basic tests for User IPI .../admin-guide/kernel-parameters.txt | 2 + Documentation/x86/index.rst | 1 + Documentation/x86/user-interrupts.rst | 107 +++ arch/x86/Kconfig | 12 + arch/x86/entry/syscalls/syscall_32.tbl | 6 + arch/x86/entry/syscalls/syscall_64.tbl | 6 + arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/disabled-features.h | 8 +- arch/x86/include/asm/entry-common.h | 4 + arch/x86/include/asm/fpu/types.h | 20 +- arch/x86/include/asm/fpu/xstate.h | 3 +- arch/x86/include/asm/hardirq.h | 4 + arch/x86/include/asm/idtentry.h | 5 + arch/x86/include/asm/irq_vectors.h | 6 +- arch/x86/include/asm/msr-index.h | 8 + arch/x86/include/asm/processor.h | 8 + arch/x86/include/asm/uintr.h | 76 ++ arch/x86/include/uapi/asm/processor-flags.h | 2 + arch/x86/kernel/Makefile | 1 + arch/x86/kernel/cpu/common.c | 61 ++ arch/x86/kernel/cpu/cpuid-deps.c | 1 + arch/x86/kernel/fpu/core.c | 17 + arch/x86/kernel/fpu/xstate.c | 20 +- arch/x86/kernel/idt.c | 4 + arch/x86/kernel/irq.c | 51 + arch/x86/kernel/process.c | 10 + arch/x86/kernel/process_64.c | 4 + arch/x86/kernel/uintr_core.c | 880 ++++++++++++++++++ arch/x86/kernel/uintr_fd.c | 300 ++++++ include/linux/syscalls.h | 8 + include/uapi/asm-generic/unistd.h | 15 +- kernel/sys_ni.c | 8 + scripts/checksyscalls.sh | 6 + tools/testing/selftests/x86/Makefile | 10 + tools/testing/selftests/x86/uintr.c | 147 +++ tools/uintr/manpages/0_overview.txt | 265 ++++++ tools/uintr/manpages/1_register_receiver.txt | 122 +++ .../uintr/manpages/2_unregister_receiver.txt | 62 ++ tools/uintr/manpages/3_create_fd.txt | 104 +++ tools/uintr/manpages/4_register_sender.txt | 121 +++ tools/uintr/manpages/5_unregister_sender.txt | 79 ++ tools/uintr/manpages/6_wait.txt | 59 ++ 42 files changed, 2626 insertions(+), 8 deletions(-) create mode 100644 Documentation/x86/user-interrupts.rst create mode 100644 arch/x86/include/asm/uintr.h create mode 100644 arch/x86/kernel/uintr_core.c create mode 100644 arch/x86/kernel/uintr_fd.c create mode 100644 tools/testing/selftests/x86/uintr.c create mode 100644 tools/uintr/manpages/0_overview.txt create mode 100644 tools/uintr/manpages/1_register_receiver.txt create mode 100644 tools/uintr/manpages/2_unregister_receiver.txt create mode 100644 tools/uintr/manpages/3_create_fd.txt create mode 100644 tools/uintr/manpages/4_register_sender.txt create mode 100644 tools/uintr/manpages/5_unregister_sender.txt create mode 100644 tools/uintr/manpages/6_wait.txt base-commit: 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f -- 2.33.0

2 years, 3 months

13
86
0 0

[PATCH v4 0/2] selftests: tpm2: Determine available PCR bank

by Stefan Berger

From: Stefan Berger <stefanb(a)linux.ibm.com> This series of patches fixes two issues with TPM2 selftest. - Determines available PCR banks for use by test cases - Resets DA lock on TPM2 to avoid subsequent test failures Stefan v4: - Switch to query TPM2_GET_CAP to determine the available PCR banks - Moved call to reset DA lock into finally branch at end of test - Dropped patch 3 v3: - Mention SHA-256 PCR bank as alternative in patch 1 description v2: - Clarified patch 1 description - Added patch 3 with support for SHA-384 and SHA-512 Stefan Berger (2): selftests: tpm2: Determine available PCR bank selftests: tpm2: Reset the dictionary attack lock tools/testing/selftests/tpm2/tpm2.py | 31 ++++++++++++++++++++++ tools/testing/selftests/tpm2/tpm2_tests.py | 31 ++++++++++++++++------ 2 files changed, 54 insertions(+), 8 deletions(-) -- 2.31.1

2 years, 3 months

3
12
0 0

[PATCH 1/3] selftest/kexec: fix "ignored null byte in input" warning

by Nageswara R Sastry

From: Mimi Zohar <zohar(a)linux.ibm.com> Instead of assigning the string to a variable, which might contain a null character, redirect the output and grep for the string directly. Signed-off-by: Mimi Zohar <zohar(a)linux.ibm.com> --- tools/testing/selftests/kexec/test_kexec_file_load.sh | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/kexec/test_kexec_file_load.sh b/tools/testing/selftests/kexec/test_kexec_file_load.sh index 2ff600388c30..99f6fc23ee31 100755 --- a/tools/testing/selftests/kexec/test_kexec_file_load.sh +++ b/tools/testing/selftests/kexec/test_kexec_file_load.sh @@ -97,10 +97,11 @@ check_for_imasig() check_for_modsig() { local module_sig_string="~Module signature appended~" - local sig="$(tail --bytes $((${#module_sig_string} + 1)) $KERNEL_IMAGE)" local ret=0 - if [ "$sig" == "$module_sig_string" ]; then + tail --bytes $((${#module_sig_string} + 1)) $KERNEL_IMAGE | \ + grep -q "$module_sig_string" + if [ $? -eq 0 ]; then ret=1 log_info "kexec kernel image modsig signed" else -- 2.23.0

2 years, 3 months

3
4
0 0

[PATCH v2 0/4] KVM RISC-V 64-bit selftests support

by Anup Patel

This series adds initial support for testing KVM RISC-V 64-bit using kernel selftests framework. The PATCH1 & PATCH2 of this series does some ground work in KVM RISC-V to implement RISC-V support in the KVM selftests whereas remaining patches does required changes in the KVM selftests. These patches can be found in riscv_kvm_selftests_v2 branch at: https://github.com/avpatel/linux.git Changes since v1: - Renamed kvm_sbi_ext_expevend_handler() to kvm_sbi_ext_forward_handler() in PATCH1 - Renamed KVM_CAP_RISCV_VM_GPA_SIZE to KVM_CAP_VM_GPA_BITS in PATCH2 and PATCH4 Anup Patel (4): RISC-V: KVM: Forward SBI experimental and vendor extensions RISC-V: KVM: Add VM capability to allow userspace get GPA bits KVM: selftests: Add EXTRA_CFLAGS in top-level Makefile KVM: selftests: Add initial support for RISC-V 64-bit arch/riscv/include/asm/kvm_host.h | 1 + arch/riscv/kvm/mmu.c | 5 + arch/riscv/kvm/vcpu_sbi.c | 4 + arch/riscv/kvm/vcpu_sbi_base.c | 27 ++ arch/riscv/kvm/vm.c | 3 + include/uapi/linux/kvm.h | 1 + tools/testing/selftests/kvm/Makefile | 14 +- .../testing/selftests/kvm/include/kvm_util.h | 10 + .../selftests/kvm/include/riscv/processor.h | 135 +++++++ tools/testing/selftests/kvm/lib/guest_modes.c | 10 + .../selftests/kvm/lib/riscv/processor.c | 362 ++++++++++++++++++ tools/testing/selftests/kvm/lib/riscv/ucall.c | 87 +++++ 12 files changed, 658 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/kvm/include/riscv/processor.h create mode 100644 tools/testing/selftests/kvm/lib/riscv/processor.c create mode 100644 tools/testing/selftests/kvm/lib/riscv/ucall.c -- 2.25.1

2 years, 4 months

5
14
0 0

[PATCH 1/2] kselftest: signal all child processes

by Li Zhijian

We have some many cases that will create child process as well, such as pidfd_wait. Previously, we will signal/kill the parent process when it is time out, but this signal will not be sent to its child process. In such case, if child process doesn't terminate itself, ksefltest framework will hang forever. below ps tree show the situation when ksefltest is blocking: root 1172 0.0 0.0 5996 2500 ? S 07:03 0:00 \_ /bin/bash /lkp/lkp/src/tests/kernel-selftests root 1216 0.0 0.0 4392 1976 ? S 07:03 0:00 \_ make run_tests -C pidfd root 1218 0.0 0.0 2396 1652 ? S 07:03 0:00 \_ /bin/sh -c BASE_DIR="/usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests"; . /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/kselftest/runner.sh; if [ "X" != "X" ]; then per_test_logging=1; fi; run_many /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_fdinfo_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_open_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_poll_test /usr/src/perf_selftests-x86_64-rhel- 8. root 12491 0.0 0.0 2396 132 ? S 07:03 0:00 \_ /bin/sh -c BASE_DIR="/usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests"; . /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/kselftest/runner.sh; if [ "X" != "X" ]; then per_test_logging=1; fi; run_many /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_fdinfo_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_open_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_poll_test /usr/src/perf_selftests-x86_64-r he root 12492 0.0 0.0 2396 132 ? S 07:03 0:00 \_ /bin/sh -c BASE_DIR="/usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests"; . /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/kselftest/runner.sh; if [ "X" != "X" ]; then per_test_logging=1; fi; run_many /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_fdinfo_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_open_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_poll_test /usr/src/perf_selftests-x86_ 64 root 12493 0.0 0.0 2396 132 ? S 07:03 0:00 \_ /bin/sh -c BASE_DIR="/usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests"; . /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/kselftest/runner.sh; if [ "X" != "X" ]; then per_test_logging=1; fi; run_many /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_fdinfo_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_open_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_poll_test /usr/src/perf_selftests- x8 root 12496 0.0 0.0 2396 132 ? S 07:03 0:00 \_ /bin/sh -c BASE_DIR="/usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests"; . /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/kselftest/runner.sh; if [ "X" != "X" ]; then per_test_logging=1; fi; run_many /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_fdinfo_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_open_test /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/pidfd/pidfd_poll_test /usr/src/perf_selfte st root 12498 0.0 0.0 10564 6116 ? S 07:03 0:00 \_ perl /usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-519d81956ee277b4419c723adfb154603c2565ba/tools/testing/selftests/kselftest/prefix.pl root 12503 0.0 0.0 2452 112 ? T 07:03 0:00 ./pidfd_wait root 12621 0.0 0.0 2372 1600 ? SLs 07:04 0:00 /usr/sbin/watchdog root 19438 0.0 0.0 992 60 ? Ss 07:39 0:00 /lkp/lkp/src/bin/event/wakeup activate-monitor Here we group all its child processes so that kill() can signal all of them in timeout. CC: Kees Cook <keescook(a)chromium.org> CC: Andy Lutomirski <luto(a)amacapital.net> CC: Will Drewry <wad(a)chromium.org> CC: Shuah Khan <shuah(a)kernel.org> CC: Christian Brauner <christian(a)brauner.io> CC: Philip Li <philip.li(a)intel.com> Suggested-by: yang xu <xuyang2018.jy(a)cn.fujitsu.com> Signed-off-by: Li Zhijian <lizhijian(a)cn.fujitsu.com> --- tools/testing/selftests/kselftest_harness.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/kselftest_harness.h b/tools/testing/selftests/kselftest_harness.h index ae0f0f33b2a6..c7251396e7ee 100644 --- a/tools/testing/selftests/kselftest_harness.h +++ b/tools/testing/selftests/kselftest_harness.h @@ -875,7 +875,8 @@ static void __timeout_handler(int sig, siginfo_t *info, void *ucontext) } t->timed_out = true; - kill(t->pid, SIGKILL); + // signal process group + kill(-(t->pid), SIGKILL); } void __wait_for_test(struct __test_metadata *t) @@ -985,6 +986,7 @@ void __run_test(struct __fixture_metadata *f, ksft_print_msg("ERROR SPAWNING TEST CHILD\n"); t->passed = 0; } else if (t->pid == 0) { + setpgrp(); t->fn(t, variant); if (t->skip) _exit(255); -- 2.33.0

2 years, 4 months

4
9
0 0

[PATCH v6 00/37] arm64/sme: Initial support for the Scalable Matrix Extension

by Mark Brown

This series provides initial support for the ARMv9 Scalable Matrix Extension (SME). SME takes the approach used for vectors in SVE and extends this to provide architectural support for matrix operations. A more detailed overview can be found in [1]. For the kernel SME can be thought of as a series of features which are intended to be used together by applications but operate mostly orthogonally: - The ZA matrix register. - Streaming mode, in which ZA can be accessed and a subset of SVE features are available. - A second vector length, used for streaming mode SVE and ZA and controlled using a similar interface to that for SVE. - TPIDR2, a new userspace controllable system register intended for use by the C library for storing context related to the ZA ABI. A substantial part of the series is dedicated to refactoring the existing SVE support so that we don't need to duplicate code for handling vector lengths and the SVE registers, this involves creating an array of vector types and making the users take the vector type as a parameter. I'm not 100% happy with this but wasn't able to come up with anything better, duplicating code definitely felt like a bad idea so this felt like the least bad thing. If this approach makes sense to people it might make sense to split this off into a separate series and/or merge it while the rest is pending review to try to make things a little more digestable, the series is very large so it'd probably make things easier to digest if some of the preparatory refactoring could be merged before the rest is ready. One feature of the architecture of particular note is that switching to and from streaming mode may change the size of and invalidate the contents of the SVE registers, and when in streaming mode the FFR is not accessible. This complicates aspects of the ABI like signal handling and ptrace. This initial implementation is mainly intended to get the ABI in place, there are several areas which will be worked on going forwards - some of these will be blockers, others could be handled in followup serieses: - KVM is not currently supported and we depend on !KVM, this is obviously not good - in hopefully the next version I will add support for coexisting with KVM and then in a subsequent series implement support for use of SME by KVM guests. - It is likely some build configurations have issues, I've not fully checked this yet. In general testing is still ongoing, I anticipate finding and fixing some issues in the implementation. - No support is currently provided for scheduler control of SME or SME applications, given the size of the SME register state the context switch overhead may be noticable so this may be needed especially for real time applications. Similar concerns already exist for larger SVE vector lengths but are amplified for SME, particularly as the vector length increases. - There has been no work on optimising the performance of anything the kernel does. It is not expected that any systems will be encountered that support SME but not SVE, SME is an ARMv9 feature and SVE is mandatory for ARMv9. The code attempts to handle any such systems that are encountered but this hasn't been tested extensively. Due to dependencies on changes already upstreamed this series is based on a merge of for-next/kselftest and for-next/sve in the arm64 tree. v6: - Rebase onto v5.16-rc1. - Return to disabling TIF_SVE on kernel entry even if we have SME state, this avoids the need for KVM to handle the case where TIF_SVE is set on guest entry. - Add syscall-abi.h to SME updates to syscall-abi, mistakenly omitted from commit. v5: - Rebase onto currently merged SVE and kselftest patches. - Add support for the FA64 option, introduced in the recently published EAC1 update to the specification. - Pull in test program for the syscall ABI previously sent separately with some revisions and add coverage for the SME ABI. - Fix checking for options with 1 bit fields in ID_AA64SMFR0_EL1. - Minor fixes and clarifications to the ABI documentation. v4: - Rebase onto merged patches. - Remove an uneeded NULL check in vec_proc_do_default_vl(). - Include patch to factor out utility routines in kselftests written in assembler. - Specify -ffreestanding when building TPIDR2 test. v3: - Skip FFR rather than predicate registers in sve_flush_live(). - Don't assume a bool is all zeros in sve_flush_live() as per AAPCS. - Don't redundantly specify a zero index when clearing FFR. v2: - Fix several issues with !SME and !SVE configurations. - Preserve TPIDR2 when creating a new thread/process unless CLONE_SETTLS is set. - Report traps due to using features in an invalid mode as SIGILL. - Spell out streaming mode behaviour in SVE ABI documentation more directly. - Document TPIDR2 in the ABI document. - Use SMSTART and SMSTOP rather than read/modify/write sequences. - Rework logic for exiting streaming mode on syscall. - Don't needlessly initialise SVCR on access trap. - Always restore SME VL for userspace if SME traps are disabled. - Only yield to encourage preemption every 128 iterations in za-test, otherwise do a getpid(), and validate SVCR after syscall. - Leave streaming mode disabled except when reading the vector length in za-test, and disable ZA after detecting a mismatch. - Add SME support to vlset. - Clarifications and typo fixes in comments. - Move sme_alloc() forward declaration back a patch. [1] https://community.arm.com/developer/ip-products/processors/b/processors-ip-… Mark Brown (37): arm64/sve: Make sysctl interface for SVE reusable by SME arm64/sve: Generalise vector length configuration prctl() for SME arm64/sve: Minor clarification of ABI documentation kselftest/arm64: Parameterise ptrace vector length information kselftest/arm64: Allow signal tests to trigger from a function kselftest/arm64: Add a test program to exercise the syscall ABI tools/nolibc: Implement gettid() arm64: cpufeature: Add has_feature_flag() match function arm64/sme: Provide ABI documentation for SME arm64/sme: System register and exception syndrome definitions arm64/sme: Define macros for manually encoding SME instructions arm64/sme: Early CPU setup for SME arm64/sme: Basic enumeration support arm64/sme: Identify supported SME vector lengths at boot arm64/sme: Implement sysctl to set the default vector length arm64/sme: Implement vector length configuration prctl()s arm64/sme: Implement support for TPIDR2 arm64/sme: Implement SVCR context switching arm64/sme: Implement streaming SVE context switching arm64/sme: Implement ZA context switching arm64/sme: Implement traps and syscall handling for SME arm64/sme: Implement streaming SVE signal handling arm64/sme: Implement ZA signal handling arm64/sme: Implement ptrace support for streaming mode SVE registers arm64/sme: Add ptrace support for ZA arm64/sme: Disable streaming mode and ZA when flushing CPU state arm64/sme: Save and restore streaming mode over EFI runtime calls arm64/sme: Provide Kconfig for SME kselftest/arm64: sme: Add streaming SME support to vlset kselftest/arm64: Add tests for TPIDR2 kselftest/arm64: Extend vector configuration API tests to cover SME kselftest/arm64: sme: Provide streaming mode SVE stress test kselftest/arm64: Add stress test for SME ZA context switching kselftest/arm64: signal: Add SME signal handling tests kselftest/arm64: Add streaming SVE to SVE ptrace tests kselftest/arm64: Add coverage for the ZA ptrace interface kselftest/arm64: Add SME support to syscall ABI test Documentation/arm64/elf_hwcaps.rst | 33 + Documentation/arm64/index.rst | 1 + Documentation/arm64/sme.rst | 430 ++++++++++++ Documentation/arm64/sve.rst | 72 +- arch/arm64/Kconfig | 11 + arch/arm64/include/asm/cpu.h | 4 + arch/arm64/include/asm/cpufeature.h | 24 + arch/arm64/include/asm/el2_setup.h | 45 ++ arch/arm64/include/asm/esr.h | 13 +- arch/arm64/include/asm/exception.h | 1 + arch/arm64/include/asm/fpsimd.h | 112 ++- arch/arm64/include/asm/fpsimdmacros.h | 77 ++ arch/arm64/include/asm/hwcap.h | 8 + arch/arm64/include/asm/kvm_arm.h | 1 + arch/arm64/include/asm/processor.h | 18 +- arch/arm64/include/asm/sysreg.h | 58 ++ arch/arm64/include/asm/thread_info.h | 2 + arch/arm64/include/uapi/asm/hwcap.h | 8 + arch/arm64/include/uapi/asm/ptrace.h | 69 +- arch/arm64/include/uapi/asm/sigcontext.h | 55 +- arch/arm64/kernel/cpufeature.c | 130 ++++ arch/arm64/kernel/cpuinfo.c | 13 + arch/arm64/kernel/entry-common.c | 10 + arch/arm64/kernel/entry-fpsimd.S | 31 + arch/arm64/kernel/fpsimd.c | 657 ++++++++++++++++-- arch/arm64/kernel/process.c | 28 +- arch/arm64/kernel/ptrace.c | 358 ++++++++-- arch/arm64/kernel/signal.c | 187 ++++- arch/arm64/kernel/syscall.c | 34 +- arch/arm64/kernel/traps.c | 1 + arch/arm64/kvm/fpsimd.c | 3 +- arch/arm64/kvm/reset.c | 8 +- arch/arm64/tools/cpucaps | 2 + include/uapi/linux/elf.h | 2 + include/uapi/linux/prctl.h | 9 + kernel/sys.c | 12 + tools/include/nolibc/nolibc.h | 18 + tools/testing/selftests/arm64/Makefile | 2 +- tools/testing/selftests/arm64/abi/.gitignore | 2 + tools/testing/selftests/arm64/abi/Makefile | 15 + .../selftests/arm64/abi/syscall-abi-asm.S | 307 ++++++++ .../testing/selftests/arm64/abi/syscall-abi.c | 485 +++++++++++++ .../testing/selftests/arm64/abi/syscall-abi.h | 15 + tools/testing/selftests/arm64/abi/tpidr2.c | 298 ++++++++ tools/testing/selftests/arm64/fp/.gitignore | 4 + tools/testing/selftests/arm64/fp/Makefile | 12 +- tools/testing/selftests/arm64/fp/rdvl-sme.c | 14 + tools/testing/selftests/arm64/fp/rdvl.S | 16 + tools/testing/selftests/arm64/fp/rdvl.h | 1 + tools/testing/selftests/arm64/fp/ssve-stress | 59 ++ tools/testing/selftests/arm64/fp/sve-ptrace.c | 230 ++++-- tools/testing/selftests/arm64/fp/sve-test.S | 30 + tools/testing/selftests/arm64/fp/vec-syscfg.c | 10 + tools/testing/selftests/arm64/fp/vlset.c | 10 +- tools/testing/selftests/arm64/fp/za-ptrace.c | 353 ++++++++++ tools/testing/selftests/arm64/fp/za-stress | 59 ++ tools/testing/selftests/arm64/fp/za-test.S | 431 ++++++++++++ .../testing/selftests/arm64/signal/.gitignore | 2 + .../selftests/arm64/signal/test_signals.h | 2 + .../arm64/signal/test_signals_utils.c | 5 +- .../testcases/fake_sigreturn_sme_change_vl.c | 92 +++ .../arm64/signal/testcases/sme_trap_za.c | 36 + .../selftests/arm64/signal/testcases/sme_vl.c | 70 ++ .../arm64/signal/testcases/ssve_regs.c | 129 ++++ 64 files changed, 4986 insertions(+), 248 deletions(-) create mode 100644 Documentation/arm64/sme.rst create mode 100644 tools/testing/selftests/arm64/abi/.gitignore create mode 100644 tools/testing/selftests/arm64/abi/Makefile create mode 100644 tools/testing/selftests/arm64/abi/syscall-abi-asm.S create mode 100644 tools/testing/selftests/arm64/abi/syscall-abi.c create mode 100644 tools/testing/selftests/arm64/abi/syscall-abi.h create mode 100644 tools/testing/selftests/arm64/abi/tpidr2.c create mode 100644 tools/testing/selftests/arm64/fp/rdvl-sme.c create mode 100644 tools/testing/selftests/arm64/fp/ssve-stress create mode 100644 tools/testing/selftests/arm64/fp/za-ptrace.c create mode 100644 tools/testing/selftests/arm64/fp/za-stress create mode 100644 tools/testing/selftests/arm64/fp/za-test.S create mode 100644 tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_sme_change_vl.c create mode 100644 tools/testing/selftests/arm64/signal/testcases/sme_trap_za.c create mode 100644 tools/testing/selftests/arm64/signal/testcases/sme_vl.c create mode 100644 tools/testing/selftests/arm64/signal/testcases/ssve_regs.c base-commit: fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf -- 2.30.2

2 years, 4 months

2
48
0 0

[PATCH v1 1/1] kunit: Replace kernel.h with the necessary inclusions

by Andy Shevchenko

When kernel.h is used in the headers it adds a lot into dependency hell, especially when there are circular dependencies are involved. Replace kernel.h inclusion with the list of what is really being used. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- include/kunit/assert.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/kunit/assert.h b/include/kunit/assert.h index ad889b539ab3..ccbc36c0b02f 100644 --- a/include/kunit/assert.h +++ b/include/kunit/assert.h @@ -10,7 +10,7 @@ #define _KUNIT_ASSERT_H #include <linux/err.h> -#include <linux/kernel.h> +#include <linux/printk.h> struct kunit; struct string_stream; -- 2.33.0

2 years, 4 months

1
3
0 0

[PATCH] kunit: tool: suggest using decode_stacktrace.sh on kernel crash

by Daniel Latypov

kunit.py isn't very clear that 1) it stashes a copy of the unparsed output in $BUILD_DIR/test.log 2) it sets $BUILD_DIR=.kunit by default So it's trickier than it should be for a user to come up with the right command to do so. Make kunit.py print out a command for this if a) we saw a test case crash b) we only ran one kernel (test.log only contains output from the last) Example suggested command: $ scripts/decode_stacktrace.sh .kunit/vmlinux .kunit < .kunit/test.log | tee .kunit/decoded.log | ./tools/testing/kunit/kunit.py parse Without debug info a user might see something like [14:11:25] Call Trace: [14:11:25] ? kunit_binary_assert_format (:?) [14:11:25] kunit_try_run_case (test.c:?) [14:11:25] ? __kthread_parkme (kthread.c:?) [14:11:25] kunit_generic_run_threadfn_adapter (try-catch.c:?) [14:11:25] ? kunit_generic_run_threadfn_adapter (try-catch.c:?) [14:11:25] kthread (kthread.c:?) [14:11:25] new_thread_handler (:?) [14:11:25] [CRASHED] `tee` is in GNU coreutils, so it seems fine to add that into the pipeline by default, that way users can inspect the otuput in more detail. Note: to turn on debug info, users would need to do something like $ echo -e 'CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y' >> .kunit/.kunitconfig $ ./tools/testing/kunit/kunit.py config $ ./tools/testing/kunit/kunit.py build $ <then run decode_stacktrace.sh now vmlinux is updated> This feels too clunky to include in the instructions. With --kconfig_add [1], it would become a bit less painful. [1] https://lore.kernel.org/linux-kselftest/20211106013058.2621799-2-dlatypov@g… Signed-off-by: Daniel Latypov <dlatypov(a)google.com> --- tools/testing/kunit/kunit.py | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py index 68e6f461c758..a45836ac2ca1 100755 --- a/tools/testing/kunit/kunit.py +++ b/tools/testing/kunit/kunit.py @@ -156,6 +156,12 @@ def exec_tests(linux: kunit_kernel.LinuxSourceTree, request: KunitExecRequest, test_counts.add_subtest_counts(result.result.test.counts) + if len(filter_globs) == 1 and test_counts.crashed > 0: + bd = request.build_dir + print('The kernel seems to have crashed; you can decode the stack traces with:') + print('$ scripts/decode_stacktrace.sh {}/vmlinux {} < {} | tee {}/decoded.log | {} parse'.format( + bd, bd, kunit_kernel.get_outfile_path(bd), bd, sys.argv[0])) + kunit_status = _map_to_overall_status(test_counts.get_status()) return KunitResult(status=kunit_status, result=result.result, elapsed_time=exec_time) base-commit: fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf -- 2.34.0.rc2.393.gf8c9666880-goog

2 years, 4 months

2
1
0 0

[PATCH] kunit: tool: revamp message for invalid kunitconfig

by Daniel Latypov

The current error message is precise, but not very clear if you don't already know what it's talking about, e.g. > $ make ARCH=um olddefconfig O=.kunit > ERROR:root:Provided Kconfig is not contained in validated .config. Following fields found in kunitconfig, but not in .config: CONFIG_DRM=y Try to reword the error message so that it's * your missing options usually have unsatisified dependencies * if you're on UML, that might be the cause (it is, in this example) Signed-off-by: Daniel Latypov <dlatypov(a)google.com> --- Note: this is based on https://lore.kernel.org/linux-kselftest/20211106013058.2621799-1-dlatypov@g… There's a fairly trivial merge conflict between these two patches (that patch changes the line above where this diff starts). --- tools/testing/kunit/kunit_kernel.py | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/tools/testing/kunit/kunit_kernel.py b/tools/testing/kunit/kunit_kernel.py index 7d459d6d6ff2..350883672be0 100644 --- a/tools/testing/kunit/kunit_kernel.py +++ b/tools/testing/kunit/kunit_kernel.py @@ -266,15 +266,17 @@ class LinuxSourceTree(object): def validate_config(self, build_dir) -> bool: kconfig_path = get_kconfig_path(build_dir) validated_kconfig = kunit_config.parse_file(kconfig_path) - if not self._kconfig.is_subset_of(validated_kconfig): - invalid = self._kconfig.entries() - validated_kconfig.entries() - message = 'Provided Kconfig is not contained in validated .config. Following fields found in kunitconfig, ' \ - 'but not in .config: %s' % ( - ', '.join([str(e) for e in invalid]) - ) - logging.error(message) - return False - return True + if self._kconfig.is_subset_of(validated_kconfig): + return True + invalid = self._kconfig.entries() - validated_kconfig.entries() + message = 'Not all Kconfig options selected in kunitconfig were in the generated .config.\n' \ + 'This is probably due to unsatisfied dependencies.\n' \ + 'Missing: ' + ', '.join([str(e) for e in invalid]) + if self._arch == 'um': + message += '\nNote: many Kconfig options aren\'t available on UML. You can try running ' \ + 'on a different architecture with something like "--arch=x86_64".' + logging.error(message) + return False def build_config(self, build_dir, make_options) -> bool: kconfig_path = get_kconfig_path(build_dir) base-commit: c949316af0a7c2103521aaa39be85392e2f02bab -- 2.34.0.rc1.387.gb447b232ab-goog

2 years, 4 months

3
2
0 0

[PATCH v2] kunit: tool: reconfigure when the used kunitconfig changes

by Daniel Latypov

Problem: currently, if you remove something from your kunitconfig, kunit.py will not regenerate the .config file. The same thing happens if you did --kunitconfig_add=CONFIG_KASAN=y [1] and then ran again without it. Your new run will still have KASAN. The reason is that kunit.py won't regenerate the .config file if it's a superset of the kunitconfig. This speeds it up a bit for iterating. This patch adds an additional check that forces kunit.py to regenerate the .config file if the current kunitconfig doesn't match the previous one. What this means: * deleting entries from .kunitconfig works as one would expect * dropping a --kunitconfig_add also triggers a rebuild * you can still edit .config directly to turn on new options We implement this by creating a `last_used_kunitconfig` file in the build directory (so .kunit, by default) after we generate the .config. When comparing the kconfigs, we compare python sets, so duplicates and permutations don't trip us up. The majority of this patch is adding unit tests for the existing logic and for the new case where `last_used_kunitconfig` differs. [1] https://lore.kernel.org/linux-kselftest/20211106013058.2621799-2-dlatypov@g… Signed-off-by: Daniel Latypov <dlatypov(a)google.com> --- Note: this patch is based on https://lore.kernel.org/linux-kselftest/20211106013058.2621799-1-dlatypov@g… This patch will work without it, but there'll be a false merge conflict. v1 -> v2: * always regenerate if last_used_kunitconfig doesn't exist * don't call os.remove() if last_used_kunitconfig doesn't exist * add in get_old_kunitconfig_path() to match get_kunitconfig_path() * s/_kconfig_changed/_kunitconfig_changed --- Documentation/dev-tools/kunit/start.rst | 8 ++--- tools/testing/kunit/kunit_kernel.py | 40 ++++++++++++++++------ tools/testing/kunit/kunit_tool_test.py | 45 +++++++++++++++++++++++++ 3 files changed, 78 insertions(+), 15 deletions(-) diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst index 1e00f9226f74..0a5e65540974 100644 --- a/Documentation/dev-tools/kunit/start.rst +++ b/Documentation/dev-tools/kunit/start.rst @@ -50,10 +50,10 @@ It'll warn you if you haven't included the dependencies of the options you're using. .. note:: - Note that removing something from the ``.kunitconfig`` will not trigger a - rebuild of the ``.config`` file: the configuration is only updated if the - ``.kunitconfig`` is not a subset of ``.config``. This means that you can use - other tools (such as make menuconfig) to adjust other config options. + If you change the ``.kunitconfig``, kunit.py will trigger a rebuild of the + ``.config`` file. But you can edit the ``.config`` file directly or with + tools like ``make menuconfig O=.kunit``. As long as its a superset of + ``.kunitconfig``, kunit.py won't overwrite your changes. Running the tests (KUnit Wrapper) diff --git a/tools/testing/kunit/kunit_kernel.py b/tools/testing/kunit/kunit_kernel.py index 350883672be0..12085e04a80c 100644 --- a/tools/testing/kunit/kunit_kernel.py +++ b/tools/testing/kunit/kunit_kernel.py @@ -21,6 +21,7 @@ import qemu_config KCONFIG_PATH = '.config' KUNITCONFIG_PATH = '.kunitconfig' +OLD_KUNITCONFIG_PATH = 'last_used_kunitconfig' DEFAULT_KUNITCONFIG_PATH = 'tools/testing/kunit/configs/default.config' BROKEN_ALLCONFIG_PATH = 'tools/testing/kunit/configs/broken_on_uml.config' OUTFILE_PATH = 'test.log' @@ -179,6 +180,9 @@ def get_kconfig_path(build_dir) -> str: def get_kunitconfig_path(build_dir) -> str: return get_file_path(build_dir, KUNITCONFIG_PATH) +def get_old_kunitconfig_path(build_dir) -> str: + return get_file_path(build_dir, OLD_KUNITCONFIG_PATH) + def get_outfile_path(build_dir) -> str: return get_file_path(build_dir, OUTFILE_PATH) @@ -289,24 +293,38 @@ class LinuxSourceTree(object): except ConfigError as e: logging.error(e) return False - return self.validate_config(build_dir) + if not self.validate_config(build_dir): + return False + + old_path = get_old_kunitconfig_path(build_dir) + if os.path.exists(old_path): + os.remove(old_path) # write_to_file appends to the file + self._kconfig.write_to_file(old_path) + return True + + def _kunitconfig_changed(self, build_dir: str) -> bool: + old_path = get_old_kunitconfig_path(build_dir) + if not os.path.exists(old_path): + return True + + old_kconfig = kunit_config.parse_file(old_path) + return old_kconfig.entries() != self._kconfig.entries() def build_reconfig(self, build_dir, make_options) -> bool: """Creates a new .config if it is not a subset of the .kunitconfig.""" kconfig_path = get_kconfig_path(build_dir) - if os.path.exists(kconfig_path): - existing_kconfig = kunit_config.parse_file(kconfig_path) - self._ops.make_arch_qemuconfig(self._kconfig) - if not self._kconfig.is_subset_of(existing_kconfig): - print('Regenerating .config ...') - os.remove(kconfig_path) - return self.build_config(build_dir, make_options) - else: - return True - else: + if not os.path.exists(kconfig_path): print('Generating .config ...') return self.build_config(build_dir, make_options) + existing_kconfig = kunit_config.parse_file(kconfig_path) + self._ops.make_arch_qemuconfig(self._kconfig) + if self._kconfig.is_subset_of(existing_kconfig) and not self._kunitconfig_changed(build_dir): + return True + print('Regenerating .config ...') + os.remove(kconfig_path) + return self.build_config(build_dir, make_options) + def build_kernel(self, alltests, jobs, build_dir, make_options) -> bool: try: if alltests: diff --git a/tools/testing/kunit/kunit_tool_test.py b/tools/testing/kunit/kunit_tool_test.py index 7e42a7c27987..572f133511aa 100755 --- a/tools/testing/kunit/kunit_tool_test.py +++ b/tools/testing/kunit/kunit_tool_test.py @@ -358,6 +358,51 @@ class LinuxSourceTreeTest(unittest.TestCase): with open(kunit_kernel.get_outfile_path(build_dir), 'rt') as outfile: self.assertEqual(outfile.read(), 'hi\nbye\n', msg='Missing some output') + def test_build_reconfig_no_config(self): + with tempfile.TemporaryDirectory('') as build_dir: + with open(kunit_kernel.get_kunitconfig_path(build_dir), 'w') as f: + f.write('CONFIG_KUNIT=y') + + tree = kunit_kernel.LinuxSourceTree(build_dir) + mock_build_config = mock.patch.object(tree, 'build_config').start() + + # Should generate the .config + self.assertTrue(tree.build_reconfig(build_dir, make_options=[])) + mock_build_config.assert_called_once_with(build_dir, []) + + def test_build_reconfig_existing_config(self): + with tempfile.TemporaryDirectory('') as build_dir: + # Existing .config is a superset, should not touch it + with open(kunit_kernel.get_kunitconfig_path(build_dir), 'w') as f: + f.write('CONFIG_KUNIT=y') + with open(kunit_kernel.get_old_kunitconfig_path(build_dir), 'w') as f: + f.write('CONFIG_KUNIT=y') + with open(kunit_kernel.get_kconfig_path(build_dir), 'w') as f: + f.write('CONFIG_KUNIT=y\nCONFIG_KUNIT_TEST=y') + + tree = kunit_kernel.LinuxSourceTree(build_dir) + mock_build_config = mock.patch.object(tree, 'build_config').start() + + self.assertTrue(tree.build_reconfig(build_dir, make_options=[])) + self.assertEqual(mock_build_config.call_count, 0) + + def test_build_reconfig_remove_option(self): + with tempfile.TemporaryDirectory('') as build_dir: + # We removed CONFIG_KUNIT_TEST=y from our .kunitconfig... + with open(kunit_kernel.get_kunitconfig_path(build_dir), 'w') as f: + f.write('CONFIG_KUNIT=y') + with open(kunit_kernel.get_old_kunitconfig_path(build_dir), 'w') as f: + f.write('CONFIG_KUNIT=y\nCONFIG_KUNIT_TEST=y') + with open(kunit_kernel.get_kconfig_path(build_dir), 'w') as f: + f.write('CONFIG_KUNIT=y\nCONFIG_KUNIT_TEST=y') + + tree = kunit_kernel.LinuxSourceTree(build_dir) + mock_build_config = mock.patch.object(tree, 'build_config').start() + + # ... so we should trigger a call to build_config() + self.assertTrue(tree.build_reconfig(build_dir, make_options=[])) + mock_build_config.assert_called_once_with(build_dir, []) + # TODO: add more test cases. -- 2.34.0.rc2.393.gf8c9666880-goog

2 years, 4 months

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror November 2021