aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2023-08-31riscv: support PREEMPT_DYNAMIC with static keysJisheng Zhang2-1/+14
Currently, each architecture can support PREEMPT_DYNAMIC through either static calls or static keys. To support PREEMPT_DYNAMIC on riscv, we face three choices: 1. only add static calls support to riscv As Mark pointed out in commit 99cf983cc8bc ("sched/preempt: Add PREEMPT_DYNAMIC using static keys"), static keys "...should have slightly lower overhead than non-inline static calls, as this effectively inlines each trampoline into the start of its callee. This may avoid redundant work, and may integrate better with CFI schemes." So even we add static calls(without inline static calls) to riscv, static keys is still a better choice. 2. add static calls and inline static calls to riscv Per my understanding, inline static calls requires objtool support which is not easy. 3. use static keys While riscv doesn't have static calls support, it supports static keys perfectly. So this patch selects HAVE_PREEMPT_DYNAMIC_KEY to enable support for PREEMPT_DYNAMIC on riscv, so that the preemption model can be chosen at boot time. It also patches asm-generic/preempt.h, mainly to add __preempt_schedule() and __preempt_schedule_notrace() macros for PREEMPT_DYNAMIC case. Other architectures which use generic preempt.h can also benefit from this patch by simply selecting HAVE_PREEMPT_DYNAMIC_KEY to enable PREEMPT_DYNAMIC if they supports static keys. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230716164925.1858-1-jszhang@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-31riscv: Move create_tmp_mapping() to init sectionsAlexandre Ghiti1-1/+1
This function is only used at boot time so mark it as __init. Fixes: 96f9d4daf745 ("riscv: Rework kasan population functions") Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230704074357.233982-2-alexghiti@rivosinc.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-31riscv: Mark KASAN tmp* page tables variables as staticAlexandre Ghiti1-3/+3
tmp_pg_dir, tmp_p4d and tmp_pud are only used in kasan_init.c so they should be declared as static. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306282202.bODptiGE-lkp@intel.com/ Fixes: 96f9d4daf745 ("riscv: Rework kasan population functions") Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230704074357.233982-1-alexghiti@rivosinc.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-31riscv: mm: use bitmap_zero() APIYe Xingchen1-1/+1
bitmap_zero() is faster than bitmap_clear(), so use bitmap_zero() instead of bitmap_clear(). Signed-off-by: Ye Xingchen <ye.xingchen@zte.com.cn> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/202305061711417142802@zte.com.cn Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-31riscv: enable DEBUG_FORCE_FUNCTION_ALIGN_64BJisheng Zhang1-1/+1
Allow to force all function address 64B aligned as it is possible for other architectures. This may be useful when verify if performance bump is caused by function alignment changes. Before commit 1bf18da62106 ("lib/Kconfig.debug: add ARCH dependency for FUNCTION_ALIGN option"), riscv supports enabling the DEBUG_FORCE_FUNCTION_ALIGN_64B option, but after that commit, each arch needs to claim the support explicitly. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230727160356.3874-1-jszhang@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-31riscv: remove redundant mv instructionsNam Cao1-5/+1
Some mv instructions were useful when first introduced to preserve a0 and a1 before function calls. However the code has changed and they are now redundant. Remove them. Signed-off-by: Nam Cao <namcaov@gmail.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230725053835.138910-1-namcaov@gmail.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23RISC-V: mm: Document mmap changesCharlie Jenkins1-0/+22
The behavior of mmap is modified with this patch series, so explain the changes to the mmap hint address behavior. Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230809232218.849726-5-charlie@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23RISC-V: mm: Update pgtable comment documentationCharlie Jenkins1-3/+5
sv57 is supported in the kernel so pgtable.h should reflect that. Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230809232218.849726-4-charlie@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23RISC-V: mm: Add tests for RISC-V mmCharlie Jenkins7-1/+164
Add tests that enforce mmap hint address behavior. mmap should default to sv48. mmap will provide an address at the highest address space that can fit into the hint address, unless the hint address is less than sv39 and not 0, then it will return a sv39 address. These tests are split into two files: mmap_default.c and mmap_bottomup.c because a new process must be exec'd in order to change the mmap layout. The run_mmap.sh script sets the stack to be unlimited for the mmap_bottomup.c test which triggers a bottomup layout. Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/20230809232218.849726-3-charlie@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23RISC-V: mm: Restrict address space for sv39,sv48,sv57Charlie Jenkins3-9/+70
Make sv48 the default address space for mmap as some applications currently depend on this assumption. A hint address passed to mmap will cause the largest address space that fits entirely into the hint to be used. If the hint is less than or equal to 1<<38, an sv39 address will be used. An exception is that if the hint address is 0, then a sv48 address will be used. After an address space is completely full, the next smallest address space will be used. Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/20230809232218.849726-2-charlie@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23riscv: enable DMA_BOUNCE_UNALIGNED_KMALLOC for !dma_coherentJisheng Zhang1-0/+1
With the DMA bouncing of unaligned kmalloc() buffers now in place, enable it for riscv when RISCV_DMA_NONCOHERENT=y to allow the kmalloc-{8,16,32,96} caches. Since RV32 doesn't enable SWIOTLB yet, and I didn't see any dma noncoherent RV32 platforms in the mainline, so skip RV32 now by only enabling DMA_BOUNCE_UNALIGNED_KMALLOC if SWIOTLB is available. Once we see such requirement on RV32, we can enable it then. NOTE: we didn't force to create the swiotlb buffer even when the end of RAM is within the 32-bit physical address range. That's to say: For RV64 with > 4GB memory, the feature is enabled. For RV64 with <= 4GB memory, the feature isn't enabled by default. We rely on users to pass "swiotlb=mmnn,force" where mmnn is the Number of I/O TLB slabs, see kernel-parameters.txt for details. Tested on Sipeed Lichee Pi 4A with 8GB DDR and Sipeed M1S BL808 Dock board. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230718152214.2907-3-jszhang@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23riscv: allow kmalloc() caches aligned to the smallest valueJisheng Zhang4-0/+25
Currently, riscv defines ARCH_DMA_MINALIGN as L1_CACHE_BYTES, I.E 64Bytes, if CONFIG_RISCV_DMA_NONCOHERENT=y. To support unified kernel Image, usually we have to enable CONFIG_RISCV_DMA_NONCOHERENT, thus it brings some bad effects to coherent platforms: Firstly, it wastes memory, kmalloc-96, kmalloc-32, kmalloc-16 and kmalloc-8 slab caches don't exist any more, they are replaced with either kmalloc-128 or kmalloc-64. Secondly, larger than necessary kmalloc aligned allocations results in unnecessary cache/TLB pressure. This issue also exists on arm64 platforms. From last year, Catalin tried to solve this issue by decoupling ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN, limiting kmalloc() minimum alignment to dma_get_cache_alignment() and replacing ARCH_KMALLOC_MINALIGN usage in various drivers with ARCH_DMA_MINALIGN etc.[1] One fact we can make use of for riscv: if the CPU doesn't support ZICBOM or T-HEAD CMO, we know the platform is coherent. Based on Catalin's work and above fact, we can easily solve the kmalloc align issue for riscv: we can override dma_get_cache_alignment(), then let it return ARCH_DMA_MINALIGN at the beginning and return 1 once we know the underlying HW neither supports ZICBOM nor supports T-HEAD CMO. So what about if the CPU supports ZICBOM or T-HEAD CMO, but all the devices are dma coherent? Well, we use ARCH_DMA_MINALIGN as the kmalloc minimum alignment, nothing changed in this case. This case can be improved in the future. After this patch, a simple test of booting to a small buildroot rootfs on qemu shows: kmalloc-96 5041 5041 96 ... kmalloc-64 9606 9606 64 ... kmalloc-32 5128 5128 32 ... kmalloc-16 7682 7682 16 ... kmalloc-8 10246 10246 8 ... So we save about 1268KB memory. The saving will be much larger in normal OS env on real HW platforms. Link: https://lore.kernel.org/linux-arm-kernel/20230524171904.3967031-1-catalin.marinas@arm.com/ [1] Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230718152214.2907-2-jszhang@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23riscv: support the elf-fdpic binfmt loaderGreg Ungerer4-2/+20
Add support for enabling and using the binfmt_elf_fdpic program loader on RISC-V platforms. The most important change is to setup registers during program load to pass the mapping addresses to the new process. One of the interesting features of the elf-fdpic loader is that it also allows appropriately compiled ELF format binaries to be loaded on nommu systems. Appropriate being those compiled with -pie. Signed-off-by: Greg Ungerer <gerg@kernel.org> Acked-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230711130754.481209-3-gerg@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23binfmt_elf_fdpic: support 64-bit systemsGreg Ungerer3-20/+47
The binfmt_flat_fdpic code has a number of 32-bit specific data structures associated with it. Extend it to be able to support and be used on 64-bit systems as well. The new code defines a number of key 64-bit variants of the core elf-fdpic data structures - along side the existing 32-bit sized ones. A common set of generic named structures are defined to be either the 32-bit or 64-bit ones as required at compile time. This is a similar technique to that used in the ELF binfmt loader. For example: elf_fdpic_loadseg is either elf32_fdpic_loadseg or elf64_fdpic_loadseg elf_fdpic_loadmap is either elf32_fdpic_loadmap or elf64_fdpic_loadmap the choice based on ELFCLASS32 or ELFCLASS64. Signed-off-by: Greg Ungerer <gerg@kernel.org> Acked-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230711130754.481209-2-gerg@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23riscv: Allow CONFIG_CFI_CLANG to be selectedSami Tolvanen1-0/+1
Select ARCH_SUPPORTS_CFI_CLANG to allow CFI_CLANG to be selected on riscv. Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Link: https://lore.kernel.org/r/20230710183544.999540-14-samitolvanen@google.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23riscv/purgatory: Disable CFISami Tolvanen1-0/+4
Filter out CC_FLAGS_CFI when CONFIG_CFI_CLANG. Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Link: https://lore.kernel.org/r/20230710183544.999540-13-samitolvanen@google.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23riscv: Add CFI error handlingSami Tolvanen6-1/+115
With CONFIG_CFI_CLANG, the compiler injects a type preamble immediately before each function and a check to validate the target function type before indirect calls: ; type preamble .word <id> function: ... ; indirect call check lw t1, -4(a0) lui t2, <hi20> addiw t2, t2, <lo12> beq t1, t2, .Ltmp0 ebreak .Ltmp0: jarl a0 Implement error handling code for the ebreak traps emitted for the checks. This produces the following oops on a CFI failure (generated using lkdtm): [ 21.177245] CFI failure at lkdtm_indirect_call+0x22/0x32 [lkdtm] (target: lkdtm_increment_int+0x0/0x18 [lkdtm]; expected type: 0x3ad55aca) [ 21.178483] Kernel BUG [#1] [ 21.178671] Modules linked in: lkdtm [ 21.179037] CPU: 1 PID: 104 Comm: sh Not tainted 6.3.0-rc6-00037-g37d5ec6297ab #1 [ 21.179511] Hardware name: riscv-virtio,qemu (DT) [ 21.179818] epc : lkdtm_indirect_call+0x22/0x32 [lkdtm] [ 21.180106] ra : lkdtm_CFI_FORWARD_PROTO+0x48/0x7c [lkdtm] [ 21.180426] epc : ffffffff01387092 ra : ffffffff01386f14 sp : ff20000000453cf0 [ 21.180792] gp : ffffffff81308c38 tp : ff6000000243f080 t0 : ff20000000453b78 [ 21.181157] t1 : 000000003ad55aca t2 : 000000007e0c52a5 s0 : ff20000000453d00 [ 21.181506] s1 : 0000000000000001 a0 : ffffffff0138d170 a1 : ffffffff013870bc [ 21.181819] a2 : b5fea48dd89aa700 a3 : 0000000000000001 a4 : 0000000000000fff [ 21.182169] a5 : 0000000000000004 a6 : 00000000000000b7 a7 : 0000000000000000 [ 21.182591] s2 : ff20000000453e78 s3 : ffffffffffffffea s4 : 0000000000000012 [ 21.183001] s5 : ff600000023c7000 s6 : 0000000000000006 s7 : ffffffff013882a0 [ 21.183653] s8 : 0000000000000008 s9 : 0000000000000002 s10: ffffffff0138d878 [ 21.184245] s11: ffffffff0138d878 t3 : 0000000000000003 t4 : 0000000000000000 [ 21.184591] t5 : ffffffff8133df08 t6 : ffffffff8133df07 [ 21.184858] status: 0000000000000120 badaddr: 0000000000000000 cause: 0000000000000003 [ 21.185415] [<ffffffff01387092>] lkdtm_indirect_call+0x22/0x32 [lkdtm] [ 21.185772] [<ffffffff01386f14>] lkdtm_CFI_FORWARD_PROTO+0x48/0x7c [lkdtm] [ 21.186093] [<ffffffff01383552>] lkdtm_do_action+0x22/0x34 [lkdtm] [ 21.186445] [<ffffffff0138350c>] direct_entry+0x128/0x13a [lkdtm] [ 21.186817] [<ffffffff8033ed8c>] full_proxy_write+0x58/0xb2 [ 21.187352] [<ffffffff801d4fe8>] vfs_write+0x14c/0x33a [ 21.187644] [<ffffffff801d5328>] ksys_write+0x64/0xd4 [ 21.187832] [<ffffffff801d53a6>] sys_write+0xe/0x1a [ 21.188171] [<ffffffff80003996>] ret_from_syscall+0x0/0x2 [ 21.188595] Code: 0513 0f65 a303 ffc5 53b7 7e0c 839b 2a53 0363 0073 (9002) 9582 [ 21.189178] ---[ end trace 0000000000000000 ]--- [ 21.189590] Kernel panic - not syncing: Fatal exception Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> # ISA bits Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Link: https://lore.kernel.org/r/20230710183544.999540-12-samitolvanen@google.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23riscv: Add ftrace_stub_graphSami Tolvanen1-0/+4
Commit 883bbbffa5a4 ("ftrace,kcfi: Separate ftrace_stub() and ftrace_stub_graph()") added a separate ftrace_stub_graph function for CFI_CLANG. Add the stub to fix FUNCTION_GRAPH_TRACER compatibility with CFI. Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Link: https://lore.kernel.org/r/20230710183544.999540-11-samitolvanen@google.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23riscv: Add types to indirectly called assembly functionsSami Tolvanen2-4/+6
With CONFIG_CFI_CLANG, assembly functions indirectly called from C code must be annotated with type identifiers to pass CFI checking. Use the SYM_TYPED_START macro to add types to the relevant functions. Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Link: https://lore.kernel.org/r/20230710183544.999540-10-samitolvanen@google.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23riscv: Implement syscall wrappersSami Tolvanen6-7/+108
Commit f0bddf50586d ("riscv: entry: Convert to generic entry") moved syscall handling to C code, which exposed function pointer type mismatches that trip fine-grained forward-edge Control-Flow Integrity (CFI) checks as syscall handlers are all called through the same syscall_t pointer type. To fix the type mismatches, implement pt_regs based syscall wrappers similarly to x86 and arm64. This patch is based on arm64 syscall wrappers added in commit 4378a7d4be30 ("arm64: implement syscall wrappers"), where the main goal was to minimize the risk of userspace-controlled values being used under speculation. This may be a concern for riscv in future as well. Following other architectures, the syscall wrappers generate three functions for each syscall; __riscv_<compat_>sys_<name> takes a pt_regs pointer and extracts arguments from registers, __se_<compat_>sys_<name> is a sign-extension wrapper that casts the long arguments to the correct types for the real syscall implementation, which is named __do_<compat_>sys_<name>. Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Link: https://lore.kernel.org/r/20230710183544.999540-9-samitolvanen@google.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-23riscv: Require FRAME_POINTER for some configurationsBjörn Töpel2-3/+1
Some V configurations implicitly turn on '-fno-omit-frame-pointer', but leaving FRAME_POINTER disabled. This makes it hard to reason about the FRAME_POINTER config, and also triggers build failures introduced in by the commit in the Fixes: tag. Select FRAME_POINTER explicitly for these configurations. Fixes: ebc9cb03b21e ("riscv: stack: Fixup independent softirq stack for CONFIG_FRAME_POINTER=n") Signed-off-by: Björn Töpel <bjorn@rivosinc.com> Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230823082845.354839-1-bjorn@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16docs: kdump: Update the crashkernel description for riscvChen Jiahao1-7/+8
Now "crashkernel=" parameter on riscv has been updated to support crashkernel=X,[high,low]. Through which we can reserve memory region above/within 32bit addressible DMA zone. Here update the parameter description accordingly. Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com> Reviewed-by: Guo Ren <guoren@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com> Acked-by: Baoquan He <bhe@redhat.com> Link: https://lore.kernel.org/r/20230726175000.2536220-3-chenjiahao16@huawei.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16riscv: kdump: Implement crashkernel=X,[high,low]Chen Jiahao2-7/+91
On riscv, the current crash kernel allocation logic is trying to allocate within 32bit addressible memory region by default, if failed, try to allocate without 4G restriction. In need of saving DMA zone memory while allocating a relatively large crash kernel region, allocating the reserved memory top down in high memory, without overlapping the DMA zone, is a mature solution. Here introduce the parameter option crashkernel=X,[high,low]. One can reserve the crash kernel from high memory above DMA zone range by explicitly passing "crashkernel=X,high"; or reserve a memory range below 4G with "crashkernel=X,low". Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com> Acked-by: Guo Ren <guoren@kernel.org> Acked-by: Baoquan He <bhe@redhat.com> Link: https://lore.kernel.org/r/20230726175000.2536220-2-chenjiahao16@huawei.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16riscv: kprobes: simulate c.beqz and c.bnezNam Cao3-2/+48
kprobes currently rejects instruction c.beqz and c.bnez. Implement them. Signed-off-by: Nam Cao <namcaov@gmail.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/1d879dba4e4ee9a82e27625d6483b5c9cfed684f.1690704360.git.namcaov@gmail.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16riscv: kprobes: simulate c.jr and c.jalr instructionsNam Cao3-2/+41
kprobes currently rejects c.jr and c.jalr instructions. Implement them. Signed-off-by: Nam Cao <namcaov@gmail.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/db8b7787e9208654cca50484f68334f412be2ea9.1690704360.git.namcaov@gmail.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16riscv: kprobes: simulate c.j instructionNam Cao3-1/+27
kprobes currently rejects c.j instruction. Implement it. Signed-off-by: Nam Cao <namcaov@gmail.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/6ef76cd9984b8015826649d13f870f8ac45a2d0d.1690704360.git.namcaov@gmail.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16perf: tests: Adapt mmap-basic.c for riscvAlexandre Ghiti1-2/+4
riscv now supports mmaping hardware counters to userspace so adapt the test to run on this architecture. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Ian Rogers <irogers@google.com>
2023-08-16tools: lib: perf: Implement riscv mmap supportAlexandre Ghiti1-0/+66
riscv now supports mmaping hardware counters so add what's needed to take advantage of that in libperf. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Ian Rogers <irogers@google.com>
2023-08-16Documentation: admin-guide: Add riscv sysctl_perf_user_accessAlexandre Ghiti1-4/+23
riscv now uses this sysctl so document its usage for this architecture. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
2023-08-16drivers: perf: Implement perf event mmap support in the SBI backendAlexandre Ghiti2-7/+195
We used to unconditionnally expose the cycle and instret csrs to userspace, which gives rise to security concerns. So now we only allow access to hw counters from userspace through the perf framework which will handle context switches, per-task events...etc. A sysctl allows to revert the behaviour to the legacy mode so that userspace applications which are not ready for this change do not break. But the default value is to allow userspace only through perf: this will break userspace applications which rely on direct access to rdcycle. This choice was made for security reasons [1][2]: most of the applications which use rdcycle can instead use rdtime to count the elapsed time. [1] https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/REWcwYnzsKE?pli=1 [2] https://www.youtube.com/watch?v=3-c4C_L2PRQ&ab_channel=IEEESymposiumonSecurityandPrivacy Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
2023-08-16drivers: perf: Implement perf event mmap support in the legacy backendAlexandre Ghiti1-0/+26
Implement the needed callbacks in the legacy driver so that we can directly access the counters through perf in userspace. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com>
2023-08-16riscv: Prepare for user-space perf event mmap supportAlexandre Ghiti2-0/+109
Provide all the necessary bits in the generic riscv pmu driver to be able to mmap perf events in userspace: the heavy lifting lies in the driver backend, namely the legacy and sbi implementations. Note that arch_perf_update_userpage is almost a copy of arm64 code. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com>
2023-08-16drivers: perf: Rename riscv pmu sbi driverAlexandre Ghiti2-3/+3
That's just cosmetic, no functional changes. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com>
2023-08-16riscv: Make legacy counter enum match the HW numberingAlexandre Ghiti1-1/+1
RISCV_PMU_LEGACY_INSTRET used to be set to 1 whereas the offset of this hardware counter from CSR_CYCLE is actually 2: make this offset match the real hw offset so that we can directly expose those values to userspace. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com>
2023-08-16include: riscv: Fix wrong include guard in riscv_pmu.hAlexandre Ghiti1-3/+3
The current include guard prevents the inclusion of asm/perf_event.h which uses the same include guard: fix the one in riscv_pmu.h so that it matches the file name. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com>
2023-08-16perf: Fix wrong comment about default event_idxAlexandre Ghiti1-1/+2
Since commit c719f56092ad ("perf: Fix and clean up initialization of pmu::event_idx"), event_idx default implementation has returned 0, not idx + 1, so fix the comment that can be misleading. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com>
2023-08-02riscv: alternatives: fix a typo in commentYuan Tan1-1/+1
In the usage of ALTERNATIVE, "always" is misspelled as "alwyas". Signed-off-by: Yuan Tan <tanyuan@tinylab.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230723165155.4896-1-tanyuan@tinylab.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-02RISC-V: cpu: refactor deprecated strncpyJustin Stitt1-6/+6
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. Favor not copying strings onto stack and instead use strings directly. This avoids hard-coding sizes and buffer lengths all together. Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Suggested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230802-arch-riscv-kernel-v2-1-24266e85bc96@google.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-25RISC-V: provide Kconfig & commandline options to control parsing "riscv,isa"Conor Dooley5-2/+46
As it says on the tin, provide Kconfig option to control parsing the "riscv,isa" devicetree property. If either option is used, the kernel will fall back to parsing "riscv,isa", where "riscv,isa-base" and "riscv,isa-extensions" are not present. The Kconfig options are set up so that the default kernel configuration will enable the fallback path, without needing the commandline option. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Suggested-by: Palmer Dabbelt <palmer@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230713-aviator-plausibly-a35662485c2c@wendy Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-25RISC-V: try new extension properties in of_early_processor_hartid()Conor Dooley1-1/+28
To fully deprecate the kernel's use of "riscv,isa", of_early_processor_hartid() needs to first try using the new properties, before falling back to "riscv,isa". Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230713-tablet-jimmy-987fea0eb2e1@wendy Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-25RISC-V: enable extension detection from dedicated propertiesConor Dooley2-4/+75
Add support for parsing the new riscv,isa-extensions property in riscv_fill_hwcap(), by means of a new "property" member of the riscv_isa_ext_data struct. For now, this shadows the name of the extension for all users, however this may not be the case for all extensions, based on how the dt-binding is written. For the sake of backwards compatibility, fall back to the old scheme if the new properties are not detected. For now, just inform, rather than warn, when that happens. Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230713-vocation-profane-39a74b3c2649@wendy Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-25RISC-V: split riscv_fill_hwcap() in 3Conor Dooley1-168/+177
Before adding more complexity to it, split riscv_fill_hwcap() into 3 distinct sections: - riscv_fill_hwcap() still is the top level function, into which the additional complexity will be added. - riscv_fill_hwcap_from_isa_string() handles getting the information from the riscv,isa/ACPI equivalent across harts & the various quirks there - riscv_parse_isa_string() does what it says on the tin. Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230713-daylight-puritan-37aeb41a4d9b@wendy Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-25RISC-V: add single letter extensions to riscv_isa_extConor Dooley2-26/+24
So that riscv_fill_hwcap() can use riscv_isa_ext to probe for single letter extensions, add them to it. As a result, what gets spat out in /proc/cpuinfo will become borked, as single letter extensions will be printed as part of the base extensions and while printing from riscv_isa_arr. Take the opportunity to unify the printing of the isa string, using the new member of riscv_isa_ext_data in the process. Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230713-despite-bright-de00ac888cc7@wendy Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-25RISC-V: add missing single letter extension definitionsConor Dooley1-0/+5
To facilitate adding single letter extensions to riscv_isa_ext, add definitions for the extensions present in base_riscv_exts that do not already have them. Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Evan Green <evan@rivosinc.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230713-train-feisty-93de38250f98@wendy Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-25RISC-V: repurpose riscv_isa_ext array in riscv_fill_hwcap()Conor Dooley3-28/+14
In riscv_fill_hwcap() riscv_isa_ext array can be looped over, rather than duplicating the list of extensions with individual SET_ISA_EXT_MAP() usage. While at it, drop the statement-of-the-obvious comments from the struct, rename uprop to something more suitable for its new use & constify the members. Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230713-dastardly-affiliate-4cf819dccde2@wendy Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-25RISC-V: shunt isa_ext_arr to cpufeature.cConor Dooley3-73/+72
To facilitate using one struct to define extensions, rather than having several, shunt isa_ext_arr to cpufeature.c, where it will be used for probing extension presence also. As that scope of the array as widened, prefix it with riscv & drop the type from the variable name. Since the new array is const, print_isa() needs a wee bit of cleanup to avoid complaints about losing the const qualifier. Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Evan Green <evan@rivosinc.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230713-spirits-upside-a2c61c65fd5a@wendy Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-25RISC-V: drop a needless check in print_isa_ext()Conor Dooley1-4/+0
isa_ext_arr cannot be empty, as some of the extensions within it are always built into the kernel. When this code was first added, back in commit a9b202606c69 ("RISC-V: Improve /proc/cpuinfo output for ISA extensions"), the array was empty and needed a dummy item & thus there could be no extensions present. When the first multi-letter ones did get added, it was Sscofpmf - which didn't have a Kconfig symbol to disable it. Remove this check, as it has been redundant since Sscofpmf was added. Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230713-veggie-mug-3d3bf6787ae2@wendy Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-25RISC-V: don't parse dt/acpi isa string to get rv32/rv64Heiko Stuebner1-12/+9
When filling hwcap the kernel already expects the isa string to start with rv32 if CONFIG_32BIT and rv64 if CONFIG_64BIT. So when recreating the runtime isa-string we can also just go the other way to get the correct starting point for it. Signed-off-by: Heiko Stuebner <heiko.stuebner@vrull.eu> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Evan Green <evan@rivosinc.com> Co-developed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230713-masculine-saddlebag-67a94966b091@wendy Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-25RISC-V: Provide a more helpful error message on invalid ISA stringsPalmer Dabbelt1-2/+6
Right now we provide a somewhat unhelpful error message on systems with invalid error messages, something along the lines of CPU with hartid=0 is not available ------------[ cut here ]------------ kernel BUG at arch/riscv/kernel/smpboot.c:174! Kernel BUG [#1] Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 6.4.0-rc1-00096-ge0097d2c62d5-dirty #1 Hardware name: Microchip PolarFire-SoC Icicle Kit (DT) epc : of_parse_and_init_cpus+0x16c/0x16e ra : of_parse_and_init_cpus+0x9a/0x16e epc : ffffffff80c04e0a ra : ffffffff80c04d38 sp : ffffffff81603e20 gp : ffffffff8182d658 tp : ffffffff81613f80 t0 : 000000000000006e t1 : 0000000000000064 t2 : 0000000000000000 s0 : ffffffff81603e80 s1 : 0000000000000000 a0 : 0000000000000000 a1 : 0000000000000000 a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 a5 : 0000000000001fff a6 : 0000000000001fff a7 : ffffffff816148b0 s2 : 0000000000000001 s3 : ffffffff81492a4c s4 : ffffffff81a4b090 s5 : ffffffff81506030 s6 : 0000000000000040 s7 : 0000000000000000 s8 : 00000000bfb6f046 s9 : 0000000000000001 s10: 0000000000000000 s11: 00000000bf389700 t3 : 0000000000000000 t4 : 0000000000000000 t5 : ffffffff824dd188 t6 : ffffffff824dd187 status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [<ffffffff80c04e0a>] of_parse_and_init_cpus+0x16c/0x16e [<ffffffff80c04c96>] setup_smp+0x1e/0x26 [<ffffffff80c03ffe>] setup_arch+0x6e/0xb2 [<ffffffff80c00384>] start_kernel+0x72/0x400 Code: 80e7 4a00 a603 0009 b795 1097 ffe5 80e7 92c0 9002 (9002) 715d ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt Add a warning for the cases where the ISA string isn't valid. It's still above the BUG_ON cut, but hopefully it's at least a bit easier for users. Reviewed-by: Evan Green <evan@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230713-endless-spearhead-62a5a4b149bd@wendy Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-11riscv: sigcontext: Correct the comment of sigreturnGuo Ren1-1/+1
The real-time signals enlarged the sigset_t type, and most architectures have changed to using rt_sigreturn as the only way. The riscv is one of them, and there is no sys_sigreturn in it. Only some old architecture preserved sys_sigreturn as part of the historical burden. Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Signed-off-by: Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/r/20230628091213.2908149-1-guoren@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.