summaryrefslogtreecommitdiff
path: root/arch/riscv/kernel
AgeCommit message (Collapse)Author
11 daysriscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are presentJinRui
The RISC-V ISA manual specifies that Zfh implies Zfhmin, a normative rule clarified in https://github.com/riscv/riscv-isa-manual/pull/3070. Zvfh likewise implies Zvfhmin, as stated by the vector extension specification. The kernel currently reports ZFH and ZFHMIN (and ZVFH and ZVFHMIN) as independent hwprobe bits derived only from what the device tree declares. Platforms that declare just "zfh" (Zfh being a superset that already contains all Zfhmin instructions) therefore report RISCV_HWPROBE_EXT_ZFHMIN=0, which breaks userspace RVA23 conformance checks (e.g. snapd installing core26 on riscv64). Use the existing superset mechanism to set the implied subset bits: - zfh implies zfhmin - zvfh implies zvfhmin Add a hwprobe selftest asserting the implication holds and update the hwprobe documentation accordingly. This is complementary to the rva23u64 base behavior discussion: the RVA23 conformance query proposed there is derived from the per-extension bits fixed here, so correct EXT_0 reporting is a prerequisite for it to work on harts whose device tree declares only "zfh". Tested on a RISC-V QEMU VM whose device tree only declares "zfh" and "zvfh": with this change both /proc/cpuinfo and the hwprobe RISCV_HWPROBE_KEY_IMA_EXT_0 bitmap report ZFHMIN and ZVFHMIN, and the hwprobe selftest (including the new implication check) passes. Link: https://lore.kernel.org/kvm-riscv/20260206002349.96740-1-andrew.jones@oss.qualcomm.com/ Signed-off-by: JinRui <jinrui@haiwei.tech> Link: https://patch.msgid.link/7190E4DB338251C3+20260811081513.2849980-1-jinrui@haiwei.tech [pjw@kernel.org: trimmed superfluous blank line in tags] Signed-off-by: Paul Walmsley <pjw@kernel.org>
12 daysriscv: hwprobe: initialize pair->value in hwprobe_one_pair()Andy Chiu
The vendor-extension handlers reached from hwprobe_one_pair() (hwprobe_isa_vendor_ext_thead_0() and friends) only OR the present bits into pair->value via VENDOR_EXTENSION_SUPPORTED() and clear their own missing bits; they assume the caller has already zeroed pair->value. That holds for hwprobe_get_values() (it zeroes each pair) and hwprobe_get_cpus() (it re-initializes its scratch pair per key), but not for complete_hwprobe_vdso_data(), which reuses a single pair across all keys without re-zeroing. A vendor key therefore inherits stale bits from the previously probed key, and the wrong value is cached in the vDSO all_cpu_hwprobe_values[] and handed to userspace on the fast patih. Zero pair->value once at the top of hwprobe_one_pair() so every handler starts from a clean value regardless of the caller, and drop the now redundant zeroing in the *_BLOCK_SIZE cases. hwprobe_isa_ext0() keeps its own zeroing because hwprobe_ext0_has() calls it directly, bypassing hwprobe_one_pair(). Fixes: a5ea53da65c5 ("riscv: hwprobe: Add thead vendor extension probing") Signed-off-by: Andy Chiu <tchiu@tenstorrent.com> Reviewed-by: Jesse Taube <jtaubepe@redhat.com> Link: https://patch.msgid.link/20260725001614.2578617-2-tchiu@tenstorrent.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
12 daysriscv: use string helper in setup_global_riscv_enable()Dmitry Antipov
Prefer the convenient string choice 'str_disabled_enabled()' helper over hardcoded strings in 'setup_global_riscv_enable()'. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Link: https://patch.msgid.link/20260819160546.3219942-1-dmantipov@yandex.ru Signed-off-by: Paul Walmsley <pjw@kernel.org>
12 daysRevert "riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set"Samuel Holland
This reverts commit 3033b2b1e3949274f33a140e2a97571b5a307298. The reverted patch is userspace-visible behavior change, not a bug fix. The two variables here (pmm and pmlen) control two independent features: pmm is the _hardware_ pointer masking mode that applies while executing in userspace. pmlen is the shift amount that the _kernel_ uses when untagging addresses; PMLEN_0 means no untagging occurs, so the kernel does not accept tagged addresses in syscall arguments. It is valid (as documented and tested by the self test) to enable pointer masking without enabling the tagged address ABI. This separation is necessary to allow userspace to create an execution environment similar to what the kernel supports on arm64 by default, where TBI is enabled but the tagged address ABI is not. (On arm64, there is no equivalent to PR_PMLEN_MASK because TBI is always enabled.) Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Link: https://patch.msgid.link/20260820014551.1979772-1-samuel.holland@sifive.com Cc: stable@vger.kernel.org Fixes: 3033b2b1e394 ("riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set") Signed-off-by: Paul Walmsley <pjw@kernel.org>
12 daysriscv: patch: skip fixmap mapping when kernel text is already writableXiaofeng Yuan
patch_map() always creates a temporary writable mapping via fixmap for kernel text addresses, even when CONFIG_STRICT_KERNEL_RWX is disabled and the kernel text is already mapped with _PAGE_WRITE. This is unnecessary overhead at best, and on minimal configurations it can cause page faults. Skip the fixmap path for kernel text when CONFIG_STRICT_KERNEL_RWX is not enabled, since the text pages are already writable in that case. The module text path is already gated on CONFIG_STRICT_MODULE_RWX and is kept unchanged. Reported-by: Klara Modin <klara@kasm.eu> Closes: https://lore.kernel.org/all/ant_8TaBbov_GS4i@soda.int.kasm.eu/ Reported-by: Lad Prabhakar <prabhakar.csengg@gmail.com> Closes: https://lore.kernel.org/all/CA+V-a8tQK8rih9SGGTyqrEBGpNkx4H0eX2YccCRrgkVAPr+EBg@mail.gmail.com/ Tested-by: Klara Modin <klarasmodin@gmail.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://patch.msgid.link/20260814082742.148403-3-xiaofengmian@163.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-25Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm updates from Paolo Bonzini: "ARM64: - Add support for 'slot' based PMU events, paired with new UAPI that compels the user to select a specific PMU implementation - Lazy save/restore of vCPU state for pKVM, along with various fixes and cleanups to the management of vCPU state between the untrusted host and pKVM hypervisor - Disable traps of EL1 registers for nested hypervisors when FEAT_NV2p1 is present, guaranteeing that EL2-specific register bits are stateful in the EL1 counterpart - Leverage FEAT_NV3 to avoid unnecessary ERET/TLBI traps when the scope of those instructions remains 'in host' (i.e. L1 kernel/userspace) - Pile of fixes for the management of the VNCR pseudo-TLB, such as under-invalidations and races with concurrent TLBIs on other vCPUs - Consolidate the non-protected and pKVM view of ICH_VTR_EL2 to a runtime-patched constant, allowing the same data to be shared with pKVM prior to dropping host privileges - Considerable pile of LLM-assisted fixes around the shop but mostly in the VGIC, our in-kernel generator of bugs (and sometimes interrupts) LoongArch: - Advertise already-supported capabilities - Some bug fixes about timer and MMIO - Some hardening about interrupt injection - Replace kvm_err() with kvm_pr_unimpl() - Add FPU/LSX/LASX test cases for selftests RISC-V: - Svadu/Zicfiss/Zicfilp FWFT support for Guest - Use try_cmpxchg for IMSIC MRIF RMW - More arch-specific tracepoints in KVM RISC-V - Eager page splitting when enabling dirty logging - Optimize hfence request handling for SMP Guests - Improve dirty log clearing by skipping zero bits in mask - Guard HFENCE range loops against overflow - CPU PM notifiers in KVM RISC-V for non-retentive idle states - Fix kernel-mode vector context save/restore for Guest s390: - Fixes for vfio-ap - Fixes for the gmap rework - Fixes for vsie - AI triggered fixes all over - diag9c tracing - code move preparation for the additional arm64 support - enable CONTEXT_ANALYSIS x86: - Perform spring cleaning on x86.{c,h} and asm/kvm_host.h, by adding regs.c (the kvm_cache_regs.h => regs.h is already applied) and msrs.{c,h}, and moving relevant code out of x86.c - Split kvm_mmu in three parts, respectively to describe the format of page tables, walking the guest page tables and building the page tables. Always use the same page table walker kvm->arch.gva_walk as the entry point to convert a guest's virtual address, where the previous code used two different kvm_mmu structs depending on whether the walk included nested EPT/NPT or not. Make page fault vmexits reuse the permission checking machinery that is used for guest page faults. This is both a cleanup and a baby step towards supporting XS/XU memory permissions - Document some of the "fun" gotchas with the APIC base when creating IRQCHIPs on x86 - Remove a defunct masterclock update from kvm_xen_shared_info_init(). It could result in incorrect kvmclock due to triggering an unnecessary switch to/from masterclock mode - Skip Xen runstate time updates if time has effectively gone backwards, so that the guest doesn't report 100% steal time for a very, very long time - Drop KVM's runtime updates of the Xen PV timing CPUID leaf, as KVM was updating the wrong sub-leaf, and upstream KVM will soon provide all the information needed by userspace to populate the CPUID field itself - Fix a bug where KVM would walk a newly created rmap without holding the rmap lock (or mmu_lock) during aging - Fix a bug where aging TDP MMU SPTEs could clobber FROZEN SPTEs - Fix a variety of #DB priority bugs - Fix a class of races related to enabling Hyper-V emulation on a vCPU after the vCPU is visible to the rest of KVM - Use static calls for nested virtualization ops - Move more KVM-internal code out of x86's kvm_host.h - Enumerate support for a variety of Zhaoxin instructions that don't require explicit virtualization - Fix missing EFER validation bugs, including in the KVM_SET_SREGS* path - Harden kvm_vcpu_map() against double-mapping and thus leaking references - Misc fixes and cleanups, e.g. for largely benign syzkaller splats x86 (Intel): - Zero a vCPU's entry in VMX's Posted Interrupt Descriptor table used for IPI virtualization when the vCPU is freed, to fix a use-after-free where hardware will write to a freed vCPU's PID - Service local TLB flushes on a failed nested VM-Enter to fix a bug where KVM could miss a TLB on a future, successful VM-Enter with the same L2 VPID - Cap the maximum value shoved into the VMX Preemption Timer to workaround an erratum that affects all existing Intel CPUs that support CPUID 0x15 - Fix VPID virtualization bugs where KVM would fail to flush hardware TLBs - Harden the TDX "populate" ioctls against bad input, and to prepare for supporting in-place private<=>shared conversion x86 (AMD): - Forcefully invalidate SNP VMSA pages if their backing guest_memfd page is zapped/invalidated, e.g. due to a PUNCH_HOLE in response to a Page-State Change request - Remove a dying VM from the GA Log notifier list before the VM is actually destroyed, to fix a potential use-after-free - While FOLL_WRITE was needed in the past to trigger CoW unsharing, nowadays FOLL_LONGTERM does that already even without FOLL_WRITE, and in fact, get_user_pages() actually disallows FOLL_WRITE together with FOLL_LONGTERM. So don't pass FOLL_WRITE when registering encrypted memory regions, i.e. when pinning SEV/SEV-ES guest memory, to fix a regression with file-backed memory introduced by KVM's (correct) usage of long-term pins (This was reviewed by mm maintainers; for more information, see commit ee1a586dd1fa "KVM: SEV: Drop FOLL_WRITE for encrypted region registration") - Allocate full pages for SEV/SEV-ES {DE,EN}CRYPT ops on SNP-enabled hosts to fix a data corruption issue due to the PSP driver assigning to-be-written pages to firmware (as required by the SNP specs) - Unconditionally intercept ICBEP so that KVM generates the correct guest RIP when handling an ICEBP-induced TASK_SWITCH #VMEXIT - Harden the SNP "populate" ioctls against bad input, and to prepare for supporting in-place private<=>shared conversion Generic: - Remove kvm_debugfs_dir if kvm_init() fails after creating KVM's debugfs - Add a per-VM bitmap to track which vCPU IDs have been "claimed" but for which the vCPU isn't yet online, and use the bitmap to reject duplicate IDs before calling into arch code. This allows arch code to consume vcpu_id without having to worry about cross-vCPU clobbering (at least s390 and x86 have had related bugs) - Rework the so called "prepare" and "invalidate" guest_memfd hooks to prepare for in-place private<=>shared conversion, and clean up a few warts along the way Selftests: - Automatically allocate a full page for L2 guest stacks on x86 instead of requiring test-specific L1 guest code to carve out a portion of the L1 stack for L2 usage, and to ensure the L2 stack also adheres to the x86-64 calling convention ABI - Add a selftest to verify {Guest,Host}-Only behavior in x86's mediated PMU - Clean up nested SVM's handling of GPRs on L2<=>L1 transitions, reuse the functionality for nested VMX, and drop the ucall hack that was fudging around the lack of GPR switching on nVMX - Add a stress test to verify KVM doesn't clobber/drop #PF state, e.g. CR2, across save/restore, including when L2 is active - Add a test to verify KVM_CREATE_VM accepts exactly what is reported by KVM_CAP_VM_TYPES - Misc selftests fixes and cleanups - Fix several issues with seeding the pRNG, and rework the pRNG APIs to that the pRNG can be sanely used in host code, not just guest code - Add an IRQ test to validate virtual IRQ deliverty for IRQs wired up via KVM_IRQFD + KVM_SET_GSI_ROUTING, with optional support for triggering IRQs via writes to an assigned VFIO device - Add syscall wrappers to assert success on a variety of pthreads and CPU affinity APIs - Set vCPU pthread affinity as early as possible to reduce contention issues that were surfaced by PREEMPT_LAZY, which result in runtimes of over a minute on large hosts, versus the expected ~5 seconds - Rework the PMU counters test to run each testcase using a single VM with many vCPUs for each sub-testcase, instead of using a unique VM for each sub-testcase. This cuts the runtime by ~20x Miscellaneous: - MAINTAINERS updates for vfio-ap, guest_memfd, kvm-x86. Mostly representing the status quo more accurately, but also... welcome David Hildenbrand as guest_memfd reviewer!" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (413 commits) KVM: arm64: Validate GICv5 timer PPIs before claiming ownership KVM: arm64: vgic: Reject out-of-range GICv5 PPI IDs KVM: arm64: vgic: Prevent speculative SPI array underflow KVM: arm64: vgic: Free gic_kvm_info on initialization failure KVM: arm64: Avoid mismatched accesses to 'struct kvm_nvhe_init_params' s390/vfio-ap: Fix NULL deref in status_show() during queue probe s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removed s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove s390/vfio-ap: Fix required lock not held during update of ap_matrix_mdev object s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL s390/vfio-ap: Fix stale do_remove flag across iterations in vfio_ap_mdev_cfg_remove RISC-V: KVM: fix vcpu vector context handling for kernel-mode vector riscv: vector: allow non-preemptible kernel-mode vector with IRQs off riscv: vector: refactor riscv_v_start_kernel_context KVM: s390: gmap: Make prefix handling optional KVM: s390: gmap: Make CMMA optional KVM: s390: gmap: Make storage keys optional KVM: s390: Prepare gmap for a second KVM implementation ...
2026-08-20Merge tag 'riscv-for-linus-7.3-mw1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V updates from Paul Walmsley - Add initial definitions and discovery for the Smcsrind, Sscsrind, Smcntrpmf, Ssccfg, Smcdeleg, Zicclsm, Ziccamoa, Ziccif, Ziccrse, Za64rs, and Ssqosid RISC-V ISA extensions - Improve the RISC-V update_mmu_cache_range() implementation by using flush-by-ASID, enabling performance improvements on microarchitectures that support related optimizations; and by taking advantage of the Svinval RISC-V ISA extension on microarchitectures that support it - Shrink CFI shadow stack allocation further (to 512MB) to save virtual address space (and physical memory on systems with strict overcommit policies) - Add initial CPU context switch support for QoS tagging (Ssqosid) - Change our vector misaligned access speed test code to be synchronous, avoiding a bunch of bugs related to unnecessary asynchronicity - Enable ARCH_HAS_ACPI_TABLE_UPGRADE for RISC-V to help with ACPI table debugging (similar to ARM64 and x86) - Extract vDSO section offsets at build time, rather than run time, to avoid the boot time overhead - Use assembler directives to control the use of instructions from the RISC-V ISA extensions Zacas and Zabha, rather than compiler -march flags that could affect the whole kernel (similar to ARM64) - Add a kselftest for kprobes support for the c.jal instruction on RISC-V - When UEFI runtime services are available, use them to restart and power off - Fix ARCH_HAS_ACPI_TABLE_UPGRADE for RISC-V by adding a missing include file to the ACPI code - Move contiguous DMA memory reservation later in the boot, to ensure that the correct global and per-node pools are allocated when CONFIG_CMA_SIZE_PERNUMA is enabled - Disallow probes on breakpoint handlers to avoid recursing indefinitely into do_trap_break() - Patch the compat vDSO during runtime alternatives processing, not only the standard vDSO - Remove some leftover XIP support elements missed by commit 9b3a2be84803 ("riscv: Remove support for XIP kernel") - Fix broadcast timer switching in ACPI LPI power states by implementing a RISC-V version of arch_get_idle_state_flags() - Miscellaneous fixes, including: vDSO makefile simplification; marking our default_power_off() as __noreturn; error path fixes in the PMU SBI perf driver; RISC-V extension capitalization consistency; the use of BIT() macros in one of our include files; and some documentation fixes * tag 'riscv-for-linus-7.3-mw1' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: (39 commits) RISC-V: hwprobe: Use BIT macro to avoid warnings riscv: alternative: Also patch the compat vDSO riscv: alternative: Use the statically extracted vDSO section offsets riscv: vdso: Add symbols for the alternative section boundaries riscv: Add Ziccamoa, Ziccif, Ziccrse, and Za64rs to cpufeature and hwprobe riscv: Add Zicclsm to cpufeature and hwprobe riscv: cpufeature: Clarify ISA spec version for canonical order riscv: Standardize extension capitalization riscv: kprobes: Prevent probes in breakpoint handlers riscv: cmpxchg: Use .option arch for Zacas and Zabha riscv: acpi: Handle LPI architectural context loss flags riscv: further remove XIP riscv: Add support for srmcfg CSR from Ssqosid extension riscv: Detect the Ssqosid extension dt-bindings: riscv: Add Ssqosid extension description dt-bindings: riscv: add Counter delegation ISA extensions description RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsing RISC-V: Add Ssccfg extension CSR definition dt-bindings: riscv: add Smcntrpmf ISA extension description RISC-V: Add Smcntrpmf extension parsing ...
2026-08-18Merge tag 'core-entry-2026-08-17' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull generic entry code updates from Thomas Gleixner: - Make syscall user dispatching configurable Not all architectures can makes use of syscall user dispatching. Allow them to disable the feature completely. - Consolidate stack randomization for the generic entry code and the architectures using it. Stack randomization on syscall entry was sprinkled throughout the architecture specific low level entry code and in some cases at the wrong points, e.g. before establishing state, which violates the non-instrumentable constraints of that code. Clean this up by integrating stack randomization into the generic entry code helpers so that it is invoked at the earliest possible point right after establishing state and converting all generic entry code using architecture over. - Clean up the syscall number handling in the generic entry code. It works correctly for architectures which have a separate return value storage in pt_regs, but fails to distinguish the case where user space handed in -1 as syscall number from the case where the entry code rejects it by returning -1 to the callers. Aside of that the return value functionality of those interfaces is not really intuitive. Fix this by separating the decision to reject a syscall (user dispatch, ptrace, seccomp ...) from the potential modification of the syscall number through these mechanisms. This solves most of the problems for architectures which do not have a separate return value storage in pt_regs except for the case where a tracepoint has a BPF script or a probe attached which overwrite both the syscall number and the return value. But that's a problem which cannot be solved in the generic code, that only can be addressed by separating the storage model in the affected architectures. * tag 'core-entry-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (23 commits) entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall execution entry: Make return type of syscall_trace_enter() bool entry: Rework trace_syscall_enter() entry: Rework syscall_audit_enter() syscall_user_dispatch: Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH entry: Fix seccomp bypass after ptrace with TSYNC x86/entry: Simplify the syscall number logic x86/entry: Get rid of the sys_ni_syscall() indirection x86/entry: Make syscall functions static ptrace, treewide: Rename ptrace_report_syscall_entry() to ptrace_report_syscall_permit_entry() seccomp, treewide: Rename and convert __secure_computing() to return boolean entry: Use syscall number instead of rereading it entry: Remove syscall_enter_from_user_mode() x86/syscall: Use [syscall_]enter_from_user_mode_randomize_stack() s390/syscall: Use enter_from_user_mode_randomize_stack() riscv/syscall: Use syscall_enter_from_user_mode_randomize_stack() powerpc/syscall: Use syscall_enter_from_user_mode_randomize_stack() loongarch/syscall: Use syscall_enter_from_user_mode_randomize_stack() entry: Provide [syscall_]enter_from_user_mode_randomize_stack() randomize_kstack: Provide add_random_kstack_offset_irqsoff() ...
2026-08-18Merge tag 'kexec-v7.3-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux Pull kexec updates from Mike Rapoport: - Deduplicate crash memory allocation and the exclusion of reserved crash kernel regions from architecture specific code into a generic crash_prepare_headers() and enable crashkernel CMA reservation on arm64 and riscv reservation on arm64 and riscv. - Skip purgatory checksum verification when the kexec segments cannot be corrupted by DMA, which saves about 250ms on kexec. - Replace __ASSEMBLY__ with the compiler provided __ASSEMBLER__ in include/linux/kexec.h. - Fix a keyring refcount imbalance in the kdump kernel's dm-crypt key restore path, which over-dropped the user keyring reference when more than one key was restored. * tag 'kexec-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux: crash_dump: release keyring reference at the correct time kexec: Replace __ASSEMBLY__ with __ASSEMBLER__ in header file kexec_file: skip checksum verification when safe riscv: kexec_file: Add support for crashkernel CMA reservation arm64: kexec_file: Add support for crashkernel CMA reservation powerpc/kexec_file: Use crash_exclude_core_ranges() helper LoongArch: kexec_file: Use crash_prepare_headers() helper to simplify code riscv: kexec_file: Use crash_prepare_headers() helper to simplify code x86/crash: Use crash_prepare_headers() helper to simplify code arm64: kexec_file: Use crash_prepare_headers() helper to simplify code crash: Add crash_prepare_headers() to exclude crash kernel memory powerpc/crash: sort crash memory ranges before preparing elfcorehdr riscv: kexec_file: Fix crashk_low_res not exclude bug
2026-08-18Merge tag 'loongarch-kvm-7.3' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson into HEAD LoongArch KVM changes for v7.3 1. Advertise already-supported capabilities. 2. Some bug fixes about timer and MMIO. 3. Some hardening about interrupt injection. 4. Replace kvm_err() with kvm_pr_unimpl(). 5. Add FPU/LSX/LASX test cases for selftests.
2026-08-13RISC-V: KVM: fix vcpu vector context handling for kernel-mode vectorAndy Chiu
Running vector workloads like perf + mcf on KVM can result in an unexpected termination due to a vtype corruption. This happens because the kernel-mode vector (KMV) misattributes the guest's vcpu context as the user's context and source from a wrong status.VS. The simplified call chain that results in this problem is shown as follow: __riscv_sys_ioctl() kvm_arch_vcpu_ioctl_run() kvm_riscv_vcpu_exit() kvm_riscv_vcpu_sbi_ecall() kvm_riscv_vcpu_pmu_ctr_stop() kvm_vcpu_write_guest() __copy_to_user() enter_vector_usercopy() kernel_vector_begin() kernel_vector_begin() should use the sstatus.VS from guest's vcpu context instead of task_pt_reg(current). Also, it should not save guest's v-reg into the user's context memory. To resolve this, the vcpu context must be correctly saved when KMV is serving a guest. However, invoking KVM functions directly from generic RISC-V architecture code introduces a reverse dependency, breaking builds when KVM is configured as N or M. Address this by registering an RCU-protected callback for context flushing. KVM registers this callback at module initialization and unregisters it on exit. When KMV starts a kernel context, it can now safely flush the vector context via the callback. Fixes: ecd2ada8a5e0 ("riscv: Add support for kernel mode vector") Signed-off-by: Andy Chiu <tchiu@tenstorrent.com> Reviewed-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260803215250.824417-4-tchiu@tenstorrent.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-08-13riscv: vector: allow non-preemptible kernel-mode vector with IRQs offAndy Chiu
Similar to commit 7137a203b251 ("arm64/fpsimd: Permit kernel mode NEON with IRQs off"), we are upgrading get/put_cpu_vector_context such that kvm_arch_vcpu_load/put can be safely called under both irq off and regular process context. Also, export both symbols so the kvm module can call into it. Signed-off-by: Andy Chiu <tchiu@tenstorrent.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260803215250.824417-3-tchiu@tenstorrent.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-08-13riscv: vector: refactor riscv_v_start_kernel_contextAndy Chiu
Refactor riscv_v_start_kernel_context() to drop `is_nested` variable and simplify the logic. This introduces no functional change and works as a preparatory patch for the kernel-mode vector fix. Signed-off-by: Andy Chiu <tchiu@tenstorrent.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260803215250.824417-2-tchiu@tenstorrent.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-08-07riscv: alternative: Also patch the compat vDSOThomas Weißschuh
The vDSO for compat processes can also contain alternative entries. Patch those, too. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260630-riscv-vdso32-alternative-v1-3-a32fd89b7b1c@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: alternative: Use the statically extracted vDSO section offsetsThomas Weißschuh
Currently the alternative sections are extracted from the vDSO binaries at runtime. This has runtime overhead and also doesn't work for the compat vDSO. Use the offsets generated during the build instead, fixing both issues. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260630-riscv-vdso32-alternative-v1-2-a32fd89b7b1c@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: vdso: Add symbols for the alternative section boundariesThomas Weißschuh
Currently the alternative sections are extracted from the vDSO binaries at runtime. This has runtime overhead and also doesn't work for the compat vDSO. Extract the offsets of the alternative section during the build with the existing symbol extraction machinery. Also add dummy symbols as fallback. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260630-riscv-vdso32-alternative-v1-1-a32fd89b7b1c@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Add Ziccamoa, Ziccif, Ziccrse, and Za64rs to cpufeature and hwprobeAndrew Jones
Add Ziccamoa, Ziccif, and Za64rs to riscv_isa_ext[] so they can be parsed from devicetree/ACPI ISA strings. Ziccrse is already present in cpufeature; this patch only adds its hwprobe exposure. Expose all four extensions via hwprobe through new bits in RISCV_HWPROBE_KEY_IMA_EXT_1 (RISCV_HWPROBE_EXT_ZICCAMOA, _ZICCIF, _ZICCRSE, _ZA64RS), so userspace can probe each of these RVA23U64-mandatory extensions individually. Reviewed-by: Jesse Taube <jtaubepe@redhat.com> Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-6-2c61f94a695a@gmail.com [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Add Zicclsm to cpufeature and hwprobeJesse Taube
Zicclsm requires misaligned support for all regular load and store instructions, both scalar and vector, but not AMOs or other specialized forms of memory access, to main memory regions with both the cacheability and coherence PMAs, as defined in the profiles spec. Even though mandated, misaligned loads and stores might execute extremely slowly. Standard software distributions should assume their existence only for correctness, not for performance. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Andy Chiu <andy.chiu@sifive.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Tested-by: Charlie Jenkins <charlie@rivosinc.com> Signed-off-by: Jesse Taube <jesse@rivosinc.com> [andrew.jones: Rebased, rewrote doc text, minor commit message revisions] Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-5-2c61f94a695a@gmail.com [pjw@kernel.org: updated to apply; added Andrew's username to his tag comments] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: cpufeature: Clarify ISA spec version for canonical orderGuodong Xu
Specify that chapter 27 refers to version 20191213 of the RISC-V ISA Unprivileged Architecture. The chapter numbering differs across specification versions - for example, in version 20250508, the ISA Extension Naming Conventions is chapter 36, not chapter 27. Historical versions of the RISC-V specification can be found via Link [1]. Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://riscv.org/specifications/ratified/ [1] Fixes: 99e2266f2460 ("RISC-V: clarify ISA string ordering rules in cpu.c") Signed-off-by: Guodong Xu <guodong@riscstar.com> Link: https://patch.msgid.link/20260125-supm-ext-id-v2-3-1e3b9714c860@riscstar.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Standardize extension capitalizationCharlie Jenkins
The base extensions are often lowercase and were written as lowercase in hwcap, but other references to these extensions in the kernel are uppercase. Standardize the case to make it easier to handle macro expansion. Acked-by: Anup Patel <anup@brainfault.org> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Charlie Jenkins <thecharlesjenkins@gmail.com> [andrew.jones: Apply KVM_ISA_EXT_ARR(), fixup all KVM use.] Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-4-2c61f94a695a@gmail.com [pjw@kernel.org: fixed a checkpatch warning; added Andrew's username to his tag comments] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: kprobes: Prevent probes in breakpoint handlersRui Qi
The ftrace selftest multiple_kprobes.tc registers kprobe events on the first 256 text symbols from /proc/kallsyms. If handle_break() is selected as a probe target on RISC-V, the breakpoint exception path can trap again before it reaches the kprobe breakpoint handler. That recursively enters do_trap_break() and can make the system unresponsive. Mark handle_break() and its local probe dispatch helpers as nokprobe symbols so they are added to the kprobe blacklist, matching other low-level breakpoint exception paths. Signed-off-by: Rui Qi <qirui.001@bytedance.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260806043807.2583001-1-qirui.001@bytedance.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: further remove XIPJisheng Zhang
After commit 9b3a2be84803 ("riscv: Remove support for XIP kernel"), something relatd with XIP are still there. Remove them to clean up the code. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260805010049.13918-1-jszhang@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Add support for srmcfg CSR from Ssqosid extensionDrew Fustini
Add support for the srmcfg CSR defined in the Ssqosid ISA extension. The CSR contains two fields: - Resource Control ID (RCID) for resource allocation - Monitoring Counter ID (MCID) for tracking resource usage Requests from a hart to shared resources are tagged with these IDs, allowing resource usage to be associated with the running task. Add a srmcfg field to thread_struct with the same format as the CSR. The context-switch path writes the field to the CSR, and resctrl_arch_set_closid_rmid() updates it when a task is assigned to a resctrl control or monitoring group. A per-cpu cpu_srmcfg_default holds the default srmcfg for each CPU, set by resctrl_arch_set_cpu_default_closid_rmid() on CPU group assignment. On context switch, RCID and MCID inherit from the CPU default independently: a task whose thread RCID field is zero takes the CPU default's RCID, and likewise for MCID. A per-cpu cpu_srmcfg variable mirrors the CSR state to avoid redundant writes. L1D-hot memory access is faster than a CSR read and avoids traps under virtualization. Link: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0 Assisted-by: Claude:claude-opus-4-7 Co-developed-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Drew Fustini <fustini@kernel.org> Link: https://patch.msgid.link/20260729-dfustini-atl-sc-cbqri-dt-v6-3-7c22b05d461b@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Detect the Ssqosid extensionDrew Fustini
Ssqosid is the RISC-V Quality-of-Service (QoS) Identifiers specification which defines the Supervisor Resource Management Configuration (srmcfg) register. Link: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0 Co-developed-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Drew Fustini <fustini@kernel.org> Link: https://patch.msgid.link/20260729-dfustini-atl-sc-cbqri-dt-v6-2-7c22b05d461b@kernel.org [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsingAtish Patra
Smcdeleg extension allows the M-mode to delegate selected counters to S-mode so that it can access those counters and correpsonding hpmevent CSRs without M-mode. Ssccfg (‘Ss’ for Privileged architecture and Supervisor-level extension, ‘ccfg’ for Counter Configuration) provides access to delegated counters and new supervisor-level state. This patch just enables these definitions and enable parsing. Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260807-counter_delegation-v9-9-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Add Smcntrpmf extension parsingAtish Patra
Smcntrpmf extension allows M-mode to enable privilege mode filtering for cycle/instret counters. However, the cyclecfg/instretcfg CSRs are available in Ssccfg only if Smcntrpmf is present. That's why, kernel needs to detect presence of Smcntrpmf extension and enable privilege mode filtering for cycle/instret counters. Reviewed-by: Clément Léger <cleger@rivosinc.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260807-counter_delegation-v9-6-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Add Smcsrind and Sscsrind ISA extension definition and parsingAtish Patra
The S[m|s]csrind extensions extend the indirect CSR access mechanism defined in Smaia/Ssaia extensions. This patch just enables the definition and parsing. Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> [pjw@kernel.org: use official RISC-V extension names in the patch description] Link: https://patch.msgid.link/20260807-counter_delegation-v9-3-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07Revert "riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot"Nam Cao
This reverts commit 5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot"). The commit ensures synchronization between the unaligned vector access speed probe kthread and vDSO data read. But now that the kthread has been removed, this commit can be reverted. Signed-off-by: Nam Cao <namcao@linutronix.de> Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Link: https://patch.msgid.link/50ca78a649faf53f8941bc94c9cf8268b3644d38.1781666867.git.namcao@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: unaligned: stop using kthread for check_vector_unaligned_access()Nam Cao
A kthread is used to run check_vector_unaligned_access() to optimize boot time, allowing the kernel to continue booting without waiting for the unaligned vector speed probe to finish. However, this asynchronous approach introduces several complications. First, the kthread may not complete before a user reads vDSO data, resulting in incorrect values. This was previously addressed by commit 5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot"), which added complex synchronization between the kthread and vDSO reads. Second, it was discovered that the kthread may not finish before vec_check_unaligned_access_speed_all_cpus() (marked with __init) is freed, triggering a page fault. These issues raise the question of whether the kthread is worth the added complexity. A past boot time regression report was actually unrelated to synchronous probing; it was caused by the probe running serially. Since switching to a parallel probe, no further complaints have been made. Furthermore, the unaligned scalar access speed probe takes the same amount of time, runs synchronously, and has caused no issues. Testing shows no noticeable boot time slowdown when running the vector probe synchronously (0.464474s with kthread vs. 0.457991s without). Remove the kthread usage and run the probe synchronously. This simplifies the boot flow and allows for the revert of commit 5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot") Reported-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Closes: https://lore.kernel.org/linux-riscv/20260612-vec_unaligned_drop_init-v1-1-df969210ae34@oss.tenstorrent.com/ Fixes: e7c9d66e313b ("RISC-V: Report vector unaligned access speed hwprobe") Cc: stable@vger.kernel.org Signed-off-by: Nam Cao <namcao@linutronix.de> Acked-by: Jesse Taube <jtaubepe@redhat.com> Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Link: https://patch.msgid.link/1c378963f27c5960e8a57c50b8b444d30954cb54.1781666867.git.namcao@linutronix.de [pjw@kernel.org: updated to apply; adjusted Fixes: tag; fixed my own manual patch application error] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Mark default_power_off() as __noreturnThorsten Blum
Since default_power_off() never returns, annotate it with the __noreturn attribute to improve compiler optimizations. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260727100339.410466-2-thorsten.blum@linux.dev Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: cfi: reduce shadow stack size limit from 2GB to 512MBZong Li
Change the shadow stack size calculation from RLIMIT_STACK/2 (capped at 2GB) to RLIMIT_STACK/8 (capped at 512MB), following David Laight's analysis and recommendation. Rationale: David Laight pointed out that the focus should be on the ratio between shadow stack size and the normal stack size, rather than just the absolute upper limit. His analysis showed that while there are many functions with small stack frames, the majority have stack deltas of over 64 bytes due to saved registers and local variables. Shadow stacks only store return addresses (8 bytes per entry on 64-bit systems), whereas normal stack frames typically consume 64+ bytes. This 8:64 byte ratio means that programs using a lot of stack space are dominated by large buffer allocations and local variables, not extreme recursion depths with minimal local data. For example, with the default RLIMIT_STACK of 8MB: - RLIMIT_STACK/2 gives a 4MB shadow stack supporting 512K nested calls - RLIMIT_STACK/8 gives a 1MB shadow stack supporting 128K nested calls Given typical stack frame sizes of 64+ bytes, RLIMIT_STACK/8 is still conservative and provides adequate depth for practical applications. David noted that this could even be safely halved again. This reduction also better accommodates memory-constrained platforms. On systems with limited physical memory, allocating large shadow stacks can cause virtual memory allocation failures when overcommit mode is set to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER. Suggested-by: David Laight <david.laight.linux@gmail.com> Link: https://lore.kernel.org/all/20260518105725.7afe7a4c@pumpkin/ Signed-off-by: Zong Li <zong.li@sifive.com> Link: https://patch.msgid.link/20260522093634.3530233-1-zong.li@sifive.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: vdso: Simplify cflags remove logicThomas Weißschuh
Listing all flags for each object file is tedious and error-prone. Replace it with a simpler solution. Link: https://lore.kernel.org/all/20260630135316-f26f0e0f-c08c-4d4d-9963-10f9985a7689@linutronix.de/ Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260701-riscv-vdso-lto-v1-2-89db0cd82077@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: kprobes: add test case for c.jal instruction simulationNam Cao
Add a test case validating that kprobes correctly simulates the c.jal instruction on RV32. The test uses two probe points: a forward c.jal and a backward c.jal, and verifies that the containing function returns the expected magic value KPROBE_TEST_MAGIC after kprobe interception. Co-developed-by: Xiaofeng Yuan <xiaofengmian@163.com> Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Xiaofeng Yuan <xiaofengmian@163.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260701081033.49871-3-xiaofengmian@163.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: probes: simulate c.jal instructionXiaofeng Yuan
The c.jal instruction is currently marked REJECTED in kprobes instruction decoding, but it should be SIMULATED like other compressed jump instructions. Add simulate_c_jal() which saves the return address to RA and sets the program counter to the target offset, reusing simulate_c_j for the common jump logic. Although c.jal is RV32-only, the function compiles unconditionally. On RV64, riscv_insn_is_c_jal() always returns 0, so the simulation code is never invoked and the small overhead in kernel size is acceptable. Signed-off-by: Xiaofeng Yuan <xiaofengmian@163.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Tested-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260701081033.49871-2-xiaofengmian@163.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: acpi: Enable ARCH_HAS_ACPI_TABLE_UPGRADEVivian Wang
Implement the various required hooks and enable ARCH_HAS_ACPI_TABLE_UPGRADE to allow use for ACPI_TABLE_UPGRADE, which is useful for debugging ACPI table problems. The implementation is based on arm64's of the same feature due to the similarities of the requirements of the two platforms. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://patch.msgid.link/20260616-riscv-acpi-table-upgrade-v1-2-45902d2dedf9@iscas.ac.cn [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Restart via EFI runtime services when availableAtish Patra
Firmware-preferred reset and EFI capsule update support requires reset via EFI runtime services rather than direction M-mode firmware invocation via SBI. Unlike poweroff, restart mechanism is directly controlled from machine_restart function though. Prefer the EFI runtime ResetSystem() service for restart when UEFI runtime services are available. Signed-off-by: Atish Patra <atishp@meta.com> Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com> Link: https://patch.msgid.link/20260615-efi_reset_shutdown-v1-2-9414edcbbab0@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: efi: Power off via EFI runtime services when availableAtish Patra
When booted via UEFI with runtime services enabled, EFI Reset Shutdown is the firmware-preferred shutdown path: it lets firmware run its own shutdown hooks which may invoke SBI SRST extension internally. However, RISC-V always powers off via the SBI SRST extension today and EFI runtime path is never used even when firmware provides it. Enable the poweroff via EFI by overriding efi_poweroff_required() Signed-off-by: Atish Patra <atishp@meta.com> Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com> Link: https://patch.msgid.link/20260615-efi_reset_shutdown-v1-1-9414edcbbab0@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: hwprobe: Register unaligned probes before usermodeRui Qi
The hwprobe vDSO data is populated by the first riscv_hwprobe syscall. Some values, such as MISALIGNED_VECTOR_PERF, may depend on the async vector unaligned access speed probe registered by check_unaligned_access_all_cpus(). That initcall currently runs at late_initcall level. However, rootfs_initcall enables usermode helpers before late initcalls run, so an early helper can execute userspace and call riscv_hwprobe first. In that case complete_hwprobe_vdso_data() consumes the initial pending_boot_probes reference, populates the vDSO cache, and marks it ready before the later async probe is registered. The eventual probe result then cannot update the already-ready cache. Move check_unaligned_access_all_cpus() to fs_initcall_sync. This still runs after clocksource_done_booting(), so the ktime_get_mono_fast_ns() benchmark uses a stable clocksource, but it runs before rootfs_initcall enables usermode helpers. Any async hwprobe probe is therefore registered before userspace can trigger the one-time vDSO cache population. Cc: stable@vger.kernel.org Fixes: 6455c6c11827 ("riscv: Clean up & optimize unaligned scalar access probe") Signed-off-by: Rui Qi <qirui.001@bytedance.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260721150511.1607105-1-qirui.001@bytedance.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-06riscv: ftrace: Fix ftrace_modify_call failure on kprobed functionsPu Lehui
We are frequently hitting the following splat during the riscv bpf selftests: 00000000026dc75a: expected (7c3ff297) but got (00100073) ------------[ ftrace bug ]------------ ftrace failed to modify [<ffffffff03c44c1c>] bpf_kfunc_common_test+0x4/0x20 [bpf_testmod] actual: e7:82:c2:ce Updating ftrace call site to call a different ftrace function ftrace record flags: 80100002 (2) expected tramp: ffffffff80043904 ------------[ cut here ]------------ WARNING: kernel/trace/ftrace.c:2278 at ftrace_bug+0x46e/0x4b0, CPU#1: test_progs/98 ... [<ffffffff80008f4e>] ftrace_bug+0x46e/0x4b0 [<ffffffff803d3e86>] ftrace_replace_code+0x16e/0x170 [<ffffffff803d42b6>] ftrace_modify_all_code+0x12e/0x1b8 [<ffffffff800430f4>] arch_ftrace_update_code+0x14/0x28 [<ffffffff803e0324>] ftrace_startup+0x14c/0x2a0 [<ffffffff803e133c>] ftrace_startup_subops+0x584/0x1050 [<ffffffff804500e6>] register_ftrace_graph+0x4e6/0x1018 [<ffffffff804cf9f6>] register_fprobe_ips+0xc66/0x12f8 [<ffffffff8049abe8>] bpf_kprobe_multi_link_attach+0x5d8/0xe68 [<ffffffff8050fcaa>] __sys_bpf+0x3d5a/0x47f0 [<ffffffff805107ee>] __riscv_sys_bpf+0xae/0x168 [<ffffffff80034d78>] syscall_handler+0x60/0x100 [<ffffffff8228b4f4>] do_trap_ecall_u+0x174/0x208 [<ffffffff822b69c4>] handle_exception+0x16c/0x178 After debugging, it can be triggered by similar commands below: ``` echo do_nanosleep > set_ftrace_filter echo function > current_tracer echo 'p do_nanosleep' > kprobe_events echo 1 > events/kprobes/enable echo 'f do_nanosleep' > dynamic_events echo 1 > events/fprobes/enable ``` The reason is that attaching a kprobe to an ftrace-traced function entry replaces its initial auipc insn with ebreak. When ftrace_modify_call later runs, it expects auipc insn, so verification fails and triggers ftrace_bug. The expected auipc logic remains conceptually unchanged, and kprobe single-stepping ensures normal execution. Therefore, if the first insn is ebreak, bypassing the check to continue patching the jalr insn is safe and avoids ftrace failures. Fixes: b2137c3b6d7a ("riscv: ftrace: prepare ftrace for atomic code patching") Signed-off-by: Pu Lehui <pulehui@huawei.com> Link: https://patch.msgid.link/20260802094929.3978390-1-pulehui@huaweicloud.com [pjw@kernel.org: fixed reproducer in commit message] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-29riscv: drop __init from vec_check_unaligned_access_speed_all_cpusAnirudh Srinivasan
This function runs within a kthread and need not necessarily finish before system finishes boot and free_initmem() unmaps the .init.text section. This function makes calls to SBI for probing unaligned access speed, and if this is slow for some reason (say some debug prints were added to SBI), the kthread can still be running at this point and result in an instruction page fault when trying to fetch from the freed region. [ 25.642087] Unable to handle kernel paging request at virtual address ffffffff80a04ef8 [ 25.646694] Current vec_check_unali pgtable: 4K pagesize, 48-bit VAs, pgdp=0x00004000316e9000 [ 25.653170] [ffffffff80a04ef8] pgd=000010004be7e401, p4d=000010004be7e401, pud=000010004be7e001, pmd=000010000c3000e3 [ 25.661244] Oops [#1] [ 25.662997] Modules linked in: [ 25.665357] CPU: 3 UID: 0 PID: 42 Comm: vec_check_unali Not tainted 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY [ 25.674669] Hardware name: Tenstorrent Blackhole (DT) [ 25.678545] epc : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.683458] ra : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.688372] epc : ffffffff80a04ef8 ra : ffffffff80a04ef8 sp : ffff8f8000203e20 [ 25.693874] gp : ffffffff814dc168 tp : ffffaf8001ad9900 t0 : 0000000000000000 [ 25.699401] t1 : fffffffffffffff0 t2 : ffffaf8001ad9a10 s0 : ffff8f8000203e30 [ 25.704912] s1 : ffffaf80018dc780 a0 : 0000000000000000 a1 : 0000000000000002 [ 25.710407] a2 : 00000000000001f0 a3 : 0000000000000018 a4 : 0000000000000000 [ 25.715917] a5 : 0000000000000000 a6 : ffffaf8001c03d98 a7 : ffffaf8001c03e30 [ 25.721419] s2 : ffff8f8000023c98 s3 : ffffaf8001aa1240 s4 : ffffffff80a04ee0 [ 25.726937] s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000 [ 25.732450] s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000 [ 25.737944] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000402 [ 25.743481] t5 : 0000000000000040 t6 : 0000000000000004 ssp : 0000000000000000 [ 25.749024] status: 0000000200000120 badaddr: ffffffff80a04ef8 cause: 000000000000000c [ 25.755060] [<ffffffff80a04ef8>] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.760964] [<ffffffff80047a10>] kthread+0xd8/0xfc [ 25.764660] [<ffffffff80010c48>] ret_from_fork_kernel+0x18/0x1c4 [ 25.769220] [<ffffffff80895fe6>] ret_from_fork_kernel_asm+0x16/0x18 [ 25.774018] Code: cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc (cccc) cccc Drop __init from its signature so that this doesn't happen. Fixes: a00e022be531 ("riscv: Annotate unaligned access init functions") Signed-off-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Assisted-by: Claude:claude-opus-4-6 Link: https://patch.msgid.link/20260612-vec_unaligned_drop_init-v1-1-df969210ae34@oss.tenstorrent.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-20entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall ↵Thomas Gleixner
execution The return values of syscall_enter_from_user_mode[_work]() are non-intuitive. Both functions return the syscall number which should be invoked by the architecture specific syscall entry code. The returned number can be: - the unmodified syscall number which was handed in by the caller - a modified syscall number (ptrace, seccomp, trace/probe/bpf) That has an additional twist. If the return value is -1L then the caller is not allowed to modify the return value as that indicates that the modifying entity requests to abort the syscall and set the return value already. That can obviously not be differentiated from a syscall which handed in -1 as syscall number. The most trivial way to deal with that is: set_return_value(regs, -ENOSYS); nr = syscall_enter_from_user_mode(regs, nr); if (valid(nr)) handle_syscall(regs, nr); That's what LOONGARCH, RISCV, and X86 do. But PowerPC and S390 do not preset the return value, so when user space hands in -1 and there is nothing setting the return value in the entry work code, then the syscall is skipped but the return value is whatever random data has been in the return value register. Change the return values of syscall_enter_from_user_mode[_work]() to boolean and return false, when either ptrace or seccomp request to skip the syscall. If they return true, update the syscall number as it might have been changed. That results in slightly different behaviour of the architectures versus tracing. If the syscall tracepoint has probe/BPF attached, those might set the syscall number to -1 and also set the return value. PowerPC and S390 will then overwrite that value with -ENOSYS. The other architectures will just ignore it like any other invalid syscall and use the modified one. Originally-by: Michal Suchánek <msuchanek@suse.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Michal Suchánek <msuchanek@suse.de> Link: https://patch.msgid.link/20260712141346.772209074@kernel.org
2026-07-15riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()Mark Harris
When cpusetsize < cpumask_size(), hwprobe_get_cpus() did not fully initialize its copy of the cpu mask, which could cause non-deterministic results from the riscv_hwprobe syscall on a system with more than 8 CPUs when the supplied cpu mask is empty. Address this by fully initializing the cpu mask. Fixes: e178bf146e4b ("RISC-V: hwprobe: Introduce which-cpus flag") Signed-off-by: Mark Harris <mark.hsj@gmail.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Michael Ellerman <mpe@kernel.org> Link: https://patch.msgid.link/20260714003056.73707-1-mark.hsj@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-14arch/riscv: vdso: remove CFI landing pad from rt_sigreturnAurelien Jarno
When CONFIG_RISCV_USER_CFI is enabled, the CFI version of the vDSO, has a CFI landing pad instruction at the start of __vdso_rt_sigreturn. This breaks libgcc's unwinding code which matches on the first two instructions. Other unwinders that rely on similar instruction matching may also be affected. Since __vdso_rt_sigreturn is reached as part of signal-return handling rather than via an indirect call/jump from userspace, it does not need a CFI landing pad. Remove it and restore the instruction sequence expected by existing unwinding code. This matches what was done on arm64 in commit 9a964285572b ("arm64: vdso: Don't prefix sigreturn trampoline with a BTI C instruction") for a similar issue. Cc: stable@vger.kernel.org Fixes: 37f57bd3faea ("arch/riscv: compile vdso with landing pad and shadow stack note") Co-authored-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://patch.msgid.link/20260623204058.498120-1-aurelien@aurel32.net [pjw@kernel.org: fixed comment style] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-13riscv: vdso: Do not use LTO for the vDSOThomas Weißschuh
With LTO enabled the compiler assumes that the vDSO functions are not used and optimizes them away completely. Currently this happens to __vdso_clock_getres(), __vdso_clock_gettime(), __vdso_getrandom(), __vdso_gettimeofday() and __vdso_riscv_hwprobe(). Disable LTO for the vDSO, as these functions are hand-optimized anyways. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202606301855.WvkSC4kD-lkp@intel.com/ Fixes: 021d23428bdb ("RISC-V: build: Allow LTO to be selected") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260701-riscv-vdso-lto-v1-1-89db0cd82077@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-13riscv: mm: Make mark_new_valid_map() stuff depend on 64BIT && MMUVivian Wang
None of the code relating to mark_new_valid_map() does anything useful without CONFIG_64BIT=y && CONFIG_MMU=y, because the new_valid_map_cpus_check code is only used if CONFIG_64BIT, and the exception codes checked there can only happen with CONFIG_MMU=y. Therefore, make these conditional on CONFIG_64BIT=y && CONFIG_MMU=y to simplify programming, since we do not have to handle CONFIG_MMU=n when changing this code in the future. This also removes some unused code on the entry path for CONFIG_MMU=n. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://patch.msgid.link/20260713-mark-after-vmemmap-populate-v6-1-b945ceba29d4@iscas.ac.cn Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-12riscv/syscall: Use syscall_enter_from_user_mode_randomize_stack()Thomas Gleixner
syscall_enter_from_user_mode_randomize_stack() replaces syscall_enter_from_user_mode() and the subsequent invocation of add_random_kstack_offset(). The advantage is that it applies the stack randomization right after enter_from_user_mode() and thereby avoids the overhead of get/put_cpu_var() as that code is invoked with interrupts disabled. No functional change. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Radu Rendec <radu@rendec.net> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Link: https://patch.msgid.link/20260707190253.974626922@kernel.org
2026-07-06riscv: Prevent NULL pointer dereference in machine_kexec_prepare()Tao Liu
A NULL pointer dereference issue is noticed in riscv's machine_kexec_prepare(), where image->segment[i].buf might be NULL and copied unchecked. The NULL buf comes from ima_add_kexec_buffer(), where kbuf is added by kexec_add_buffer(), but kbuf.buffer is NULL, then it is copied without a check in machine_kexec_prepare(): kexec_file_load -> kimage_file_alloc_init() -> kimage_file_prepare_segments() -> ima_add_kexec_buffer() -> kexec_add_buffer() -> machine_kexec_prepare() -> memcpy() Address this by adding a check before the data copy attempt. Fixes: b7fb4d78a6ad ("RISC-V: use memcpy for kexec_file mode") Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/kexec/CAO7dBbVftLUhd2qrh7hmijTB3PEPfZAhykCGqEfrPoOcSrrj-w@mail.gmail.com/ Acked-by: Baoquan He <bhe@redhat.com> Acked-by: Pratyush Yadav <pratyush@kernel.org> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Signed-off-by: Tao Liu <ltao@redhat.com> Link: https://patch.msgid.link/20260705232706.30265-2-ltao@redhat.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-06-30riscv: probes: save original sp in rethook trampolineMartin Kaiser
Reading a word from the stack in a kretprobe crashes a risc-v kernel. $ cd /sys/kernel/tracing/ $ echo 'r n_tty_write $stack0' > dynamic_events $ echo 1 > events/kprobes/enable Unable to handle kernel paging request at virtual address 0000000200000128 ... [<ffffffff80016d16>] regs_get_kernel_stack_nth+0x26/0x38 [<ffffffff80177196>] process_fetch_insn+0x3ee/0x760 [<ffffffff80177836>] kretprobe_trace_func+0x116/0x1f0 [<ffffffff8017795a>] kretprobe_dispatcher+0x4a/0x58 [<ffffffff8013572e>] kretprobe_rethook_handler+0x5e/0x90 [<ffffffff80180838>] rethook_trampoline_handler+0x70/0x108 [<ffffffff8001ba32>] arch_rethook_trampoline_callback+0x12/0x1c [<ffffffff8001ba84>] arch_rethook_trampoline+0x48/0x94 [<ffffffff8067872a>] tty_write+0x1a/0x30 In regs_get_kernel_stack_nth, regs->sp contains an arbitrary value. arch_rethook_trampoline saves the registers from the probed function in a struct pt_regs. sp is not saved. Instead, sp is decremented for arch_rethook_trampoline's local stack. Fix this crash and save the original sp along with the other registers. Use a0 as a temporary register, it is overwritten anyway. Cc: stable@vger.kernel.org Fixes: c22b0bcb1dd02 ("riscv: Add kprobes supported") Signed-off-by: Martin Kaiser <martin@kaiser.cx> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Link: https://patch.msgid.link/20260630194010.1824039-1-martin@kaiser.cx [pjw@kernel.org: added Fixes tag; cc'ed stable] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-06-30riscv: kexec_file: Add support for crashkernel CMA reservationJinjie Ruan
Commit 35c18f2933c5 ("Add a new optional ",cma" suffix to the crashkernel= command line option") and commit ab475510e042 ("kdump: implement reserve_crashkernel_cma") added CMA support for kdump crashkernel reservation. This allows the kernel to dynamically allocate contiguous memory for crash dumping when needed, rather than permanently reserving a fixed region at boot time. So extend crashkernel CMA reservation support to riscv. The following changes are made to enable CMA reservation: - Parse and obtain the CMA reservation size along with other crashkernel parameters. - Call reserve_crashkernel_cma() to allocate the CMA region for kdump. - Include the CMA-reserved ranges for kdump kernel to use, which was already done in of_kexec_alloc_and_setup_fdt(). - Exclude the CMA-reserved ranges from the crash kernel memory to prevent them from being exported through /proc/vmcore, which was already done in the crash core. Update kernel-parameters.txt to document CMA support for crashkernel on riscv architecture. Cc: Paul Walmsley <pjw@kernel.org> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexandre Ghiti <alex@ghiti.fr> Acked-by: Baoquan He <bhe@redhat.com> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Acked-by: Paul Walmsley <pjw@kernel.org> # arch/riscv Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20260629094746.191843-11-ruanjinjie@huawei.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-06-30riscv: kexec_file: Use crash_prepare_headers() helper to simplify codeJinjie Ruan
Use the newly introduced crash_prepare_headers() function to replace the existing prepare_elf_headers(), allocate cmem and exclude crash kernel memory in the crash core, which reduce code duplication. Only the following two architecture functions need to be implemented: - arch_get_system_nr_ranges(). Call get_nr_ram_ranges_callback() to pre-counts the max number of memory ranges. - arch_crash_populate_cmem(). Use prepare_elf64_ram_headers_callback() to collects the memory ranges and fills them into cmem. Cc: Paul Walmsley <pjw@kernel.org> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Guo Ren <guoren@kernel.org> Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com> Acked-by: Baoquan He <bhe@redhat.com> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Guo Ren <guoren@kernel.org> Link: https://patch.msgid.link/20260629094746.191843-7-ruanjinjie@huawei.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-12 15:58:26 +0000