- 22 Feb, 2023 20 commits
-
-
Guo Ren authored
Add HVO support for RISC-V; see commit 6be24bed ("mm: hugetlb: introduce a new config HUGETLB_PAGE_FREE_VMEMMAP"). This patch is similar to commit 1e63ac08 ("arm64: mm: hugetlb: enable HUGETLB_PAGE_FREE_VMEMMAP for arm64"), and riscv's motivation is the same as arm64. The current riscv was ready to enable HVO after fixup, ref commit d33deda0 ("riscv/mm: hugepage's PG_dcache_clean flag is only set in head page"). See Documentation/mm/vmemmap_dedup.rst for more details. The HugeTLB VmemmapvOptimization (HVO) defaults to off in Kconfig. Here is the riscv test log: cat /proc/sys/vm/hugetlb_optimize_vmemmap echo 8 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages mount -t hugetlbfs none test/ -o pagesize=2048k <Try some simple hugetlb test in test dir, no problem found.> Signed-off-by:
Guo Ren <guoren@linux.alibaba.com> Signed-off-by:
Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/linux-riscv/1F5AF29D-708A-483B-A29F-CAEE6F554866@linux.dev/Acked-by:
Muchun Song <songmuchun@bytedance.com> Reviewed-by:
Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20230201015259.3222524-1-guoren@kernel.orgSigned-off-by:
Palmer Dabbelt <palmer@rivosinc.com>
-
Liao Chang authored
Add header include guards to insn.h to prevent repeating declaration of any identifiers in insn.h. Fixes: edde5584 ("riscv: Add SW single-step support for KDB") Signed-off-by:
Liao Chang <liaochang1@huawei.com> Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230129094242.282620-1-liaochang1@huawei.com Cc: stable@vger.kernel.org Signed-off-by:
-
Palmer Dabbelt authored
Björn Töpel <bjorn@kernel.org> says: From: Björn Töpel <bjorn@rivosinc.com> RISC-V does not dump faulting instructions in the oops handler. This series adds "Code:" dumps to the oops output together with scripts/decodecode support. * b4-shazam-merge: scripts/decodecode: Add support for RISC-V riscv: Add instruction dump to RISC-V splats Link: https://lore.kernel.org/r/20230119074738.708301-1-bjorn@kernel.orgSigned-off-by:
-
Jisheng Zhang authored
If we patched auipc + jalr pair, we'd better proceed one more instruction. Andrew pointed out "There's not a problem now, since we're only adding a fixup for jal, not jalr, but we should future-proof this and there's no reason to revisit an already fixed-up instruction anyway." Signed-off-by:
Jisheng Zhang <jszhang@kernel.org> Suggested-by:
Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20230115162811.3146-1-jszhang@kernel.orgSigned-off-by:
-
Palmer Dabbelt authored
Jisheng Zhang <jszhang@kernel.org> says: This series tries to improve link time handling of riscv: patch1 adds the missing RUNTIME_DISCARD_EXIT as suggested by Masahiro. Similar as other architectures such as x86, arm64 and so on, enable ARCH_WANT_LD_ORPHAN_WARN to enable linker orphan warnings to prevent from missing any new sections in future. So the following two patches are preparation ones, and the last patch finally selects ARCH_WANT_LD_ORPHAN_WARN * b4-shazam-merge: riscv: select ARCH_WANT_LD_ORPHAN_WARN for !XIP_KERNEL riscv: vmlinux.lds.S: explicitly catch .init.bss sections from EFI stub riscv: vmlinux.lds.S: explicitly catch .riscv.attributes sections riscv: vmlinux.lds.S: explicitly catch .rela.dyn symbols riscv: lds: define RUNTIME_DISCARD_EXIT Link: https://lore.kernel.org/r/20230119155417.2600-1-jszhang@kernel.orgSigned-off-by:
-
Mattias Nissler authored
While working on something else, I noticed that the kernel would start accepting interrupts again after crashing in an interrupt handler. Since the kernel is already in inconsistent state, enabling interrupts is dangerous and opens up risk of kernel state deteriorating further. Interrupts do get enabled via what looks like an unintended side effect of spin_unlock_irq, so switch to the more cautious spin_lock_irqsave/spin_unlock_irqrestore instead. Fixes: 76d2a049 ("RISC-V: Init and Halt Code") Signed-off-by:
Mattias Nissler <mnissler@rivosinc.com> Reviewed-by:
Björn Töpel <bjorn@kernel.org> Link: https://lore.kernel.org/r/20230215144828.3370316-1-mnissler@rivosinc.com Cc: stable@vger.kernel.org Signed-off-by:
-
Björn Töpel authored
Commit 21855cac ("riscv/mm: Prevent kernel module to access user memory without uaccess routines") added early exits/deaths for page faults stemming from accesses to user-space without using proper uaccess routines (where sstatus.SUM is set). Unfortunatly, this is too strict for some BPF programs, which relies on BPF exhandler fixups. These BPF programs loads "BTF pointers". A BTF pointers could either be a valid kernel pointer or NULL, but not a userspace address. Resolve the problem by calling the fixup handler in the early exit path. Fixes: 21855cac ("riscv/mm: Prevent kernel module to access user memory without uaccess routines") Signed-off-by:
Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20230214162515.184827-1-bjorn@kernel.org Cc: stable@vger.kernel.org Signed-off-by:
-
Conor Dooley authored
Guenter reported a splat during boot, that Samuel pointed out was the lockdep assertion failing in patch_insn_write(): WARNING: CPU: 0 PID: 0 at arch/riscv/kernel/patch.c:63 patch_insn_write+0x222/0x2f6 epc : patch_insn_write+0x222/0x2f6 ra : patch_insn_write+0x21e/0x2f6 epc : ffffffff800068c6 ra : ffffffff800068c2 sp : ffffffff81803df0 gp : ffffffff81a1ab78 tp : ffffffff81814f80 t0 : ffffffffffffe000 t1 : 0000000000000001 t2 : 4c45203a76637369 s0 : ffffffff81803e40 s1 : 0000000000000004 a0 : 0000000000000000 a1 : ffffffffffffffff a2 : 0000000000000004 a3 : 0000000000000000 a4 : 0000000000000001 a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000052464e43 s2 : ffffffff80b4889c s3 : 000000000000082c s4 : ffffffff80b48828 s5 : 0000000000000828 s6 : ffffffff8131a0a0 s7 : 0000000000000fff s8 : 0000000008000200 s9 : ffffffff8131a520 s10: 0000000000000018 s11: 000000000000000b t3 : 0000000000000001 t4 : 000000000000000d t5 : ffffffffd8180000 t6 : ffffffff81803bc8 status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [<ffffffff800068c6>] patch_insn_write+0x222/0x2f6 [<ffffffff80006a36>] patch_text_nosync+0xc/0x2a [<ffffffff80003b86>] riscv_cpufeature_patch_func+0x52/0x98 [<ffffffff80003348>] _apply_alternatives+0x46/0x86 [<ffffffff80c02d36>] apply_boot_alternatives+0x3c/0xfa [<ffffffff80c03ad8>] setup_arch+0x584/0x5b8 [<ffffffff80c0075a>] start_kernel+0xa2/0x8f8 This issue was exposed by 702e6455 ("riscv: fpu: switch has_fpu() to riscv_has_extension_likely()"), as it is the patching in has_fpu() that triggers the splats in Guenter's report. Take the text_mutex before doing any code patching to satisfy lockdep. Fixes: ff689fd2 ("riscv: add RISC-V Svpbmt extension support") Fixes: a35707c3 ("riscv: add memory-type errata for T-Head") Fixes: 1a0e5dbd ("riscv: sifive: Add SiFive alternative ports") Reported-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/all/20230212154333.GA3760469@roeck-us.net/Signed-off-by:
Samuel Holland <samuel@sholland.org> Tested-by:
-
Andrew Jones authored
While the comment above the ISA extension ID definitions says "Entries are sorted alphabetically.", this stopped being good advice with commit d8a3d8a7 ("riscv: hwcap: make ISA extension ids can be used in asm"), as we now use macros instead of enums. Reshuffling defines is error-prone, so, since they don't need to be in any particular order, change the advice to just adding new extensions at the bottom. Also, take the opportunity to change spaces to tabs, merge three comments into one, and move the base and max defines into more logical locations wrt the ID definitions. Signed-off-by:
-
Heiko Stuebner authored
As Andrew reported, Zb* comes after Zi* according 27.11 "Subset Naming Convention" so fix the ordering accordingly. Reported-by:Heiko Stuebner <heiko.stuebner@vrull.eu> Reviewed-by:
-
Andy Chiu authored
Runtime code patching must be done at a naturally aligned address, or we may execute on a partial instruction. We have encountered problems traced back to static jump functions during the test. We switched the tracer randomly for every 1~5 seconds on a dual-core QEMU setup and found the kernel sucking at a static branch where it jumps to itself. The reason is that the static branch was 2-byte but not 4-byte aligned. Then, the kernel would patch the instruction, either J or NOP, with two half-word stores if the machine does not have efficient unaligned accesses. Thus, moments exist where half of the NOP mixes with the other half of the J when transitioning the branch. In our particular case, on a little-endian machine, the upper half of the NOP was mixed with the lower part of the J when enabling the branch, resulting in a jump that jumped to itself. Conversely, it would result in a HINT instruction when disabling the branch, but it might not be observable. ARM64 does not have this problem since all instructions must be 4-byte aligned. Fixes: ebc00dde ("riscv: Add jump-label implementation") Link: https://lore.kernel.org/linux-riscv/20220913094252.3555240-6-andy.chiu@sifive.com/Reviewed-by:
Greentime Hu <greentime.hu@sifive.com> Signed-off-by:
Andy Chiu <andy.chiu@sifive.com> Signed-off-by:
-
Palmer Dabbelt authored
The recent refactoring led to us leaking some HWCAP bits to userspace that didn't make much sense. With any luck we'll have a better scheme soon, but for now just mask off those bits to avoid polluting userspace. Acked-by:
-
Sergey Matyukevich authored
This is a partial revert of the commit 4bd1d80e ("riscv: mm: notify remote harts about mmu cache updates"). Original commit included two loosely related changes serving the same purpose of fixing stale TLB entries causing user-space application crash: - introduce deferred per-ASID TLB flush for CPUs not running the task - switch to per-ASID TLB flush on all CPUs running the task in update_mmu_cache According to report and discussion in [1], the second part caused a regression on Renesas RZ/Five SoC. For now restore the old behavior of the update_mmu_cache. [1] https://lore.kernel.org/linux-riscv/20220829205219.283543-1-geomatsi@gmail.com/ Fixes: 4bd1d80e ("riscv: mm: notify remote harts about mmu cache updates") Reported-by:
"Lad, Prabhakar" <prabhakar.csengg@gmail.com> Signed-off-by:
Sergey Matyukevich <sergey.matyukevich@syntacore.com> Link: trailer, so that it can be parsed with git's trailer functionality? Reviewed-by:
-
Björn Töpel authored
RISC-V has some GNU disassembly quirks, e.g. it requires '-D' to properly disassemble .2byte directives similar to Arm [1]. Further, GNU objdump groups RISC-V instruction by 2 or 4 byte chunks, instead doing byte-for-byte. Add the required switches, and translate from short/word to bytes when ARCH is "riscv". An example how to invoke decodecode for RISC-V: $ echo 'Code: bf45 f793 1007 f7d9 50ef 37af d541 b7d9 7097 00c8 (80e7) 6140' | AFLAGS="-march=rv64imac_zicbom_zihintpause" \ ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- ./scripts/decodecode Code: bf45 f793 1007 f7d9 50ef 37af d541 b7d9 7097 00c8 (80e7) 6140 All code ======== 0: bf45 c.j 0xffffffffffffffb0 2: 1007f793 andi a5,a5,256 6: f7d9 c.bnez a5,0xffffffffffffff94 8: 37af50ef jal ra,0xf5382 c: d541 c.beqz a0,0xffffffffffffff94 e: b7d9 c.j 0xffffffffffffffd4 10: 00c87097 auipc ra,0xc87 14:* 614080e7 jalr ra,1556(ra) # 0xc87624 <-- trapping instruction Code starting with the faulting instruction =========================================== 0: 614080e7 jalr ra,1556(ra) [1] https://sourceware.org/bugzilla/show_bug.cgi?id=10263Signed-off-by:Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230119074738.708301-3-bjorn@kernel.orgSigned-off-by:
-
Björn Töpel authored
Add instruction dump (Code:) output to RISC-V splats. Dump 16b parcels. An example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Oops [#1] Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc3-00302-g840ff44c571d-dirty #27 Hardware name: riscv-virtio,qemu (DT) epc : kernel_init+0xc8/0x10e ra : kernel_init+0x70/0x10e epc : ffffffff80bd9a40 ra : ffffffff80bd99e8 sp : ff2000000060bec0 gp : ffffffff81730b28 tp : ff6000007ff00000 t0 : 7974697275636573 t1 : 0000000000000000 t2 : 3030303270393d6e s0 : ff2000000060bee0 s1 : ffffffff81732028 a0 : 0000000000000000 a1 : ff60000080dd1780 a2 : 0000000000000002 a3 : ffffffff8176a470 a4 : 0000000000000000 a5 : 000000000000000a a6 : 0000000000000081 a7 : ff60000080dd1780 s2 : 0000000000000000 s3 : 0000000000000000 s4 : 0000000000000000 s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000 s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000 s11: 0000000000000000 t3 : ffffffff81186018 t4 : 0000000000000022 t5 : 000000000000003d t6 : 0000000000000000 status: 0000000200000120 badaddr: 0000000000000000 cause: 000000000000000f [<ffffffff80003528>] ret_from_exception+0x0/0x16 Code: 862a d179 608c a517 0069 0513 2be5 d0ef db2e 47a9 (c11c) a517 ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b SMP: stopping secondary CPUs ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- Signed-off-by:
-
Jisheng Zhang authored
Now, after that all the sections are explicitly described and declared in vmlinux.lds.S, we can enable ld orphan warnings for !XIP_KERNEL to prevent from missing any new sections in future. Signed-off-by:
-
Jisheng Zhang authored
When enabling linker orphan section warning, I got warnings similar as below: ld.lld: warning: ./drivers/firmware/efi/libstub/lib.a(efi-stub-helper.stub.o):(.init.bss) is being placed in '.init.bss' Catch the sections so that we can enable linker orphan section warning. Signed-off-by:
-
Jisheng Zhang authored
When enabling linker orphan section warning, I got warnings similar as below: riscv64-linux-gnu-ld: warning: orphan section `.riscv.attributes' from `init/main.o' being placed in section `.riscv.attributes' While I don't see any usage of .riscv.attributes sections' in kernel now, just catch the sections so that we can enable linker orphan section warning. Signed-off-by:
-
Jisheng Zhang authored
When enabling linker orphan section warning, I got warnings similar as below: riscv64-linux-gnu-ld: warning: orphan section `.rela.text' from `init/main.o' being placed in section `.rela.dyn' Use the approach similar as ARM64 does and declare it in vmlinux.lds.S Signed-off-by:
-
Jisheng Zhang authored
riscv discards .exit.* sections at run-time but doesn't define RUNTIME_DISCARD_EXIT. However, the .exit.* sections are still allocated and kept even if the generic DISCARDS would discard the sections due to missing RUNTIME_DISCARD_EXIT, because the DISCARD sits at the end of the linker script. Add the missing RUNTIME_DISCARD_EXIT define so that it still works if we move DISCARD up or even at the beginning of the linker script. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
-
- 16 Feb, 2023 1 commit
-
-
Heiko Stuebner authored
The __RISCV_INSN_FUNCS originally declared riscv_insn_is_* functions inside the kprobes implementation. This got moved into a central header in commit ec5f9087 ("RISC-V: Move riscv_insn_is_* macros into a common header"). Though it looks like I overlooked two of them, so fix that. FENCE itself is an instruction defined directly by its own opcode, while the created riscv_isn_is_system function covers all instructions defined under the SYSTEM opcode. Reviewed-by:
-
- 15 Feb, 2023 15 commits
-
-
Palmer Dabbelt authored
guoren@kernel.org <guoren@kernel.org> says: From: Guo Ren <guoren@linux.alibaba.com> The previous ftrace detour implementation fc76b8b8011 ("riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT") contain three problems. - The most horrible bug is preemption panic which found by Andy [1]. Let's disable preemption for ftrace first, and Andy could continue the ftrace preemption work. - The "-fpatchable-function-entry= CFLAG" wasted code size !RISCV_ISA_C. - The ftrace detour implementation wasted code size. - When livepatching, the trampoline (ftrace_regs_caller) would not return to <func_prolog+12> but would rather jump to the new function. So, "REG_L ra, -SZREG(sp)" would not run and the original return address would not be restored. The kernel is likely to hang or crash as a result. (Found by Evgenii Shatokhin [4]) [Palmer: The first three patches in this series are pretty concrete fixes, so I'm pulling them ahead of the rest of the series.] * b4-shazam-merge: riscv: ftrace: Reduce the detour code size to half riscv: ftrace: Remove wasted nops for !RISCV_ISA_C riscv: ftrace: Fixup panic by disabling preemption Link: https://lore.kernel.org/r/20230112090603.1295340-1-guoren@kernel.orgSigned-off-by: -
Guo Ren authored
Use a temporary register to reduce the size of detour code from 16 bytes to 8 bytes. The previous implementation is from 'commit afc76b8b ("riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT")'. Before the patch: <func_prolog>: 0: REG_S ra, -SZREG(sp) 4: auipc ra, ? 8: jalr ?(ra) 12: REG_L ra, -SZREG(sp) (func_boddy) After the patch: <func_prolog>: 0: auipc t0, ? 4: jalr t0, ?(t0) (func_boddy) This patch not just reduces the size of detour code, but also fixes an important issue: An Ftrace callback registered with FTRACE_OPS_FL_IPMODIFY flag can actually change the instruction pointer, e.g. to "replace" the given kernel function with a new one, which is needed for livepatching, etc. In this case, the trampoline (ftrace_regs_caller) would not return to <func_prolog+12> but would rather jump to the new function. So, "REG_L ra, -SZREG(sp)" would not run and the original return address would not be restored. The kernel is likely to hang or crash as a result. This can be easily demonstrated if one tries to "replace", say, cmdline_proc_show() with a new function with the same signature using instruction_pointer_set(&fregs->regs, new_func_addr) in the Ftrace callback. Link: https://lore.kernel.org/linux-riscv/20221122075440.1165172-1-suagrfillet@gmail.com/ Link: https://lore.kernel.org/linux-riscv/d7d5730b-ebef-68e5-5046-e763e1ee6164@yadro.com/Co-developed-by:
Song Shuai <suagrfillet@gmail.com> Signed-off-by:
Evgenii Shatokhin <e.shatokhin@yadro.com> Link: https://lore.kernel.org/r/20230112090603.1295340-4-guoren@kernel.org Cc: stable@vger.kernel.org Fixes: 10626c32 ("riscv/ftrace: Add basic support") Signed-off-by:
-
Guo Ren authored
When CONFIG_RISCV_ISA_C=n, -fpatchable-function-entry=8 would generate more nops than we expect. Because it treat nop opcode as 0x00000013 instead of 0x0001. Dump of assembler code for function dw_pcie_free_msi: 0xffffffff806fce94 <+0>: sd ra,-8(sp) 0xffffffff806fce98 <+4>: auipc ra,0xff90f 0xffffffff806fce9c <+8>: jalr -684(ra) # 0xffffffff8000bbec <ftrace_caller> 0xffffffff806fcea0 <+12>: ld ra,-8(sp) 0xffffffff806fcea4 <+16>: nop /* wasted */ 0xffffffff806fcea8 <+20>: nop /* wasted */ 0xffffffff806fceac <+24>: nop /* wasted */ 0xffffffff806fceb0 <+28>: nop /* wasted */ 0xffffffff806fceb4 <+0>: addi sp,sp,-48 0xffffffff806fceb8 <+4>: sd s0,32(sp) 0xffffffff806fcebc <+8>: sd s1,24(sp) 0xffffffff806fcec0 <+12>: sd s2,16(sp) 0xffffffff806fcec4 <+16>: sd s3,8(sp) 0xffffffff806fcec8 <+20>: sd ra,40(sp) 0xffffffff806fcecc <+24>: addi s0,sp,48 Signed-off-by:
-
Andy Chiu authored
In RISCV, we must use an AUIPC + JALR pair to encode an immediate, forming a jump that jumps to an address over 4K. This may cause errors if we want to enable kernel preemption and remove dependency from patching code with stop_machine(). For example, if a task was switched out on auipc. And, if we changed the ftrace function before it was switched back, then it would jump to an address that has updated 11:0 bits mixing with previous XLEN:12 part. p: patched area performed by dynamic ftrace ftrace_prologue: p| REG_S ra, -SZREG(sp) p| auipc ra, 0x? ------------> preempted ... change ftrace function ... p| jalr -?(ra) <------------- switched back p| REG_L ra, -SZREG(sp) func: xxx ret Fixes: afc76b8b ("riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT") Signed-off-by:
-
Palmer Dabbelt authored
Conor Dooley <conor@kernel.org> says: From: Conor Dooley <conor.dooley@microchip.com> I've yoinked patch 1 from Drew's series adding support for Zicboz & attached two more patches here that remove the need for, and then drop the toolchain support checks for Zicbom. The goal is to remove the need for checking the presence of toolchain Zicbom support in the work being done to support non instruction based CMOs [1]. I've tested compliation on a number of different configurations with the Zicbom config option enabled. The important ones to call out I guess are: - clang/llvm 14 w/ LLVM=1 which doesn't support Zicbom atm. - gcc 11 w/ binutils 2.37 which doesn't support Zicbom atm either. - clang/llvm 15 w/ LLVM=1 BUT with binutils 2.37's ld. This is the configuration that prompted adding the LD checks as cc/as supports Zicbom, but ld doesn't [2]. - gcc 12 w/ binutils 2.39 & clang 15 w/ LLVM=1, both of these supported Zicbom before and still do. I also checked building the THEAD errata etc with CONFIG_RISCV_ISA_ZICBOM disabled, and there were no build issues there either. * b4-shazam-merge: RISC-V: remove toolchain version checks for Zicbom RISC-V: replace cbom instructions with an insn-def RISC-V: insn-def: Add I-type insn-def Link: https://lore.kernel.org/r/20230108163356.3063839-1-conor@kernel.orgSigned-off-by:
-
Conor Dooley authored
Commit b8c86872 ("riscv: fix detection of toolchain Zicbom support") fixed building on systems where Zicbom was supported by the compiler/assembler but not by the linker in an easily backportable manner. Now that the we have insn-defs for the 3 instructions, toolchain support is no longer required for Zicbom. Stop emitting "_zicbom" in -march when Zicbom is enabled & drop the version checks entirely. Signed-off-by:
-
Conor Dooley authored
Using the cbom instructions directly in ALT_CMO_OP, requires toolchain support for the instructions. Using an insn-def will allow for removal of toolchain version checks in the build system & simplification of the proposed [1] function-based CMO scheme. Link: https://lore.kernel.org/linux-riscv/fb3b34ae-e35e-4dc2-a8f4-19984a2f58a8@app.fastmail.com/ [1] Signed-off-by:
-
Andrew Jones authored
CBO instructions use the I-type of instruction format where the immediate is used to identify the CBO instruction type. Add I-type instruction encoding support to insn-def. Signed-off-by:
-
Palmer Dabbelt authored
Conor Dooley <conor@kernel.org> says: From: Conor Dooley <conor.dooley@microchip.com> Ever since RISC-V starting using generic arch topology code, the code paths for cpu-capacity have been there but there's no binding defined to actually convey the information. Defining the same property as used on arm seems to be the only logical thing to do, so do it. [Palmer: This is on top of the fix required to make it work, which itself wasn't merged until late in the 6.2 cycle and thus pulls in various other fixes.] * b4-shazam-merge: dt-bindings: riscv: add a capacity-dmips-mhz cpu property dt-bindings: arm: move cpu-capacity to a shared loation riscv: Move call to init_cpu_topology() to later initialization stage riscv/kprobe: Fix instruction simulation of JALR riscv: fix -Wundef warning for CONFIG_RISCV_BOOT_SPINWAIT MAINTAINERS: add an IRC entry for RISC-V RISC-V: fix compile error from deduplicated __ALTERNATIVE_CFG_2 dt-bindings: riscv: fix single letter canonical order dt-bindings: riscv: fix underscore requirement for multi-letter extensions riscv: uaccess: fix type of 0 variable on error in get_user() riscv, kprobes: Stricter c.jr/c.jalr decoding Link: https://lore.kernel.org/r/20230104180513.1379453-1-conor@kernel.orgSigned-off-by:
-
Conor Dooley authored
Since commit 03f11f03 ("RISC-V: Parse cpu topology during boot.") RISC-V has used the generic arch topology code, which provides for disparate CPU capacities. We never defined a binding to acquire this information from the DT though, so document the one already used by the generic arch topology code: "capacity-dmips-mhz". Signed-off-by:
Ley Foon Tan <leyfoon.tan@starfivetech.com> Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230104180513.1379453-3-conor@kernel.orgSigned-off-by:
-
Conor Dooley authored
RISC-V uses the same generic topology code as arm64 & while there currently exists no binding for cpu-capacity on RISC-V, the code paths can be hit if the property is present. Move the documentation of cpu-capacity to a shared location, ahead of defining a binding for capacity-dmips-mhz on RISC-V. Update some references to this document in the process. Signed-off-by:
Yanteng Si <siyanteng@loongson.cn> Link: https://lore.kernel.org/r/20230104180513.1379453-2-conor@kernel.orgSigned-off-by:
-
Samuel Holland authored
Commit 4bf88607 ("riscv: cpufeature: extend riscv_cpufeature_patch_func to all ISA extensions") switched ISA extension alternatives to use the RISCV_ISA_EXT_* macros instead of CPUFEATURE_*. This was mismerged when applied on top of the Zbb series, so the Zbb alternatives referenced the wrong errata ID values. Fixes: 9daca9a5 ("Merge patch series "riscv: improve boot time isa extensions handling"") Signed-off-by:
-
Samuel Holland authored
Now that the text to patch is located using a relative offset from the alternative entry, the text address should be computed without applying the kernel mapping offset, both before and after VM setup. Fixes: 8d23e94a ("riscv: switch to relative alternative entries") Signed-off-by:
-
Conor Dooley authored
Selects should be sorted alphanumerically, and were tidied up originally by Palmer in commit e8c7ef7d ("RISC-V: Sort select statements alphanumerically") since then, things have gotten out of order again. Fish RMK's original script out of commit b1b3f49c ("ARM: config: sort select statements alphanumerically") and do some spring cleaning. Signed-off-by:
-
Conor Dooley authored
When adding the ISA string ordering rules, I didn't sufficiently indent one of the list items. Reported-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/linux-doc/202301300743.bp7Dpazv-lkp@intel.com/ Fixes: f07b2b3f ("Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo") Signed-off-by:
Bagas Sanjaya <bagasdotme@gmail.com> Link: https://lore.kernel.org/r/20230129235701.2393241-1-conor@kernel.orgSigned-off-by:
-
- 02 Feb, 2023 1 commit
-
-
Palmer Dabbelt authored
Jisheng Zhang <jszhang@kernel.org> says: Generally, riscv ISA extensions are fixed for any specific hardware platform, so a hart's features won't change after booting, this chacteristic makes it straightforward to use a static branch to check a specific ISA extension is supported or not to optimize performance. However, some ISA extensions such as SVPBMT and ZICBOM are handled via. the alternative sequences. Basically, for ease of maintenance, we prefer to use static branches in C code, but recently, Samuel found that the static branch usage in cpu_relax() breaks building with CONFIG_CC_OPTIMIZE_FOR_SIZE[1]. As Samuel pointed out, "Having a static branch in cpu_relax() is problematic because that function is widely inlined, including in some quite complex functions like in the VDSO. A quick measurement shows this static branch is responsible by itself for around 40% of the jump table." Samuel's findings pointed out one of a few downsides of static branches usage in C code to handle ISA extensions detected at boot time: static branch's metadata in the __jump_table section, which is not discarded after ISA extensions are finalized, wastes some space. I want to try to solve the issue for all possible dynamic handling of ISA extensions at boot time. Inspired by Mark[2], this patch introduces riscv_has_extension_*() helpers, which work like static branches but are patched using alternatives, thus the metadata can be freed after patching. [1]https://lore.kernel.org/linux-riscv/20220922060958.44203-1-samuel@sholland.org/ [2]https://lore.kernel.org/linux-arm-kernel/20220912162210.3626215-8-mark.rutland@arm.com/ [3]https://lore.kernel.org/linux-riscv/20221130225614.1594256-1-heiko@sntech.de/ * b4-shazam-merge: riscv: remove riscv_isa_ext_keys[] array and related usage riscv: KVM: Switch has_svinval() to riscv_has_extension_unlikely() riscv: cpu_relax: switch to riscv_has_extension_likely() riscv: alternative: patch alternatives in the vDSO riscv: switch to relative alternative entries riscv: module: Add ADD16 and SUB16 rela types riscv: module: move find_section to module.h riscv: fpu: switch has_fpu() to riscv_has_extension_likely() riscv: introduce riscv_has_extension_[un]likely() riscv: cpufeature: extend riscv_cpufeature_patch_func to all ISA extensions riscv: hwcap: make ISA extension ids can be used in asm riscv: cpufeature: detect RISCV_ALTERNATIVES_EARLY_BOOT earlier riscv: move riscv_noncoherent_supported() out of ZICBOM probe Link: https://lore.kernel.org/r/20230128172856.3814-1-jszhang@kernel.orgSigned-off-by:
-
- 01 Feb, 2023 3 commits
-
-
Jisheng Zhang authored
All users have switched to riscv_has_extension_*, remove unused definitions, vars and related setting code. Signed-off-by:
-
Andrew Jones authored
Switch has_svinval() from static branch to the new helper riscv_has_extension_unlikely(). Signed-off-by:
Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20230128172856.3814-13-jszhang@kernel.orgSigned-off-by:
-
Jisheng Zhang authored
Switch cpu_relax() from static branch to the new helper riscv_has_extension_likely() Signed-off-by:
-
