- Jun 21, 2023
-
-
Sunil V L authored
CPPC registers can be implemented as architecture specific FFH registers. Implement the FFH access routines for RISC-V which use SBI CPPC extension. Signed-off-by:Sunil V L <sunilvl@ventanamicro.com>
-
Sunil V L authored
When the DesiredPerformanceRegister is in PCC, the transition latency is determined by using PCCT. However, if the DesiredPerformanceRegister is an FFH address, we need a new weak function to return architecture specific latency value. Add a new weak function for this purpose. Signed-off-by: -
Sunil V L authored
Add helper functions to init and make state transitions of LPI states of ACPI. These routines will use SBI HSM extension to do the final transition. Signed-off-by: -
Sunil V L authored
Few functions like sbi_suspend() need to be called by both DT based cpuidle driver and ACPI LPI driver. So, move these common functions to a more generic suspend.c so that they can be shared. Signed-off-by: -
Sunil V L authored
The ACPI processor driver is not currently enabled for RISC-V. This is required to enable CPU related functionalities like LPI and CPPC. Signed-off-by: -
Sunil V L authored
Enable detecting RISC-V PLIC structure in MADT Signed-off-by:Haibo, Xu <haibo1.xu@intel.com>
-
Sunil V L authored
Signed-off-by: -
Sunil V L authored
Signed-off-by: -
Sunil V L authored
Signed-off-by: -
Sunil V L authored
The RISC-V APLIC is a wired to MSI interrupt converter device which is a platform device. However, this is also a type of interrupt controller and hence it is enumerated using MADT table. This is somewhat similar to how SMMU is initialized using IORT on ACPI based systems. Instead of adding individual platform device initialization, add a weak function which can be defined by each platform. This approach allows to add IOMMU device also in future without modifying the common path. Signed-off-by: -
Sunil V L authored
Signed-off-by: -
Sunil V L authored
Signed-off-by: -
Sunil V L authored
Signed-off-by: -
Anup Patel authored
Signed-off-by:Anup Patel <apatel@ventanamicro.com>
-
Sunil V L authored
Similar to PCI, there can be platform devices which need MSI services. They need to know what is the MSI domain on ACPI based systems. So, similar to pci-msi, provide a way in platform-msi to register the MSI controller's fwnode. Signed-off-by: -
Sunil V L authored
Signed-off-by: -
Sunil V L authored
ACPICA commit 242ae5e29c55cdc157e46d3a2ed8ea090e070824 To be Approved. Link: https://github.com/acpica/acpica/commit/242ae5e2 Reference: Mantis: 2382 Signed-off-by:
-
Sunil V L authored
ACPICA commit 2756c6ed68d6850da35e65f16c489985995f28d7 RISC-V PLIC is a platform interrupt controller for handling wired interrupt in a RISC-V systems. Add its structure definition in the MADT table. Link: https://github.com/acpica/acpica/commit/2756c6ed Signed-off-by:
-
Sunil V L authored
ACPICA commit 5d72bdcbdccbdc1e6d5d2c48b576d8a25d258f60 To be approved. Link: https://github.com/acpica/acpica/commit/5d72bdcb Reference: Mantis ID: 2381 Signed-off-by:
-
Sunil V L authored
ACPI needs some of the PCI related functions defined by each architecture. Replace existing dummy implementation with a proper implementation which uses MCFG and ECAM.
-
Sunil V L authored
As part of "RISC-V IPI Improvements" patch series, there is a new interface for drivers to use to discover the INTC hwnode. This patch is required to support SSCOFPMF irrespective of DT or ACPI. Signed-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>
-
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:
Conor Dooley <conor.dooley@microchip.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:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
Heiko Stuebner <heiko.stuebner@vrull.eu> Tested-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:
-
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:
Björn Töpel <bjorn@rivosinc.com> Reviewed-by:
Guo Ren <guoren@kernel.org> Reviewed-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:
Palmer Dabbelt <palmer@rivosinc.com>
-
