summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-05RISC-V: Documentation: Add enough title underlines to CMODXPalmer Dabbelt
This reports as a warning in linux-next along the lines of Documentation/arch/riscv/cmodx.rst:14: WARNING: Title underline too short. CMODX in the Kernel Space --------------------- [docutils] Documentation/arch/riscv/cmodx.rst:43: WARNING: Title underline too short. CMODX in the User Space --------------------- [docutils] Documentation/arch/riscv/cmodx.rst:43: WARNING: Title underline too short. CMODX in the User Space --------------------- [docutils] Link: https://lore.kernel.org/all/20250603154544.1602a8b5@canb.auug.org.au/ Fixes: 0e07200b2af6 ("riscv: Documentation: add a description about dynamic ftrace") Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/20250603172856.49925-1-palmer@dabbelt.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05Merge tag 'riscv-mw1-6.16-rc1' of ↵Palmer Dabbelt
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/alexghiti/linux into for-next riscv patches for 6.16-rc1 * Implement atomic patching support for ftrace which finally allows to get rid of stop_machine(). * Support for kexec_file_load() syscall * Improve module loading time by changing the algorithm that counts the number of plt/got entries in a module. * Zicbop is now used in the kernel to prefetch instructions [Palmer: There's been two rounds of surgery on this one, so as a result it's a bit different than the PR.] * alex-pr: (734 commits) riscv: Improve Kconfig help for RISCV_ISA_V_PREEMPTIVE MAINTAINERS: Update Atish's email address riscv: hwprobe: export Zabha extension riscv: Make regs_irqs_disabled() more clear perf symbols: Ignore mapping symbols on riscv RISC-V: Kconfig: Fix help text of CMDLINE_EXTEND riscv: module: Optimize PLT/GOT entry counting riscv: Add support for PUD THP riscv: xchg: Prefetch the destination word for sc.w riscv: Add ARCH_HAS_PREFETCH[W] support with Zicbop riscv: Add support for Zicbop riscv: Introduce Zicbop instructions riscv/kexec_file: Fix comment in purgatory relocator riscv: kexec_file: Support loading Image binary file riscv: kexec_file: Split the loading of kernel and others riscv: Documentation: add a description about dynamic ftrace riscv: ftrace: support direct call using call_ops riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS riscv: ftrace: support PREEMPT riscv: add a data fence for CMODX in the kernel mode ... Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: Improve Kconfig help for RISCV_ISA_V_PREEMPTIVEMiquel Sabaté Solà
Fix a couple of spelling issues plus some minor details on the grammar. Signed-off-by: Miquel Sabaté Solà <mikisabate@gmail.com> Link: https://lore.kernel.org/r/20250501130309.14803-1-mikisabate@gmail.com Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05MAINTAINERS: Update Atish's email addressAtish Patra
My personal upstream email account was previously based on gmail which has become difficult to manage upstream activities lately. Update it to the more reliable linux.dev account. Signed-off-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20250505-update_email_address-v1-1-1c24db506fdb@rivosinc.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05Merge patch series "riscv: Add Zicbop & prefetchw support"Alexandre Ghiti
Alexandre Ghiti <alexghiti@rivosinc.com> says: I found this lost series developed by Guo so here is a respin with the comments on v2 applied. This patch series adds Zicbop support and then enables the Linux prefetch features. * patches from https://lore.kernel.org/r/20250421142441.395849-1-alexghiti@rivosinc.com: riscv: xchg: Prefetch the destination word for sc.w riscv: Add ARCH_HAS_PREFETCH[W] support with Zicbop riscv: Add support for Zicbop riscv: Introduce Zicbop instructions Link: https://lore.kernel.org/r/20250421142441.395849-1-alexghiti@rivosinc.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: hwprobe: export Zabha extensionAlexandre Ghiti
Export Zabha through the hwprobe syscall. Reviewed-by: Clément Léger <cleger@rivosinc.com> Link: https://lore.kernel.org/r/20250421141413.394444-1-alexghiti@rivosinc.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: Make regs_irqs_disabled() more clearTiezhu Yang
The return value of regs_irqs_disabled() is true or false, so change its type to reflect that and also make it always inline. Suggested-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250422113156.25742-1-yangtiezhu@loongson.cn Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05perf symbols: Ignore mapping symbols on riscvHaibo Xu
RISCV ELF use mapping symbols with special names $x, $d to identify regions of RISCV code or code with different ISAs[1]. These symbols don't identify functions, so will confuse the perf output. The patch filters out these symbols at load time, similar to "4886f2ca perf symbols: Ignore mapping symbols on aarch64". [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/ master/riscv-elf.adoc#mapping-symbol Signed-off-by: Haibo Xu <haibo1.xu@intel.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/20250409025202.201046-1-haibo1.xu@intel.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05Merge patch series "riscv: kexec_file: Support loading Image binary file"Palmer Dabbelt
Björn Töpel <bjorn@kernel.org> says: From: Björn Töpel <bjorn@rivosinc.com> Hi! For over a year ago, Daniel and I was testing the V2 of Song's series. I also promised to take the V2, that had been sitting on the lists for too long, to rebase it on a new kernel, and re-test it. One year later, here's the V3! ;-) There are no changes from V2 other, than some simple checkpatch cleanups. Song's original cover: | This series makes the kexec_file_load() syscall support to load | Image binary file. At the same time, corresponding support for | kexec-tools had been pushed to my repo[2]. | | Now, we can leverage that kexec-tools and this series to use the | kexec_load() or kexec_file_load() syscall to boot both vmlinux and | Image file, as seen in these combo tests: | | ``` | 1. kexec -l vmlinux | 2. kexec -l Image | 3. kexec -s -l vmlinux | 4. kexec -s -l Image | ``` Notably, kexec-tools has still not made it upstream. I've prepared a branch on my GH [3], that I indend to post ASAP. That branch is a collection of fixes/features, including Song's userland Image loading. The V2 is here [2], and V1 [1]. I've tested the kexec-file/Image on qemu-rv64, with following combinations: * ACPI/UEFI * DT/UEFI * DT both "regular" kexec (-s + -e), and crashkernels (-p). Note that there are two purgatory patches that has to be present (part of -rc1, so all good): commit 28093cfef5dd ("riscv/kexec_file: Handle R_RISCV_64 in purgatory relocator") commit 3f7023171df4 ("riscv/purgatory: 4B align purgatory_start") [1] https://lore.kernel.org/linux-riscv/20230914020044.1397356-1-songshuaishuai@tinylab.org/ [2] https://lore.kernel.org/linux-riscv/20231016092006.3347632-1-songshuaishuai@tinylab.org/ [3] https://github.com/bjoto/kexec-tools/tree/rv-on-master * patches from https://lore.kernel.org/r/20250409193004.643839-1-bjorn@kernel.org: riscv: kexec_file: Support loading Image binary file riscv: kexec_file: Split the loading of kernel and others Link: https://lore.kernel.org/r/20250409193004.643839-1-bjorn@kernel.org Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05RISC-V: Kconfig: Fix help text of CMDLINE_EXTEND谢致邦 (XIE Zhibang)
It is the built-in command line appended to the bootloader command line, not the bootloader command line appended to the built-in command line. Fixes: 3aed8c43267e ("RISC-V: Update Kconfig to better handle CMDLINE") Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com> Link: https://lore.kernel.org/r/tencent_A93C7FB46BFD20054AD2FEF4645913FF550A@qq.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: module: Optimize PLT/GOT entry countingSamuel Holland
perf reports that 99.63% of the cycles from `modprobe amdgpu` are spent inside module_frob_arch_sections(). This is because amdgpu.ko contains about 300000 relocations in its .rela.text section, and the algorithm in count_max_entries() takes quadratic time. Apply two optimizations from the arm64 code, which together reduce the total execution time by 99.58%. First, sort the relocations so duplicate entries are adjacent. Second, reduce the number of relocations that must be sorted by filtering to only relocations that need PLT/GOT entries, as done in commit d4e0340919fb ("arm64/module: Optimize module load time by optimizing PLT counting"). Unlike the arm64 code, here the filtering and sorting is done in a scratch buffer, because the HI20 relocation search optimization in apply_relocate_add() depends on the original order of the relocations. This allows accumulating PLT/GOT relocations across sections so sorting and counting is only done once per module. Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20250409171526.862481-3-samuel.holland@sifive.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05Merge patch series "riscv: ftrace: atmoic patching and preempt improvements"Alexandre Ghiti
Andy Chiu <andybnac@gmail.com> says: This series makes atomic code patching in ftrace possible and eliminates the need of the stop_machine dance. The major difference of this version is that we merge the CALL_OPS support from Puranjay [1] and make direct calls available for practical uses such as BPF. Thanks for the time reviewing the series and suggestions, we hope this version gets a step closer to happening in the upstream. Please reference the link to v3 below for more introductory view of the implementation [2] Added patch: 2, 4, 10, 11, 12 Modified patch: 5, 6 Unchanged patch: 1, 3, 7, 8, 9 (1, 8 has commit msg modified) Special thanks to Björn for his efforts on testing and guiding the series! [1]: https://lore.kernel.org/lkml/20240306165904.108141-1-puranjay12@gmail.com/ [2]: https://lore.kernel.org/linux-riscv/20241127172908.17149-1-andybnac@gmail.com/ * patches from https://lore.kernel.org/r/20250407180838.42877-1-andybnac@gmail.com: riscv: Documentation: add a description about dynamic ftrace riscv: ftrace: support direct call using call_ops riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS riscv: ftrace: support PREEMPT riscv: add a data fence for CMODX in the kernel mode riscv: vector: Support calling schedule() for preemptible Vector riscv: ftrace: do not use stop_machine to update code riscv: ftrace: prepare ftrace for atomic code patching kernel: ftrace: export ftrace_sync_ipi riscv: ftrace: align patchable functions to 4 Byte boundary riscv: ftrace factor out code defined by !WITH_ARG riscv: ftrace: support fastcc in Clang for WITH_ARGS Link: https://lore.kernel.org/r/20250407180838.42877-1-andybnac@gmail.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
2025-06-05riscv: Add support for PUD THPAlexandre Ghiti
Add the necessary page table functions to deal with PUD THP, this enables the use of PUD pfnmap. Link: https://lore.kernel.org/r/20250321123954.225097-1-alexghiti@rivosinc.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: xchg: Prefetch the destination word for sc.wGuo Ren
The cost of changing a cacheline from shared to exclusive state can be significant, especially when this is triggered by an exclusive store, since it may result in having to retry the transaction. This patch makes use of prefetch.w to prefetch cachelines for write prior to lr/sc loops when using the xchg_small atomic routine. This patch is inspired by commit 0ea366f5e1b6 ("arm64: atomics: prefetch the destination word for write prior to stxr"). Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Signed-off-by: Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/r/20231231082955.16516-4-guoren@kernel.org Tested-by: Andrea Parri <parri.andrea@gmail.com> Link: https://lore.kernel.org/r/20250421142441.395849-5-alexghiti@rivosinc.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: Add ARCH_HAS_PREFETCH[W] support with ZicbopGuo Ren
Enable Linux prefetch and prefetchw primitives using Zicbop. Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Signed-off-by: Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/r/20231231082955.16516-3-guoren@kernel.org Tested-by: Andrea Parri <parri.andrea@gmail.com> Link: https://lore.kernel.org/r/20250421142441.395849-4-alexghiti@rivosinc.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: Add support for ZicbopAlexandre Ghiti
Zicbop introduces cache blocks prefetching instructions, add the necessary support for the kernel to use it in the coming commits. Co-developed-by: Guo Ren <guoren@kernel.org> Signed-off-by: Guo Ren <guoren@kernel.org> Tested-by: Andrea Parri <parri.andrea@gmail.com> Link: https://lore.kernel.org/r/20250421142441.395849-3-alexghiti@rivosinc.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: Introduce Zicbop instructionsAlexandre Ghiti
The S-type instructions are first introduced and then used to define the encoding of the Zicbop prefetching instructions. Co-developed-by: Guo Ren <guoren@kernel.org> Signed-off-by: Guo Ren <guoren@kernel.org> Tested-by: Andrea Parri <parri.andrea@gmail.com> Link: https://lore.kernel.org/r/20250421142441.395849-2-alexghiti@rivosinc.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv/kexec_file: Fix comment in purgatory relocatorYao Zi
Apparently sec_base doesn't mean relocated symbol value, which seems a copy-pasting error in the comment. Assigned with the address of section indexed by sym->st_shndx, it should represent base address of the relevant section. Let's fix the comment to avoid possible confusion. Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file") Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20250326073450.57648-2-ziyao@disroot.org Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: kexec_file: Support loading Image binary fileSong Shuai
This patch creates image_kexec_ops to load Image binary file for kexec_file_load() syscall. Signed-off-by: Song Shuai <songshuaishuai@tinylab.org> Signed-off-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20250409193004.643839-3-bjorn@kernel.org Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: kexec_file: Split the loading of kernel and othersSong Shuai
This is the preparative patch for kexec_file_load Image support. It separates the elf_kexec_load() as two parts: - the first part loads the vmlinux (or Image) - the second part loads other segments (e.g. initrd,fdt,purgatory) And the second part is exported as the load_extra_segments() function which would be used in both kexec-elf.c and kexec-image.c. No functional change intended. Signed-off-by: Song Shuai <songshuaishuai@tinylab.org> Signed-off-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20250409193004.643839-2-bjorn@kernel.org Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: Documentation: add a description about dynamic ftraceAndy Chiu
Add a section in cmodx to describe how dynamic ftrace works on riscv, limitations, and assumptions. Signed-off-by: Andy Chiu <andybnac@gmail.com> Link: https://lore.kernel.org/r/20250407180838.42877-12-andybnac@gmail.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: ftrace: support direct call using call_opsAndy Chiu
jump to FTRACE_ADDR if distance is out of reach Co-developed-by: Björn Töpel <bjorn@rivosinc.com> Signed-off-by: Björn Töpel <bjorn@rivosinc.com> Signed-off-by: Andy Chiu <andybnac@gmail.com> Link: https://lore.kernel.org/r/20250407180838.42877-11-andybnac@gmail.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPSPuranjay Mohan
This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V. This allows each ftrace callsite to provide an ftrace_ops to the common ftrace trampoline, allowing each callsite to invoke distinct tracer functions without the need to fall back to list processing or to allocate custom trampolines for each callsite. This significantly speeds up cases where multiple distinct trace functions are used and callsites are mostly traced by a single tracer. The idea and most of the implementation is taken from the ARM64's implementation of the same feature. The idea is to place a pointer to the ftrace_ops as a literal at a fixed offset from the function entry point, which can be recovered by the common ftrace trampoline. We use -fpatchable-function-entry to reserve 8 bytes above the function entry by emitting 2 4 byte or 4 2 byte nops depending on the presence of CONFIG_RISCV_ISA_C. These 8 bytes are patched at runtime with a pointer to the associated ftrace_ops for that callsite. Functions are aligned to 8 bytes to make sure that the accesses to this literal are atomic. This approach allows for directly invoking ftrace_ops::func even for ftrace_ops which are dynamically-allocated (or part of a module), without going via ftrace_ops_list_func. We've benchamrked this with the ftrace_ops sample module on Spacemit K1 Jupiter: Without this patch: baseline (Linux rivos 6.14.0-09584-g7d06015d936c #3 SMP Sat Mar 29 +-----------------------+-----------------+----------------------------+ | Number of tracers | Total time (ns) | Per-call average time | |-----------------------+-----------------+----------------------------| | Relevant | Irrelevant | 100000 calls | Total (ns) | Overhead (ns) | |----------+------------+-----------------+------------+---------------| | 0 | 0 | 1357958 | 13 | - | | 0 | 1 | 1302375 | 13 | - | | 0 | 2 | 1302375 | 13 | - | | 0 | 10 | 1379084 | 13 | - | | 0 | 100 | 1302458 | 13 | - | | 0 | 200 | 1302333 | 13 | - | |----------+------------+-----------------+------------+---------------| | 1 | 0 | 13677833 | 136 | 123 | | 1 | 1 | 18500916 | 185 | 172 | | 1 | 2 | 22856459 | 228 | 215 | | 1 | 10 | 58824709 | 588 | 575 | | 1 | 100 | 505141584 | 5051 | 5038 | | 1 | 200 | 1580473126 | 15804 | 15791 | |----------+------------+-----------------+------------+---------------| | 1 | 0 | 13561000 | 135 | 122 | | 2 | 0 | 19707292 | 197 | 184 | | 10 | 0 | 67774750 | 677 | 664 | | 100 | 0 | 714123125 | 7141 | 7128 | | 200 | 0 | 1918065668 | 19180 | 19167 | +----------+------------+-----------------+------------+---------------+ Note: per-call overhead is estimated relative to the baseline case with 0 relevant tracers and 0 irrelevant tracers. With this patch: v4-rc4 (Linux rivos 6.14.0-09598-gd75747611c93 #4 SMP Sat Mar 29 +-----------------------+-----------------+----------------------------+ | Number of tracers | Total time (ns) | Per-call average time | |-----------------------+-----------------+----------------------------| | Relevant | Irrelevant | 100000 calls | Total (ns) | Overhead (ns) | |----------+------------+-----------------+------------+---------------| | 0 | 0 | 1459917 | 14 | - | | 0 | 1 | 1408000 | 14 | - | | 0 | 2 | 1383792 | 13 | - | | 0 | 10 | 1430709 | 14 | - | | 0 | 100 | 1383791 | 13 | - | | 0 | 200 | 1383750 | 13 | - | |----------+------------+-----------------+------------+---------------| | 1 | 0 | 5238041 | 52 | 38 | | 1 | 1 | 5228542 | 52 | 38 | | 1 | 2 | 5325917 | 53 | 40 | | 1 | 10 | 5299667 | 52 | 38 | | 1 | 100 | 5245250 | 52 | 39 | | 1 | 200 | 5238459 | 52 | 39 | |----------+------------+-----------------+------------+---------------| | 1 | 0 | 5239083 | 52 | 38 | | 2 | 0 | 19449417 | 194 | 181 | | 10 | 0 | 67718584 | 677 | 663 | | 100 | 0 | 709840708 | 7098 | 7085 | | 200 | 0 | 2203580626 | 22035 | 22022 | +----------+------------+-----------------+------------+---------------+ Note: per-call overhead is estimated relative to the baseline case with 0 relevant tracers and 0 irrelevant tracers. As can be seen from the above: a) Whenever there is a single relevant tracer function associated with a tracee, the overhead of invoking the tracer is constant, and does not scale with the number of tracers which are *not* associated with that tracee. b) The overhead for a single relevant tracer has dropped to ~1/3 of the overhead prior to this series (from 122ns to 38ns). This is largely due to permitting calls to dynamically-allocated ftrace_ops without going through ftrace_ops_list_func. Signed-off-by: Puranjay Mohan <puranjay12@gmail.com> [update kconfig, asm, refactor] Signed-off-by: Andy Chiu <andybnac@gmail.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20250407180838.42877-10-andybnac@gmail.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: ftrace: support PREEMPTAndy Chiu
Now, we can safely enable dynamic ftrace with kernel preemption. Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Reviewed-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20250407180838.42877-9-andybnac@gmail.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: add a data fence for CMODX in the kernel modeAndy Chiu
RISC-V spec explicitly calls out that a local fence.i is not enough for the code modification to be visble from a remote hart. In fact, it states: To make a store to instruction memory visible to all RISC-V harts, the writing hart also has to execute a data FENCE before requesting that all remote RISC-V harts execute a FENCE.I. Although current riscv drivers for IPI use ordered MMIO when sending IPIs in order to synchronize the action between previous csd writes, riscv does not restrict itself to any particular flavor of IPI. Any driver or firmware implementation that does not order data writes before the IPI may pose a risk for code-modifying race. Thus, add a fence here to order data writes before making the IPI. Signed-off-by: Andy Chiu <andybnac@gmail.com> Reviewed-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20250407180838.42877-8-andybnac@gmail.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: vector: Support calling schedule() for preemptible VectorAndy Chiu
Each function entry implies a call to ftrace infrastructure. And it may call into schedule in some cases. So, it is possible for preemptible kernel-mode Vector to implicitly call into schedule. Since all V-regs are caller-saved, it is possible to drop all V context when a thread voluntarily call schedule(). Besides, we currently don't pass argument through vector register, so we don't have to save/restore V-regs in ftrace trampoline. Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Link: https://lore.kernel.org/r/20250407180838.42877-7-andybnac@gmail.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: ftrace: do not use stop_machine to update codeAndy Chiu
Now it is safe to remove dependency from stop_machine() for us to patch code in ftrace. Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Link: https://lore.kernel.org/r/20250407180838.42877-6-andybnac@gmail.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: ftrace: prepare ftrace for atomic code patchingAndy Chiu
We use an AUIPC+JALR pair to jump into a ftrace trampoline. Since instruction fetch can break down to 4 byte at a time, it is impossible to update two instructions without a race. In order to mitigate it, we initialize the patchable entry to AUIPC + NOP4. Then, the run-time code patching can change NOP4 to JALR to eable/disable ftrcae from a function. This limits the reach of each ftrace entry to +-2KB displacing from ftrace_caller. Starting from the trampoline, we add a level of indirection for it to reach ftrace caller target. Now, it loads the target address from a memory location, then perform the jump. This enable the kernel to update the target atomically. The new don't-stop-the-world text patching on change only one RISC-V instruction: | -8: &ftrace_ops of the associated tracer function. | <ftrace enable>: | 0: auipc t0, hi(ftrace_caller) | 4: jalr t0, lo(ftrace_caller) | | -8: &ftrace_nop_ops | <ftrace disable>: | 0: auipc t0, hi(ftrace_caller) | 4: nop This means that f+0x0 is fixed, and should not be claimed by ftrace, e.g. kprobe should be able to put a probe in f+0x0. Thus, we adjust the offset and MCOUNT_INSN_SIZE accordingly. [ alex: Fix build errors with !CONFIG_DYNAMIC_FTRACE ] Co-developed-by: Björn Töpel <bjorn@rivosinc.com> Signed-off-by: Björn Töpel <bjorn@rivosinc.com> Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Link: https://lore.kernel.org/r/20250407180838.42877-5-andybnac@gmail.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05kernel: ftrace: export ftrace_sync_ipiAndy Chiu
The following ftrace patch for riscv uses a data store to update ftrace function. Therefore, a romote fence is required to order it against function_trace_op updates. The mechanism is similar to the fence between function_trace_op and update_ftrace_func in the generic ftrace, so we leverage the same ftrace_sync_ipi function. [ alex: Fix build warning when !CONFIG_DYNAMIC_FTRACE ] Signed-off-by: Andy Chiu <andybnac@gmail.com> Link: https://lore.kernel.org/r/20250407180838.42877-4-andybnac@gmail.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: ftrace: align patchable functions to 4 Byte boundaryAndy Chiu
We are changing ftrace code patching in order to remove dependency from stop_machine() and enable kernel preemption. This requires us to align functions entry at a 4-B align address. However, -falign-functions on older versions of GCC alone was not strong enoungh to align all functions. In fact, cold functions are not aligned after turning on optimizations. We consider this is a bug in GCC and turn off guess-branch-probility as a workaround to align all functions. GCC bug id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345 The option -fmin-function-alignment is able to align all functions properly on newer versions of gcc. So, we add a cc-option to test if the toolchain supports it. Suggested-by: Evgenii Shatokhin <e.shatokhin@yadro.com> Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Reviewed-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20250407180838.42877-3-andybnac@gmail.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: ftrace factor out code defined by !WITH_ARGAndy Chiu
DYNAMIC_FTRACE selects DYNAMIC_FTRACE_WITH_ARGS and mcount-dyn.S in riscv, so we can remove ifdef jargons of WITH_ARG when it is known that DYNAMIC_FTRACE is true. Signed-off-by: Andy Chiu <andybnac@gmail.com> Link: https://lore.kernel.org/r/20250407180838.42877-2-andybnac@gmail.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: ftrace: support fastcc in Clang for WITH_ARGSAndy Chiu
Some caller-saved registers which are not defined as function arguments in the ABI can still be passed as arguments when the kernel is compiled with Clang. As a result, we must save and restore those registers to prevent ftrace from clobbering them. - [1]: https://reviews.llvm.org/D68559 Reported-by: Evgenii Shatokhin <e.shatokhin@yadro.com> Closes: https://lore.kernel.org/linux-riscv/7e7c7914-445d-426d-89a0-59a9199c45b1@yadro.com/ Fixes: 7caa9765465f ("ftrace: riscv: move from REGS to ARGS") Acked-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Björn Töpel <bjorn@rivosinc.com> Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20250407180838.42877-1-andybnac@gmail.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-02Revert "RISC-V: vDSO: Wire up getrandom() vDSO implementation"Palmer Dabbelt
This has been on -next for a bit, but it's broken and there's already a v2. So I'm reverting it to avoid more rebasing. This reverts commit 89079520cef65d6da1e864eab4464effe5396e23. Link: https://lore.kernel.org/r/20250602173315.20228-1-palmer@dabbelt.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-05-08Merge patch series "riscv: Add vendor extensions support for SiFive"Palmer Dabbelt
Cyan Yang <cyan.yang@sifive.com> says: This patch set adds four vendor-specific ISA extensions from SiFive: "xsfvqmaccdod", "xsfvqmaccqoq", "xsfvfnrclipxfqf", and "xsfvfwmaccqqq". Additionally, a new hwprobe key, RISCV_HWPROBE_KEY_VENDOR_EXT_SIFIVE_0, has been added to query which SiFive vendor extensions are supported on the current platform. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-1-cyan.yang@sifive.com * b4-shazam-merge: riscv: hwprobe: Add SiFive xsfvfwmaccqqq vendor extension riscv: hwprobe: Document SiFive xsfvfwmaccqqq vendor extension riscv: Add SiFive xsfvfwmaccqqq vendor extension dt-bindings: riscv: Add xsfvfwmaccqqq ISA extension description riscv: hwprobe: Add SiFive xsfvfnrclipxfqf vendor extension riscv: hwprobe: Document SiFive xsfvfnrclipxfqf vendor extension riscv: Add SiFive xsfvfnrclipxfqf vendor extension dt-bindings: riscv: Add xsfvfnrclipxfqf ISA extension description riscv: hwprobe: Add SiFive vendor extension support and probe for xsfqmaccdod and xsfqmaccqoq riscv: hwprobe: Document SiFive xsfvqmaccdod and xsfvqmaccqoq vendor extensions riscv: Add SiFive xsfvqmaccdod and xsfvqmaccqoq vendor extensions dt-bindings: riscv: Add xsfvqmaccdod and xsfvqmaccqoq ISA extension description Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: hwprobe: Add SiFive xsfvfwmaccqqq vendor extensionCyan Yang
Add hwprobe for SiFive "xsfvfwmaccqqq" vendor extension. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-13-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: hwprobe: Document SiFive xsfvfwmaccqqq vendor extensionCyan Yang
Document the support for matrix multiply accumulate instruction from SiFive using RISCV_HWPROBE_VENDOR_EXT_XSFVFWMACCQQQ. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-12-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: Add SiFive xsfvfwmaccqqq vendor extensionCyan Yang
Add SiFive vendor extension "xsfvfwmaccqqq" support to the kernel. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-11-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08dt-bindings: riscv: Add xsfvfwmaccqqq ISA extension descriptionCyan Yang
Add "xsfvfwmaccqqq" ISA extension which is provided by SiFive for matrix multiply accumulate instructions support. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250418053239.4351-10-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: hwprobe: Add SiFive xsfvfnrclipxfqf vendor extensionCyan Yang
Add hwprobe for SiFive "xsfvfnrclipxfqf" vendor extension. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-9-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: hwprobe: Document SiFive xsfvfnrclipxfqf vendor extensionCyan Yang
Document the support for SiFive vendor extensions for FP32-to-int8 Ranged Clip Instructions using RISCV_HWPROBE_VENDOR_EXT_XSFVFNRCLIPXFQF. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-8-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: Add SiFive xsfvfnrclipxfqf vendor extensionCyan Yang
Add SiFive vendor extension "xsfvfnrclipxfqf" support to the kernel. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-7-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08dt-bindings: riscv: Add xsfvfnrclipxfqf ISA extension descriptionCyan Yang
Add "xsfvfnrclipxfqf" ISA extension which is provided by SiFive for FP32-to-int8 ranged clip instructions support. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250418053239.4351-6-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: hwprobe: Add SiFive vendor extension support and probe for ↵Cyan Yang
xsfqmaccdod and xsfqmaccqoq Add a new hwprobe key "RISCV_HWPROBE_KEY_VENDOR_EXT_SIFIVE_0" which allows userspace to probe for the new vendor extensions from SiFive. Also, add new hwprobe for SiFive "xsfvqmaccdod" and "xsfvqmaccqoq" vendor extensions. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-5-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: hwprobe: Document SiFive xsfvqmaccdod and xsfvqmaccqoq vendor extensionsCyan Yang
Document the support for sifive vendor extensions using the key RISCV_HWPROBE_KEY_VENDOR_EXT_SIFIVE_0 and two vendor extensions for SiFive Int8 Matrix Multiplication Instructions using RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCDOD and RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCQOQ. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-4-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: Add SiFive xsfvqmaccdod and xsfvqmaccqoq vendor extensionsCyan Yang
Add SiFive vendor extension support to the kernel with the target of "xsfvqmaccdod" and "xsfvqmaccqoq". Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-3-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08dt-bindings: riscv: Add xsfvqmaccdod and xsfvqmaccqoq ISA extension descriptionCyan Yang
Add "xsfvqmaccdod" and "xsfvqmaccqoq" ISA extensions which are provided by SiFive for int8 matrix multiplication instructions support. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250418053239.4351-2-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: vDSO: Remove --hash-style=bothXi Ruoyao
When RISC-V borned, DT_GNU_HASH had already became the de-facto standard so DT_HASH is just wasting storage space. Remove the explicit --hash-style=both setting and rely on the distro toolchain default, which is most likely "gnu" (i.e. generating only DT_GNU_HASH, no DT_HASH). Following the logic of commit 48f6430505c0 ("arm64/vdso: Remove --hash-style=sysv"). Signed-off-by: Xi Ruoyao <xry111@xry111.site> Link: https://lore.kernel.org/r/20250224112042.60282-2-xry111@xry111.site Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08Merge patch series "riscv: uaccess: optimisations"Palmer Dabbelt
Cyril Bur <cyrilbur@tenstorrent.com> says: This series tries to optimize riscv uaccess by allowing the use of user_access_begin() and user_access_end() which permits grouping user accesses and avoiding the CSR write penalty for each access. The error path can also be optimised using asm goto which patches 3 and 4 achieve. This will speed up jumping to labels by avoiding the need of an intermediary error type variable within the uaccess macros I did read the discussion this series generated. It isn't clear to me which direction to take the patches, if any. * b4-shazam-merge: riscv: uaccess: use 'asm_goto_output' for get_user() riscv: uaccess: use 'asm goto' for put_user() riscv: uaccess: use input constraints for ptr of __put_user() riscv: implement user_access_begin() and families riscv: save the SR_SUM status over switches Link: https://lore.kernel.org/r/20250410070526.3160847-1-cyrilbur@tenstorrent.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: uaccess: use 'asm_goto_output' for get_user()Jisheng Zhang
With 'asm goto' we don't need to test the error etc, the exception just jumps to the error handling directly. Unlike put_user(), get_user() must work around GCC bugs [1] when using output clobbers in an asm goto statement. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 # 1 Signed-off-by: Jisheng Zhang <jszhang@kernel.org> [Cyril Bur: Rewritten commit message] Signed-off-by: Cyril Bur <cyrilbur@tenstorrent.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250410070526.3160847-6-cyrilbur@tenstorrent.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: uaccess: use 'asm goto' for put_user()Jisheng Zhang
With 'asm goto' we don't need to test the error etc, the exception just jumps to the error handling directly. Because there are no output clobbers which could trigger gcc bugs [1] the use of asm_goto_output() macro is not necessary here. Not using asm_goto_output() is desirable as the generated output asm will be cleaner. Use of the volatile keyword is redundant as per gcc 14.2.0 manual section 6.48.2.7 Goto Labels: > Also note that an asm goto statement is always implicitly considered volatile. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 # 1 Signed-off-by: Jisheng Zhang <jszhang@kernel.org> [Cyril Bur: Rewritten commit message] Signed-off-by: Cyril Bur <cyrilbur@tenstorrent.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250410070526.3160847-5-cyrilbur@tenstorrent.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>