- 20 Jun, 2023 2 commits
-
-
Jisheng Zhang authored
Attempt VMA lock-based page fault handling first, and fall back to the existing mmap_lock-based handling if that fails. A simple running the ebizzy benchmark on Lichee Pi 4A shows that PER_VMA_LOCK can improve the ebizzy benchmark by about 32.68%. In theory, the more CPUs, the bigger improvement, but I don't have any HW platform which has more than 4 CPUs. This is the riscv variant of "x86/mm: try VMA lock-based page fault handling first". Signed-off-by:
Jisheng Zhang <jszhang@kernel.org> Reviewed-by:
Guo Ren <guoren@kernel.org> Reviewed-by:
Suren Baghdasaryan <surenb@google.com> Link: https://lore.kernel.org/r/20230523165942.2630-1-jszhang@kernel.orgSigned-off-by:
Palmer Dabbelt <palmer@rivosinc.com>
-
Björn Töpel authored
The RISC-V port requires that kernel PGD entries are to be synchronized between MMs. This is done via the vmalloc_fault() function, that simply copies the PGD entries from init_mm to the faulting one. Historically, faulting in PGD entries have been a source for both bugs [1], and poor performance. One way to get rid of vmalloc faults is by pre-allocating the PGD entries. Pre-allocating the entries potientially wastes 64 * 4K (65 on SV39). The pre-allocation function is pulled from Jörg Rödel's x86 work, with the addition of 3-level page tables (PMD allocations). The pmd_alloc() function needs the ptlock cache to be initialized (when split page locks is enabled), so the pre-allocation is done in a RISC-V specific pgtable_cache_init() implementation. Pre-allocate the kernel PGD entries for the vmalloc/modules area, but only for 64b platforms. Link: https://lore.kernel.org/lkml/20200508144043.13893-1-joro@8bytes.org/ # [1] Signed-off-by:
Björn Töpel <bjorn@rivosinc.com> Reviewed-by:
Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230531093817.665799-1-bjorn@kernel.orgSigned-off-by:
-
- 19 Jun, 2023 9 commits
-
-
Palmer Dabbelt authored
Evan Green <evan@rivosinc.com> says: This change detects the presence of Zba, Zbb, and Zbs extensions and exports them per-hart to userspace via the hwprobe mechanism. Glibc can then use these in setting up hwcaps-based library search paths. There's a little bit of extra housekeeping here: the first change adds Zba and Zbs to the set of extensions the kernel recognizes, and the second change starts tracking ISA features per-hart (in addition to the ANDed mask of features across all harts which the kernel uses to make decisions). Now that we track the ISA information per-hart, we could even fix up /proc/cpuinfo to accurately report extension per-hart, though I've left that out of this series for now. * b4-shazam-merge: RISC-V: hwprobe: Expose Zba, Zbb, and Zbs RISC-V: Track ISA extensions per hart RISC-V: Add Zba, Zbs extension probing Link: https://lore.kernel.org/r/20230509182504.2997252-1-evan@rivosinc.comSigned-off-by:
-
Evan Green authored
Add two new bits to the IMA_EXT_0 key for ZBA, ZBB, and ZBS extensions. These are accurately reported per CPU. Signed-off-by:
Evan Green <evan@rivosinc.com> Reviewed-by:
Andrew Jones <ajones@ventanamicro.com> Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
Heiko Stuebner <heiko.stuebner@vrull.eu> Link: https://lore.kernel.org/r/20230509182504.2997252-4-evan@rivosinc.comSigned-off-by:
-
Evan Green authored
The kernel maintains a mask of ISA extensions ANDed together across all harts. Let's also keep a bitmap of ISA extensions for each CPU. Although the kernel is currently unlikely to enable a feature that exists only on some CPUs, we want the ability to report asymmetric CPU extensions accurately to usermode. Note that riscv_fill_hwcaps() runs before the per_cpu_offsets are built, which is why I've used a [NR_CPUS] array rather than per_cpu() data. Signed-off-by:
-
Evan Green authored
Add the Zba address bit manipulation extension and Zbs single bit instructions extension into those the kernel is aware of and maintains in its riscv_isa bitmap. Signed-off-by:
-
Krzysztof Kozlowski authored
Cleanup bindings dropping unneeded quotes. Once all these are fixed, checking for this can be enabled in yamllint. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Rob Herring <robh@kernel.org> Acked-by:
-
Sunil V L authored
Currently the PMU driver is using DT based lookup to find the INTC node for sscofpmf extension. This will not work for ACPI based systems causing the driver to fail to register the PMU overflow interrupt handler. Hence, change the code to use the standard interface to find the INTC node which works irrespective of DT or ACPI. Signed-off-by:
Sunil V L <sunilvl@ventanamicro.com> Reviewed-by:
Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20230607112417.782085-3-sunilvl@ventanamicro.comSigned-off-by:
-
Sunil V L authored
The arch specific __acpi_map_table can be wrapper around either early_memremap or early_ioremap. But early_memremap routine works with normal pointers whereas __acpi_map_table expects pointers in iomem address space. This causes kernel test bot to fail while using the sparse tool. Fix the issue by using early_ioremap and similar fix done for __acpi_unmap_table. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202305201427.I7QhPjNW-lkp@intel.com/ Fixes: a91a9ffb ("RISC-V: Add support to build the ACPI core") Signed-off-by:
-
Song Shuai authored
The suspend_restore_csrs is called in both __hibernate_cpu_resume and the `else` of subsequent swsusp_arch_suspend. Removing the first call makes both suspend_{save,restore}_csrs left in swsusp_arch_suspend for clean code. Fixes: c0317210 ("RISC-V: Add arch functions to support hibernation/suspend-to-disk") Reviewed-by:JeeHeng Sia <jeeheng.sia@starfivetech.com> Signed-off-by:
Song Shuai <songshuaishuai@tinylab.org> Link: https://lore.kernel.org/r/20230522025020.285042-1-songshuaishuai@tinylab.orgSigned-off-by:
-
Song Shuai authored
No need to link the x1/ra reg via jalr before suspend_restore_regs So it's better to replace jalr with jr. Signed-off-by:
Song Shuai <suagrfillet@gmail.com> Reviewed-by: JeeHeng Sia <jeeheng.sia@starfivetech.com > Link: https://lore.kernel.org/r/20230519060854.214138-1-suagrfillet@gmail.comSigned-off-by:
-
- 14 Jun, 2023 2 commits
-
-
Jisheng Zhang authored
extable relies on the MMU to work properly, so it's useless to include __ex_table sections and build extable related functions for !MMU case. Signed-off-by:
-
Ben Dooks authored
If Zicbom is present but there was no riscv,cbom-blocks-size property found during the cpu feeatures probe, or the cbom-block-size is not valid, then the extension will be disabled. Make the print explicitly say this is disabled to ensure that there is no confusion about what is being done. Signed-off-by:
Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by:
-
- 08 Jun, 2023 27 commits
-
-
Palmer Dabbelt authored
Andy Chiu <andy.chiu@sifive.com> says: This is the v21 patch series for adding Vector extension support in Linux. Please refer to [1] for the introduction of the patchset. The v21 patch series was aimed to solve build issues from v19, provide usage guideline for the prctl interface, and address review comments on v20. Thank every one who has been reviewing, suggesting on the topic. Hope this get a step closer to the final merge. * b4-shazam-merge: (27 commits) selftests: add .gitignore file for RISC-V hwprobe selftests: Test RISC-V Vector prctl interface riscv: Add documentation for Vector riscv: Enable Vector code to be built riscv: detect assembler support for .option arch riscv: Add sysctl to set the default vector rule for new processes riscv: Add prctl controls for userspace vector management riscv: hwcap: change ELF_HWCAP to a function riscv: KVM: Add vector lazy save/restore support riscv: kvm: Add V extension to KVM ISA riscv: prevent stack corruption by reserving task_pt_regs(p) early riscv: signal: validate altstack to reflect Vector riscv: signal: Report signal frame size to userspace via auxv riscv: signal: Add sigcontext save/restore for vector riscv: signal: check fp-reserved words unconditionally riscv: Add ptrace vector support riscv: Allocate user's vector context in the first-use trap riscv: Add task switch support for vector riscv: Introduce struct/helpers to save/restore per-task Vector state riscv: Introduce riscv_v_vsize to record size of Vector context ... Link: https://lore.kernel.org/r/20230605110724.21391-1-andy.chiu@sifive.comSigned-off-by:
-
Andy Chiu authored
The executable file "hwprobe" should be ignored by git, adding it to fix that. Signed-off-by:
Andy Chiu <andy.chiu@sifive.com> Link: https://lore.kernel.org/r/20230605110724.21391-28-andy.chiu@sifive.comSigned-off-by:
-
Andy Chiu authored
This add a test for prctl interface that controls the use of userspace Vector. Signed-off-by:
-
Andy Chiu authored
This patch add a brief documentation of the userspace interface in regard to the RISC-V Vector extension. Signed-off-by:
Greentime Hu <greentime.hu@sifive.com> Reviewed-by:
Vincent Chen <vincent.chen@sifive.com> Co-developed-by:
Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by:
-
Guo Ren authored
This patch adds configs for building Vector code. First it detects the reqired toolchain support for building the code. Then it provides an option setting whether Vector is implicitly enabled to userspace. Signed-off-by:
Guo Ren <guoren@linux.alibaba.com> Co-developed-by:
-
Andy Chiu authored
Some extensions use .option arch directive to selectively enable certain extensions in parts of its assembly code. For example, Zbb uses it to inform assmebler to emit bit manipulation instructions. However, supporting of this directive only exist on GNU assembler and has not landed on clang at the moment, making TOOLCHAIN_HAS_ZBB depend on AS_IS_GNU. While it is still under review at https://reviews.llvm.org/D123515, the upcoming Vector patch also requires this feature in assembler. Thus, provide Kconfig AS_HAS_OPTION_ARCH to detect such feature. Then TOOLCHAIN_HAS_XXX will be turned on automatically when the feature land. Suggested-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
Andy Chiu authored
To support Vector extension, the series exports variable-length vector registers on the signal frame. However, this potentially breaks abi if processing vector registers is required in the signal handler for old binaries. For example, there is such need if user-level context switch is triggerred via signals[1]. For this reason, it is best to leave a decision to distro maintainers, where the enablement of userspace Vector for new launching programs can be controlled. Developers may also need the switch to experiment with. The parameter is configurable through sysctl interface so a distro may turn off Vector early at init script if the break really happens in the wild. The switch will only take effects on new execve() calls once set. This will not effect existing processes that do not call execve(), nor processes which has been set with a non-default vstate_ctrl by making explicit PR_RISCV_V_SET_CONTROL prctl() calls. Link: https://lore.kernel.org/all/87cz4048rp.fsf@all.your.base.are.belong.to.us/Signed-off-by:
-
Andy Chiu authored
This patch add two riscv-specific prctls, to allow usespace control the use of vector unit: * PR_RISCV_V_SET_CONTROL: control the permission to use Vector at next, or all following execve for a thread. Turning off a thread's Vector live is not possible since libraries may have registered ifunc that may execute Vector instructions. * PR_RISCV_V_GET_CONTROL: get the same permission setting for the current thread, and the setting for following execve(s). Signed-off-by:
-
Andy Chiu authored
Using a function is flexible to represent ELF_HWCAP. So the kernel may encode hwcap reflecting supported hardware features just at the moment of the start of each program. This will be helpful when we introduce prctl/sysctl interface to control per-process availability of Vector extension in following patches. Programs started with V disabled should see V masked off in theirs ELF_HWCAP. Signed-off-by:
-
Vincent Chen authored
This patch adds vector context save/restore for guest VCPUs. To reduce the impact on KVM performance, the implementation imitates the FP context switch mechanism to lazily store and restore the vector context only when the kernel enters/exits the in-kernel run loop and not during the KVM world switch. Signed-off-by:
Anup Patel <anup@brainfault.org> Acked-by:
-
Vincent Chen authored
Add V extension to KVM isa extension list to enable supporting of V extension on VCPUs. Signed-off-by:
-
Greentime Hu authored
Early function calls, such as setup_vm(), relocate_enable_mmu(), soc_early_init() etc, are free to operate on stack. However, PT_SIZE_ON_STACK bytes at the head of the kernel stack are purposedly reserved for the placement of per-task register context pointed by task_pt_regs(p). Those functions may corrupt task_pt_regs if we overlap the $sp with it. In fact, we had accidentally corrupted sstatus.VS in some tests, treating the kernel to save V context before V was actually allocated, resulting in a kernel panic. Thus, we should skip PT_SIZE_ON_STACK for $sp before making C function calls from the top-level assembly. Co-developed-by:
ShihPo Hung <shihpo.hung@sifive.com> Signed-off-by:
-
Andy Chiu authored
Some extensions, such as Vector, dynamically change footprint on a signal frame, so MINSIGSTKSZ is no longer accurate. For example, an RV64V implementation with vlen = 512 may occupy 2K + 40 + 12 Bytes of a signal frame with the upcoming support. And processes that do not execute any vector instructions do not need to reserve the extra sigframe. So we need a way to guard the allocation size of the sigframe at process runtime according to current status of V. Thus, provide the function sigaltstack_size_valid() to validate its size based on current allocation status of supported extensions. Signed-off-by:
-
Vincent Chen authored
The vector register belongs to the signal context. They need to be stored and restored as entering and leaving the signal handler. According to the V-extension specification, the maximum length of the vector registers can be 2^16. Hence, if userspace refers to the MINSIGSTKSZ to create a sigframe, it may not be enough. To resolve this problem, this patch refers to the commit 94b07c1f ("arm64: signal: Report signal frame size to userspace via auxv") to enable userspace to know the minimum required sigframe size through the auxiliary vector and use it to allocate enough memory for signal context. Note that auxv always reports size of the sigframe as if V exists for all starting processes, whenever the kernel has CONFIG_RISCV_ISA_V. The reason is that users usually reference this value to allocate an alternative signal stack, and the user may use V anytime. So the user must reserve a space for V-context in sigframe in case that the signal handler invokes after the kernel allocating V. Signed-off-by:
-
Greentime Hu authored
This patch facilitates the existing fp-reserved words for placement of the first extension's context header on the user's sigframe. A context header consists of a distinct magic word and the size, including the header itself, of an extension on the stack. Then, the frame is followed by the context of that extension, and then a header + context body for another extension if exists. If there is no more extension to come, then the frame must be ended with a null context header. A special case is rv64gc, where the kernel support no extensions requiring to expose additional regfile to the user. In such case the kernel would place the null context header right after the first reserved word of __riscv_q_ext_state when saving sigframe. And the kernel would check if all reserved words are zeros when a signal handler returns. __riscv_q_ext_state---->| |<-__riscv_extra_ext_header ~ ~ .reserved[0]--->|0 |<- .reserved <-------|magic |<- .hdr | |size |_______ end of sc_fpregs | |ext-bdy| | ~ ~ +)size ------->|magic |<- another context header |size | |ext-bdy| ~ ~ |magic:0|<- null context header |size:0 | The vector registers will be saved in datap pointer. The datap pointer will be allocated dynamically when the task needs in kernel space. On the other hand, datap pointer on the sigframe will be set right after the __riscv_v_ext_state data structure. Co-developed-by:
Vineet Gupta <vineetg@rivosinc.com> Suggested-by:
Richard Henderson <richard.henderson@linaro.org> Co-developed-by:
-
Andy Chiu authored
In order to let kernel/user locate and identify an extension context on the existing sigframe, we are going to utilize reserved space of fp and encode the information there. And since the sigcontext has already preserved a space for fp context w or w/o CONFIG_FPU, we move those reserved words checking/setting routine back into generic code. This commit also undone an additional logical change carried by the refactor commit 007f5c35 ("Refactor FPU code in signal setup/return procedures"). Originally we did not restore fp context if restoring of gpr have failed. And it was fine on the other side. In such way the kernel could keep the regfiles intact, and potentially react at the failing point of restore. Signed-off-by:
-
Greentime Hu authored
This patch adds ptrace support for riscv vector. The vector registers will be saved in datap pointer of __riscv_v_ext_state. This pointer will be set right after the __riscv_v_ext_state data structure then it will be put in ubuf for ptrace system call to get or set. It will check if the datap got from ubuf is set to the correct address or not when the ptrace system call is trying to set the vector registers. Co-developed-by:
-
Andy Chiu authored
Vector unit is disabled by default for all user processes. Thus, a process will take a trap (illegal instruction) into kernel at the first time when it uses Vector. Only after then, the kernel allocates V context and starts take care of the context for that user process. Suggested-by:
-
Greentime Hu authored
This patch adds task switch support for vector. It also supports all lengths of vlen. Suggested-by:
Andrew Waterman <andrew@sifive.com> Co-developed-by:
Nick Knight <nick.knight@sifive.com> Signed-off-by:
Ruinland Tsai <ruinland.tsai@sifive.com> Signed-off-by:
-
Greentime Hu authored
Add vector state context struct to be added later in thread_struct. And prepare low-level helper functions to save/restore vector contexts. This include Vector Regfile and CSRs holding dynamic configuration state (vstart, vl, vtype, vcsr). The Vec Register width could be implementation defined, but same for all processes, so that is saved separately. This is not yet wired into final thread_struct - will be done when __switch_to actually starts doing this in later patches. Given the variable (and potentially large) size of regfile, they are saved in dynamically allocated memory, pointed to by datap pointer in __riscv_v_ext_state. Co-developed-by:
-
Greentime Hu authored
This patch is used to detect the size of CPU vector registers and use riscv_v_vsize to save the size of all the vector registers. It assumes all harts has the same capabilities in a SMP system. If a core detects VLENB that is different from the boot core, then it warns and turns off V support for user space. Co-developed-by:
-
Greentime Hu authored
These are small and likely to be frequently called so implement as inline routines (vs. function call). Co-developed-by:
-
Guo Ren authored
Disable vector instructions execution for kernel mode at its entrances. This helps find illegal uses of vector in the kernel space, which is similar to the fpu. Signed-off-by:
Han-Kuan Chen <hankuan.chen@sifive.com> Signed-off-by:
-
Greentime Hu authored
clear vector registers on boot if kernel supports V. Signed-off-by:
-
Greentime Hu authored
Follow the riscv vector spec to add new csr numbers. Acked-by:
-
Andy Chiu authored
Probing kernel support for Vector extension is available now. This only add detection for V only. Extenions like Zvfh, Zk are not in this scope. Signed-off-by:
-
Guo Ren authored
Add V-extension into riscv_isa_ext_keys array and detect it with isa string parsing. Signed-off-by:
Guo Ren <ren_guo@c-sky.com> Signed-off-by:
-
