- 10 Jan, 2024 12 commits
-
-
Palmer Dabbelt authored
Frederik Haxel <haxel@fzi.de> says: XIP boot seems to be broken for some time now. A likely reason why no one seems to have noticed this is that XIP is more difficult to test, as it is currently not easily testable with QEMU. These patches fix the XIP boot and allow an XIP build without BUILTIN_DTB, which in turn makes it easier to test an image with the QEMU virt machine. * b4-shazam-merge: riscv: Allow disabling of BUILTIN_DTB for XIP riscv: Fixed wrong register in XIP_FIXUP_FLASH_OFFSET macro riscv: Make XIP bootable again Link: https://lore.kernel.org/r/20231212130116.848530-1-haxel@fzi.deSigned-off-by:
Palmer Dabbelt <palmer@rivosinc.com>
-
Song Shuai authored
The commit be97d0db ("riscv: VMAP_STACK overflow detection thread-safe") got rid of `shadow_stack`, so SHADOW_OVERFLOW_STACK_SIZE should be removed too. Fixes: be97d0db ("riscv: VMAP_STACK overflow detection thread-safe") Signed-off-by:
Song Shuai <songshuaishuai@tinylab.org> Reviewed-by:
Sami Tolvanen <samitolvanen@google.com> Link: https://lore.kernel.org/r/20231211110331.359534-1-songshuaishuai@tinylab.orgSigned-off-by:
-
Palmer Dabbelt authored
I don't usually merge these in, but I missed sending a PR due to the holidays. * palmer/fixes: riscv: Fix set_direct_map_default_noflush() to reset _PAGE_EXEC riscv: Fix module_alloc() that did not reset the linear mapping permissions riscv: Fix wrong usage of lm_alias() when splitting a huge linear mapping riscv: Check if the code to patch lies in the exit section riscv: errata: andes: Probe for IOCP only once in boot stage riscv: Fix SMP when shadow call stacks are enabled dt-bindings: perf: riscv,pmu: drop unneeded quotes riscv: fix misaligned access handling of C.SWSP and C.SDSP RISC-V: hwprobe: Always use u64 for extension bits Support rv32 ULEB128 test riscv: Correct type casting in module loading riscv: Safely remove entries from relocation list Signed-off-by: -
Ben Dooks authored
The save_v_state() is technically sending a __user pointer through __put_user() and thus is generating a sparse warning so force the value to be "void *" to fix: arch/riscv/kernel/signal.c:94:16: warning: incorrect type in initializer (different address spaces) arch/riscv/kernel/signal.c:94:16: expected void *__val arch/riscv/kernel/signal.c:94:16: got void [noderef] __user *[assigned] datap Fixes: 8ee0b418 ("riscv: signal: Add sigcontext save/restore for vector") Signed-off-by:
Ben Dooks <ben.dooks@codethink.co.uk> Link: https://lore.kernel.org/r/20231123142708.261733-1-ben.dooks@codethink.co.ukSigned-off-by:
-
Ben Dooks authored
The instruction reading code can read from either user or kernel addresses and thus the use of __user on pointers to instructions depends on which context. Fix a few sparse warnings by using __user for user-accesses and remove it when not. Fixes: arch/riscv/kernel/traps_misaligned.c:361:21: warning: dereference of noderef expression arch/riscv/kernel/traps_misaligned.c:373:21: warning: dereference of noderef expression arch/riscv/kernel/traps_misaligned.c:381:21: warning: dereference of noderef expression arch/riscv/kernel/traps_misaligned.c:322:24: warning: incorrect type in initializer (different address spaces) arch/riscv/kernel/traps_misaligned.c:322:24: expected unsigned char const [noderef] __user *__gu_ptr arch/riscv/kernel/traps_misaligned.c:322:24: got unsigned char const [usertype] *addr arch/riscv/kernel/traps_misaligned.c:361:21: warning: dereference of noderef expression arch/riscv/kernel/traps_misaligned.c:373:21: warning: dereference of noderef expression arch/riscv/kernel/traps_misaligned.c:381:21: warning: dereference of noderef expression arch/riscv/kernel/traps_misaligned.c:332:24: warning: incorrect type in initializer (different address spaces) arch/riscv/kernel/traps_misaligned.c:332:24: expected unsigned char [noderef] __user *__gu_ptr arch/riscv/kernel/traps_misaligned.c:332:24: got unsigned char [usertype] *addr Fixes: 7c832321 ("riscv: add support for misaligned trap handling in S-mode") Signed-off-by:
-
Jisheng Zhang authored
As said in the help of ARCH_WANTS_NO_INSTR entry in arch/Kconfig: "An architecture should select this if the noinstr macro is being used on functions to denote that the toolchain should avoid instrumenting such functions and is required for correctness." Select ARCH_WANTS_NO_INSTR for correctness. PS: The reason we didn't find any issue so far is that the CC_HAS_NO_PROFILE_FN_ATTR is true. Signed-off-by:
Jisheng Zhang <jszhang@kernel.org> Link: https://lore.kernel.org/r/20231123142223.1787-1-jszhang@kernel.orgSigned-off-by:
-
Palmer Dabbelt authored
Samuel Holland <samuel.holland@sifive.com> says: This series cleans up some duplicated and dead code around the RISC-V CPU operations, that was copied from arm64 but is not needed here. The result is a bit of memory savings and removal of a few SBI calls during boot, with no functional change. * b4-shazam-merge: riscv: Use the same CPU operations for all CPUs riscv: Remove unused members from struct cpu_operations riscv: Deduplicate code in setup_smp() Link: https://lore.kernel.org/r/20231121234736.3489608-1-samuel.holland@sifive.comSigned-off-by:
-
Samuel Holland authored
This file is not used since commit 72f045d1 ("riscv: Fixup difference with defconfig"), where it was replaced by the 32-bit.config fragment. Delete the old file to avoid any confusion. Signed-off-by:
Samuel Holland <samuel.holland@sifive.com> Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231121225320.3430550-1-samuel.holland@sifive.comSigned-off-by:
-
Palmer Dabbelt authored
Andrew Jones <ajones@ventanamicro.com> says: This series introduces a flag for the hwprobe syscall which effectively reverses its behavior from getting the values of keys for a set of cpus to getting the cpus for a set of key-value pairs. * b4-shazam-merge: RISC-V: selftests: Add which-cpus hwprobe test RISC-V: hwprobe: Introduce which-cpus flag RISC-V: Move the hwprobe syscall to its own file RISC-V: hwprobe: Clarify cpus size parameter Link: https://lore.kernel.org/r/20231122164700.127954-6-ajones@ventanamicro.comSigned-off-by:
-
Frederik Haxel authored
This enables, among other things, testing with the QEMU virt machine. To build an XIP kernel for the QEMU virt machine, configure the the kernel as desired and apply the following configuration ``` CONFIG_NONPORTABLE=y CONFIG_XIP_KERNEL=y CONFIG_XIP_PHYS_ADDR=0x20000000 CONFIG_PHYS_RAM_BASE=0x80200000 CONFIG_BUILTIN_DTB=n ``` Since the QEMU virt flash memory expects a 32 MB file, the built image must be padded. For example, with `truncate -s 32M arch/riscv/boot/xipImage` The kernel can be started using the following command in QEMU (v8+) ``` qemu-system-riscv64 -M virt,pflash0=pflash0 \ -blockdev node-name=pflash0,driver=file,read-only=on,\ filename=arch/riscv/boot/xipImage <optional parameters> ``` Signed-off-by:
Frederik Haxel <haxel@fzi.de> Link: https://lore.kernel.org/r/20231212130116.848530-4-haxel@fzi.deSigned-off-by:
-
Frederik Haxel authored
During the refactoring, a bug was introduced in the rarly used XIP_FIXUP_FLASH_OFFSET macro. Fixes: bee7fbc3 ("RISC-V CPU Idle Support") Fixes: e7681beb ("RISC-V: Split out the XIP fixups into their own file") Signed-off-by:
-
Frederik Haxel authored
Currently, the XIP kernel seems to fail to boot due to missing XIP_FIXUP and a wrong page_offset value. A superfluous XIP_FIXUP has also been removed. Signed-off-by:
-
- 09 Jan, 2024 4 commits
-
-
Alexandre Ghiti authored
When resetting the linear mapping permissions, we must make sure that we clear the X bit so that do not end up with WX mappings (since we set PAGE_KERNEL). Fixes: 395a21ff ("riscv: add ARCH_HAS_SET_DIRECT_MAP support") Signed-off-by:
Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20231213134027.155327-3-alexghiti@rivosinc.comSigned-off-by:
-
Alexandre Ghiti authored
After unloading a module, we must reset the linear mapping permissions, see the example below: Before unloading a module: 0xffffaf809d65d000-0xffffaf809d6dc000 0x000000011d65d000 508K PTE . .. .. D A G . . W R V 0xffffaf809d6dc000-0xffffaf809d6dd000 0x000000011d6dc000 4K PTE . .. .. D A G . . . R V 0xffffaf809d6dd000-0xffffaf809d6e1000 0x000000011d6dd000 16K PTE . .. .. D A G . . W R V 0xffffaf809d6e1000-0xffffaf809d6e7000 0x000000011d6e1000 24K PTE . .. .. D A G . X . R V After unloading a module: 0xffffaf809d65d000-0xffffaf809d6e1000 0x000000011d65d000 528K PTE . .. .. D A G . . W R V 0xffffaf809d6e1000-0xffffaf809d6e7000 0x000000011d6e1000 24K PTE . .. .. D A G . X W R V The last mapping is not reset and we end up with WX mappings in the linear mapping. So add VM_FLUSH_RESET_PERMS to our module_alloc() definition. Fixes: 0cff8bff ("riscv: avoid the PIC offset of static percpu data in module beyond 2G limits") Signed-off-by:
-
Alexandre Ghiti authored
lm_alias() can only be used on kernel mappings since it explicitly uses __pa_symbol(), so simply fix this by checking where the address belongs to before. Fixes: 311cd2f6 ("riscv: Fix set_memory_XX() and set_direct_map_XX() by splitting huge linear mappings") Reported-by: syzbot+afb726d49f84c8d95ee1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-riscv/000000000000620dd0060c02c5e1@google.com/Signed-off-by:
Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/20231212195400.128457-1-alexghiti@rivosinc.comSigned-off-by:
-
Alexandre Ghiti authored
Otherwise we fall through to vmalloc_to_page() which panics since the address does not lie in the vmalloc region. Fixes: 043cb41a ("riscv: introduce interfaces to patch kernel code") Signed-off-by:
-
- 04 Jan, 2024 3 commits
-
-
Samuel Holland authored
RISC-V provides no binding (ACPI or DT) to describe per-cpu start/stop operations, so cpu_set_ops() will always detect the same operations for every CPU. Replace the cpu_ops array with a single pointer to save space and reduce boot time. Signed-off-by:
-
Samuel Holland authored
name is not used anywhere at all. cpu_prepare and cpu_disable do nothing and always return 0 if implemented. Signed-off-by:
-
Samuel Holland authored
Both the ACPI and DT implementations contain some of the same code. Move it to the calling function so it is not duplicated. Signed-off-by:
-
- 03 Jan, 2024 5 commits
-
-
Andrew Jones authored
Test the RISCV_HWPROBE_WHICH_CPUS flag of hwprobe. The test also has a command line interface in order to get the cpu list for arbitrary hwprobe pairs. Reviewed-by:
Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20231122164700.127954-10-ajones@ventanamicro.comSigned-off-by:
-
Andrew Jones authored
Introduce the first flag for the hwprobe syscall. The flag basically reverses its behavior, i.e. instead of populating the values of keys for a given set of cpus, the set of cpus after the call is the result of finding a set which supports the values of the keys. In order to do this, we implement a pair compare function which takes the type of value (a single value vs. a bitmask of booleans) into consideration. We also implement vdso support for the new flag. Signed-off-by:
Evan Green <evan@rivosinc.com> Link: https://lore.kernel.org/r/20231122164700.127954-9-ajones@ventanamicro.comSigned-off-by:
-
Andrew Jones authored
As Palmer says, hwprobe is "sort of its own thing now, and it's only going to get bigger..." Suggested-by:
Palmer Dabbelt <palmer@dabbelt.com> Signed-off-by:
-
Andrew Jones authored
The "count" parameter associated with the 'cpus' parameter of the hwprobe syscall is the size in bytes of 'cpus'. Naming it 'cpu_count' may mislead users (it did me) to think it's the number of CPUs that are or can be represented by 'cpus' instead. This is particularly easy (IMO) to get wrong since 'cpus' is documented to be defined by CPU_SET(3) and CPU_SET(3) also documents a CPU_COUNT() (the number of CPUs in set) macro. CPU_SET(3) refers to the size of cpu sets with 'setsize'. Adopt 'cpusetsize' for the hwprobe parameter and specifically state it is in bytes in Documentation/riscv/hwprobe.rst to clarify. Reviewed-by:
-
Palmer Dabbelt authored
There were a few single-letter extensions that we had references to floating around in the kernel, but that never ended up as actual ISA specs and have mostly been replaced by multi-letter extensions. This removes the references to those extensions. Reviewed-by:
-
- 20 Dec, 2023 6 commits
-
-
Palmer Dabbelt authored
Alexandre Ghiti <alexghiti@rivosinc.com> says: This series is a follow-up for riscv of a recent series from Ryan [1] which converts all direct dereferences of pte_t into a ptet_get() access. The goal here for riscv is to use READ_ONCE()/WRITE_ONCE() for all page table entries accesses to avoid any compiler transformation when the hardware can concurrently modify the page tables entries (A/D bits for example). I went a bit further and added pud/p4d/pgd_get() helpers as such concurrent modifications can happen too at those levels. [1] https://lore.kernel.org/all/20230612151545.3317766-1-ryan.roberts@arm.com/ * b4-shazam-merge: riscv: Use accessors to page table entries instead of direct dereference riscv: mm: Only compile pgtable.c if MMU mm: Introduce pudp/p4dp/pgdp_get() functions riscv: Use WRITE_ONCE() when setting page table entries Link: https://lore.kernel.org/r/20231213203001.179237-1-alexghiti@rivosinc.comSigned-off-by:
-
Alexandre Ghiti authored
As very well explained in commit 20a004e7 ("arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables"), an architecture whose page table walker can modify the PTE in parallel must use READ_ONCE()/WRITE_ONCE() macro to avoid any compiler transformation. So apply that to riscv which is such architecture. Signed-off-by:
Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20231213203001.179237-5-alexghiti@rivosinc.comSigned-off-by:
-
Alexandre Ghiti authored
All functions defined in there depend on MMU, so no need to compile it for !MMU configs. Signed-off-by:
-
Alexandre Ghiti authored
Instead of directly dereferencing page tables entries, which can cause issues (see commit 20a004e7 ("arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables"), let's introduce new functions to get the pud/p4d/pgd entries (the pte and pmd versions already exist). Note that arm pgd_t is actually an array so pgdp_get() is defined as a macro to avoid a build error. Those new functions will be used in subsequent commits by the riscv architecture. Signed-off-by:
-
Alexandre Ghiti authored
To avoid any compiler "weirdness" when accessing page table entries which are concurrently modified by the HW, let's use WRITE_ONCE() macro (commit 20a004e7 ("arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables") gives a great explanation with more details). Signed-off-by:
-
Michal Simek authored
MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP. It is hardware compatible with classic MicroBlaze processor. Signed-off-by:
Michal Simek <michal.simek@amd.com> Acked-by:
Rob Herring <robh@kernel.org> Acked-by:
-
- 12 Dec, 2023 10 commits
-
-
Palmer Dabbelt authored
Clément Léger <cleger@rivosinc.com> says: In order to be able to gather more information about the supported ISA extensions from userspace using the hwprobe syscall, add more ISA extensions report. This series adds the following ISA extensions parsing support: - Zfh[min] - Zvfh[min] - Zihintntl - Zbc - Zvbb - Zvbc - Zvkb - Zvkg - Zvkned - Zvknh[ab] - Zvksed - Zvksh - Zvkn - Zvknc - Zvkng - Zvks - Zvksc - Zvksg - Zvkt - Zfa - Zbkb - Zbkc - Zbkx - Zknd - Zkne - Zknh - Zkr - Zksed - Zksh - Zkt Some of these extensions are actually shorthands for other "sub" extensions. This series includes a patch from Conor/Evan that adds a way to specify such "bundled" extensions. When exposing these bundled extensions to userspace through hwprobe, only the "sub" extensions are exposed. In order to test it, one can use qemu and the small hwprobe utility provided[1]. Run qemu by specifying additional ISA extensions, for instance: $ qemu-system-riscv64 -cpu rv64,v=true,zk=true,zvksh=true,zvkned=true <whatever options you want> Then, run hwprobe: $ ./hwprobe Base system ISA: - IMA_FD - C - V Supported extensions: - Zba - Zbb - Zbs - Zbc - Zbkb - Zbkc - Zbkx - Zknd - Zkne - Zknh - Zkt - Zvkned - Zvksh - Zihintntl - Zfa * b4-shazam-merge: dt-bindings: riscv: add Zfa ISA extension description riscv: hwprobe: export Zfa ISA extension riscv: add ISA extension parsing for Zfa dt-bindings: riscv: add Zvfh[min] ISA extension description riscv: hwprobe: export Zvfh[min] ISA extensions riscv: add ISA extension parsing for Zvfh[min] dt-bindings: riscv: add Zihintntl ISA extension description riscv: hwprobe: export Zhintntl ISA extension riscv: add ISA extension parsing for Zihintntl dt-bindings: riscv: add Zfh[min] ISA extensions description riscv: hwprobe: export Zfh[min] ISA extensions riscv: add ISA extension parsing for Zfh/Zfh[min] dt-bindings: riscv: add vector crypto ISA extensions description riscv: hwprobe: export vector crypto ISA extensions riscv: add ISA extension parsing for vector crypto dt-bindings: riscv: add scalar crypto ISA extensions description riscv: hwprobe: add support for scalar crypto ISA extensions riscv: add ISA extension parsing for scalar crypto riscv: hwprobe: export missing Zbc ISA extension riscv: add ISA extension parsing for Zbc Link: https://lore.kernel.org/r/20231114141256.126749-1-cleger@rivosinc.comSigned-off-by:
-
Clément Léger authored
Add description for the Zfa ISA extension[1]. Link: https://drive.google.com/file/d/1VT6QIggpb59-8QRV266dEE4T8FZTxGq4/view [1] Signed-off-by:
Clément Léger <cleger@rivosinc.com> Acked-by:
-
Clément Léger authored
Export Zfa ISA extension[1] through hwprobe. Link: https://drive.google.com/file/d/1VT6QIggpb59-8QRV266dEE4T8FZTxGq4/view [1] Signed-off-by:
-
Clément Léger authored
Add parsing for Zfa ISA extension [1] which were ratified in commit 056b6ff467c7 ("Zfa is ratified") of riscv-isa-manual[2]. Link: https://drive.google.com/file/d/1VT6QIggpb59-8QRV266dEE4T8FZTxGq4/view [1] Link: https://github.com/riscv/riscv-isa-manual/commits/056b6ff467c7 [2] Signed-off-by: -
Clément Léger authored
Add description for Zvfh[min] ISA extension[1]. Link: https://drive.google.com/file/d/1_Yt60HGAf1r1hx7JnsIptw0sqkBd9BQ8/view [1] Signed-off-by:
-
Clément Léger authored
Export Zvfh[min] ISA extension[1] through hwprobe. Link: https://drive.google.com/file/d/1_Yt60HGAf1r1hx7JnsIptw0sqkBd9BQ8/view [1] Signed-off-by:
-
Clément Léger authored
Add parsing for Zvfh[min] ISA extension[1] which were ratified in june 2023 around commit e2ccd0548d6c ("Remove draft warnings from Zvfh[min]") in riscv-v-spec[2]. Link: https://drive.google.com/file/d/1_Yt60HGAf1r1hx7JnsIptw0sqkBd9BQ8/view [1] Link: https://github.com/riscv/riscv-v-spec/commits/e2ccd0548d6c [2] Signed-off-by: -
Clément Léger authored
Add description for Zihintntl ISA extension[1]. Link: https://drive.google.com/file/d/13_wsN8YmRfH8YWysFyTX-DjTkCnBd9hj/view [1] Signed-off-by:
-
Clément Léger authored
Export Zihintntl extension[1] through hwprobe. Link: https://drive.google.com/file/d/13_wsN8YmRfH8YWysFyTX-DjTkCnBd9hj/view [1] Signed-off-by:
-
Clément Léger authored
Add parsing for Zihintntl ISA extension[1] that was ratified in commit 0dc91f5 ("Zihintntl is ratified") of riscv-isa-manual[2]. Link: https://drive.google.com/file/d/13_wsN8YmRfH8YWysFyTX-DjTkCnBd9hj/view [1] Link: https://github.com/riscv/riscv-isa-manual/commit/0dc91f505e6d [2] Signed-off-by:
-
