aboutsummaryrefslogtreecommitdiff
path: root/target/riscv
AgeCommit message (Collapse)Author
2023-12-04target/riscv/kvm: fix shadowing in kvm_riscv_(get|put)_regs_csrDaniel Henrique Barboza
KVM_RISCV_GET_CSR() and KVM_RISCV_SET_CSR() use an 'int ret' variable that is used to do an early 'return' if ret > 0. Both are being called in functions that are also declaring a 'ret' integer, initialized with '0', and this integer is used as return of the function. The result is that the compiler is less than pleased and is pointing shadowing errors: ../target/riscv/kvm/kvm-cpu.c: In function 'kvm_riscv_get_regs_csr': ../target/riscv/kvm/kvm-cpu.c:90:13: error: declaration of 'ret' shadows a previous local [-Werror=shadow=compatible-local] 90 | int ret = kvm_get_one_reg(cs, RISCV_CSR_REG(env, csr), &reg); \ | ^~~ ../target/riscv/kvm/kvm-cpu.c:539:5: note: in expansion of macro 'KVM_RISCV_GET_CSR' 539 | KVM_RISCV_GET_CSR(cs, env, sstatus, env->mstatus); | ^~~~~~~~~~~~~~~~~ ../target/riscv/kvm/kvm-cpu.c:536:9: note: shadowed declaration is here 536 | int ret = 0; | ^~~ ../target/riscv/kvm/kvm-cpu.c: In function 'kvm_riscv_put_regs_csr': ../target/riscv/kvm/kvm-cpu.c:98:13: error: declaration of 'ret' shadows a previous local [-Werror=shadow=compatible-local] 98 | int ret = kvm_set_one_reg(cs, RISCV_CSR_REG(env, csr), &reg); \ | ^~~ ../target/riscv/kvm/kvm-cpu.c:556:5: note: in expansion of macro 'KVM_RISCV_SET_CSR' 556 | KVM_RISCV_SET_CSR(cs, env, sstatus, env->mstatus); | ^~~~~~~~~~~~~~~~~ ../target/riscv/kvm/kvm-cpu.c:553:9: note: shadowed declaration is here 553 | int ret = 0; | ^~~ The macros are doing early returns for non-zero returns and the local 'ret' variable for both functions is used just to do 'return 0', so remove them from kvm_riscv_get_regs_csr() and kvm_riscv_put_regs_csr() and do a straight 'return 0' in the end. For good measure let's also rename the 'ret' variables in KVM_RISCV_GET_CSR() and KVM_RISCV_SET_CSR() to '_ret' to make them more resilient to these kind of errors. Fixes: 937f0b4512 ("target/riscv: Implement kvm_arch_get_registers") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231123101338.1040134-1-dbarboza@ventanamicro.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-11-22target/riscv/cpu_helper.c: Fix mxr bit behaviorIvan Klokov
According to RISCV Specification sect 9.5 on two stage translation when V=1 the vsstatus(mstatus in QEMU's terms) field MXR, which makes execute-only pages readable, only overrides VS-stage page protection. Setting MXR at HS-level(mstatus_hs), however, overrides both VS-stage and G-stage execute-only permissions. The hypervisor extension changes the behavior of MXR\MPV\MPRV bits. Due to RISCV Specification sect. 9.4.1 when MPRV=1, explicit memory accesses are translated and protected, and endianness is applied, as though the current virtualization mode were set to MPV and the current nominal privilege mode were set to MPP. vsstatus.MXR makes readable those pages marked executable at the VS translation stage. Fixes: 36a18664ba ("target/riscv: Implement second stage MMU") Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231121071757.7178-3-ivan.klokov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-22target/riscv/cpu_helper.c: Invalid exception on MMU translation stageIvan Klokov
According to RISCV privileged spec sect. 5.3.2 Virtual Address Translation Process access-fault exceptions may raise only after PMA/PMP check. Current implementation generates an access-fault for mbare mode even if there were no PMA/PMP errors. This patch removes the erroneous MMU mode check and generates an access-fault exception based on the pmp_violation flag only. Fixes: 1448689c7b ("target/riscv: Allow specifying MMU stage") Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231121071757.7178-2-ivan.klokov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-22target/riscv: don't verify ISA compatibility for zicntr and zihpmClément Chigot
The extensions zicntr and zihpm were officially added in the privilege instruction set specification 1.12. However, QEMU has been implemented them long before it and thus they are forced to be on during the cpu initialization to ensure compatibility (see riscv_cpu_init). riscv_cpu_disable_priv_spec_isa_exts was not updated when the above behavior was introduced, resulting in these extensions to be disabled after all. Signed-off-by: Clément Chigot <chigot@adacore.com> Fixes: c004099330 ("target/riscv: add zicntr extension flag for TCG") Fixes: 0824121660 ("target/riscv: add zihpm extension flag for TCG") Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231114123913.536194-1-chigot@adacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-15target/riscv/cpu.h: spelling fix: separatlyMichael Tokarev
Fixes: 40336d5b1d4c "target/riscv: Add HS-mode virtual interrupt and IRQ filtering support." Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-11-07hw/cpu: Call object_class_is_abstract() once in cpu_class_by_name()Philippe Mathieu-Daudé
Let CPUClass::class_by_name() handlers to return abstract classes, and filter them once in the public cpu_class_by_name() method. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230908112235.75914-3-philmd@linaro.org>
2023-11-07target: Move ArchCPUClass definition to 'cpu.h'Philippe Mathieu-Daudé
The OBJECT_DECLARE_CPU_TYPE() macro forward-declares each ArchCPUClass type. These forward declarations are sufficient for code in hw/ to use the QOM definitions. No need to expose these structure definitions. Keep each local to their target/ by moving them to the corresponding "cpu.h" header. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231013140116.255-13-philmd@linaro.org>
2023-11-07target/riscv: Use env_archcpu() in [check_]nanbox()Philippe Mathieu-Daudé
When CPUArchState* is available (here CPURISCVState*), we can use the fast env_archcpu() macro to get ArchCPU* (here RISCVCPU*). The QOM cast RISCV_CPU() macro will be slower when building with --enable-qom-cast-debug. Inspired-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20231009110239.66778-3-philmd@linaro.org>
2023-11-07target/riscv: Move TYPE_RISCV_CPU_BASE definition to 'cpu.h'Philippe Mathieu-Daudé
TYPE_RISCV_CPU_BASE depends on the TARGET_RISCV32/TARGET_RISCV64 definitions which are target specific. Such target specific definition taints "cpu-qom.h". Since "cpu-qom.h" must be target agnostic, remove its target specific definition uses by moving TYPE_RISCV_CPU_BASE to "target/riscv/cpu.h". "target/riscv/cpu-qom.h" is now fully target agnostic. Add a comment clarifying that in the header. Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231013140116.255-12-philmd@linaro.org>
2023-11-07target/riscv: Remove CPU_RESOLVING_TYPE from 'cpu-qom.h'Philippe Mathieu-Daudé
CPU_RESOLVING_TYPE is a per-target definition, and is irrelevant for other targets. Move it to "cpu.h". Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231013140116.255-6-philmd@linaro.org>
2023-11-07target: Unify QOM stylePhilippe Mathieu-Daudé
Enforce the style described by commit 067109a11c ("docs/devel: mention the spacing requirement for QOM"): The first declaration of a storage or class structure should always be the parent and leave a visual space between that declaration and the new code. It is also useful to separate backing for properties (options driven by the user) and internal state to make navigation easier. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20231013140116.255-2-philmd@linaro.org>
2023-11-07target/riscv: Add "pmu-mask" property to replace "pmu-num"Rob Bradford
Using a mask instead of the number of PMU devices supports the accurate emulation of platforms that have a discontinuous set of PMU counters. The "pmu-num" property now generates a warning when used by the user on the command line. Rather than storing the value for "pmu-num" convert it directly to the mask if it is specified (overwriting the default "pmu-mask" value) likewise the value is calculated from the mask if the property value is obtained. In the unusual situation that both "pmu-mask" and "pmu-num" are provided then then the order on the command line determines which takes precedence (later overwriting earlier.) Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231031154000.18134-5-rbradford@rivosinc.com> [Changes by AF - Fixup ext_zihpm logic after rebase ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Use existing PMU counter mask in FDT generationRob Bradford
During the FDT generation use the existing mask containing the enabled counters rather then generating a new one. Using the existing mask will support the use of discontinuous counters. Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Message-ID: <20231031154000.18134-4-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Don't assume PMU counters are continuousRob Bradford
Check the PMU available bitmask when checking if a counter is valid rather than comparing the index against the number of PMUs. Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Message-ID: <20231031154000.18134-3-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Propagate error from PMU setupRob Bradford
More closely follow the QEMU style by returning an Error and propagating it there is an error relating to the PMU setup. Further simplify the function by removing the num_counters parameter as this is available from the passed in cpu pointer. Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Message-ID: <20231031154000.18134-2-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: cpu: Set the OpenTitan priv to 1.12.0Alistair Francis
Set the Ibex CPU priv to 1.12.0 to ensure that smepmp/epmp is correctly enabled. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231102003424.2003428-3-alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Move vector crypto extensions to riscv_cpu_extensionsMax Chou
Because the vector crypto specification is ratified, so move theses extensions from riscv_cpu_experimental_exts to riscv_cpu_extensions. Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-11-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Expose Zvks[c|g] extnesion propertiesMax Chou
Expose the properties of ShangMi Algorithm Suite related extensions (Zvks, Zvksc, Zvksg). Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-10-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Add cfg properties for Zvks[c|g] extensionsMax Chou
Vector crypto spec defines the ShangMi algorithm suite related extensions (Zvks, Zvksc, Zvksg) combined by several vector crypto extensions. Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-9-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Expose Zvkn[c|g] extnesion propertiesMax Chou
Expose the properties of NIST Algorithm Suite related extensions (Zvkn, Zvknc, Zvkng). Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-8-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Add cfg properties for Zvkn[c|g] extensionsMax Chou
Vector crypto spec defines the NIST algorithm suite related extensions (Zvkn, Zvknc, Zvkng) combined by several vector crypto extensions. Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-7-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Expose Zvkb extension propertyMax Chou
Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-6-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Replace Zvbb checking by ZvkbMax Chou
The Zvkb extension is a proper subset of the Zvbb extension and includes following instructions: * vandn.[vv,vx] * vbrev8.v * vrev8.v * vrol.[vv,vx] * vror.[vv,vx,vi] Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-5-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Add cfg property for Zvkb extensionMax Chou
After vector crypto spec v1.0.0-rc3 release, the Zvkb extension is defined as a proper subset of the Zvbb extension. And both the Zvkn and Zvks shorthand extensions replace the included Zvbb extension by Zvkb extnesion. Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-4-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Expose Zvkt extension propertyMax Chou
Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-3-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Add cfg property for Zvkt extensionMax Chou
Vector crypto spec defines the Zvkt extension that included all of the instructions of Zvbb & Zvbc extensions and some vector instructions. Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-2-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: correct csr_ops[CSR_MSECCFG]Heinrich Schuchardt
The CSR register mseccfg is used by multiple extensions: Smepm and Zkr. Consider this when checking the existence of the register. Fixes: 77442380ecbe ("target/riscv: rvk: add CSR support for Zkr") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231030102105.19501-1-heinrich.schuchardt@canonical.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv/kvm: add zicsr, zifencei, zba, zbs, svnapotDaniel Henrique Barboza
These regs were added in Linux 6.6. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231031205150.208405-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv/kvm: add zihpm regDaniel Henrique Barboza
Add zihpm support in the KVM driver now that QEMU supports it. This reg was added in Linux 6.6. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: add zihpm extension flag for TCGDaniel Henrique Barboza
zihpm is the Hardware Performance Counters extension described in chapter 12 of the unprivileged spec. It describes support for 29 unprivileged performance counters, hpmcounter3-hpmcounter31. As with zicntr, QEMU already implements zihpm before it was even an extension. zihpm is also part of the RVA22 profile, so add it to QEMU to complement the future profile implementation. Default it to 'true' for all existing CPUs since it was always present in the code. As for disabling it, there is already code in place in target/riscv/csr.c in all predicates for these counters (ctr() and mctr()) that disables them if cpu->cfg.pmu_num is zero. Thus, setting cpu->cfg.pmu_num to zero if 'zihpm=false' is enough to disable the extension. Set cpu->pmu_avail_ctrs mask to zero as well since this is also checked to verify if the counters exist. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv/kvm: add zicntr regDaniel Henrique Barboza
Add zicntr support in the KVM driver now that QEMU supports it. This reg was added in Linux 6.6. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: add zicntr extension flag for TCGDaniel Henrique Barboza
zicntr is the Base Counters and Timers extension described in chapter 12 of the unprivileged spec. It describes support for RDCYCLE, RDTIME and RDINSTRET. QEMU already implements it in TCG way before it was a discrete extension. zicntr is part of the RVA22 profile, so let's add it to QEMU to make the future profile implementation flag complete. Given than it represents an already existing feature, default it to 'true' for all CPUs. For TCG, we need a way to disable zicntr if the user wants to. This is done by restricting access to the CYCLE, TIME, and INSTRET counters via the 'ctr()' predicate when we're about to access them. Disabling zicntr happens via the command line or if its dependency, zicsr, happens to be disabled. We'll check for zicsr during realize() and, in case it's absent, disable zicntr. However, if the user was explicit about having zicntr support, error out instead of disabling it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: pmp: Ignore writes when RW=01Mayuresh Chitale
As per the Priv spec: "The R, W, and X fields form a collective WARL field for which the combinations with R=0 and W=1 are reserved." However currently such writes are not ignored as ought to be. The combinations with RW=01 are allowed only when the Smepmp extension is enabled and mseccfg.MML is set. Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231019065705.1431868-1-mchitale@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: pmp: Clear pmp/smepmp bits on resetMayuresh Chitale
As per the Priv and Smepmp specifications, certain bits such as the 'L' bit of pmp entries and mseccfg.MML can only be cleared upon reset and it is necessary to do so to allow 'M' mode firmware to correctly reinitialize the pmp/smpemp state across reboots. As required by the spec, also clear the 'A' field of pmp entries. Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231019065644.1431798-1-mchitale@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07Add epmp to extensions list and rename it to smepmpHimanshu Chauhan
Smepmp is a ratified extension which qemu refers to as epmp. Rename epmp to smepmp and add it to extension list so that it is added to the isa string. Signed-off-by: Himanshu Chauhan <hchauhan@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231019065546.1431579-1-mchitale@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv/riscv-qmp-cmds.c: check CPU accel in query-cpu-model-expansionDaniel Henrique Barboza
Use the recently added riscv_cpu_accelerator_compatible() to filter unavailable CPUs for a given accelerator. At this moment this is the case for a QEMU built with KVM and TCG support querying a binary running with TCG: qemu-system-riscv64 -S -M virt,accel=tcg -display none -qmp tcp:localhost:1234,server,wait=off ./qemu/scripts/qmp/qmp-shell localhost:1234 (QEMU) query-cpu-model-expansion type=full model={"name":"host"} {"error": {"class": "GenericError", "desc": "'host' CPU not available with tcg"}} Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: add riscv_cpu_accelerator_compatible()Daniel Henrique Barboza
Add an API to check if a given CPU is compatible with the current accelerator. This will allow query-cpu-model-expansion to work properly in conditions where QEMU supports both accelerators (TCG and KVM), QEMU is then launched using TCG, and the API requests information about a KVM only CPU (e.g. 'host' CPU). KVM doesn't have such restrictions and, at least in theory, all CPUs models should work with KVM. We will revisit this API in case we decide to restrict the amount of KVM CPUs we support. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: handle custom props in qmp_query_cpu_model_expansionDaniel Henrique Barboza
Callers can add 'props' when querying for a cpu model expansion to see if a given CPU model supports a certain criteria, and what's the resulting CPU object. If we have 'props' to handle, gather it in a QDict and use the new riscv_cpuobj_validate_qdict_in() helper to validate it. This helper will add the custom properties in the CPU object and validate it using riscv_cpu_finalize_features(). Users will be aware of validation errors if any occur, if not a CPU object with 'props' will be returned. Here's an example with the veyron-v1 vendor CPU. Disabling vendor CPU extensions is allowed, assuming the final config is valid. Disabling 'smstateen' is a valid expansion: (QEMU) query-cpu-model-expansion type=full model={"name":"veyron-v1","props":{"smstateen":false}} {"return": {"model": {"name": "veyron-v1", "props": {"zicond": false, ..., "smstateen": false, ...} But enabling extensions isn't allowed for vendor CPUs. E.g. enabling 'V' for the veyron-v1 CPU isn't allowed: (QEMU) query-cpu-model-expansion type=full model={"name":"veyron-v1","props":{"v":true}} {"error": {"class": "GenericError", "desc": "'veyron-v1' CPU does not allow enabling extensions"}} Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv/tcg: add tcg_cpu_finalize_features()Daniel Henrique Barboza
The query-cpu-model-expansion API is capable of passing extra properties to a given CPU model and tell callers if this custom configuration is valid. The RISC-V version of the API is not quite there yet. The reason is the realize() flow in the TCG driver, where most of the validation is done in tcg_cpu_realizefn(). riscv_cpu_finalize_features() is then used to validate satp_mode for both TCG and KVM CPUs. Our ARM friends uses a concept of 'finalize_features()', a step done in the end of realize() where the CPU features are validated. We have a riscv_cpu_finalize_features() helper that, at this moment, is only validating satp_mode. Re-use this existing helper to do all CPU extension validation we required after at the end of realize(). Make it public to allow APIs to use it. At this moment only the TCG driver requires a realize() time validation, thus, to avoid adding accelerator specific helpers in the API, riscv_cpu_finalize_features() uses riscv_tcg_cpu_finalize_features() if we are running TCG. The API will then use riscv_cpu_finalize_features() regardless of the current accelerator. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07qapi,risc-v: add query-cpu-model-expansionDaniel Henrique Barboza
This API is used to inspect the characteristics of a given CPU model. It also allows users to validate a CPU model with a certain configuration, e.g. if "-cpu X,a=true,b=false" is a valid setup for a given QEMU binary. We'll start implementing the first part. The second requires more changes in RISC-V CPU boot flow. The implementation is inspired by the existing ARM query-cpu-model-expansion impl in target/arm/arm-qmp-cmds.c. We'll create a RISCVCPU object with the required model, fetch its existing properties, add a couple of relevant boolean options (pmp and mmu) and display it to users. Here's an usage example: ./build/qemu-system-riscv64 -S -M virt -display none \ -qmp tcp:localhost:1234,server,wait=off ./scripts/qmp/qmp-shell localhost:1234 Welcome to the QMP low-level shell! Connected to QEMU 8.1.50 (QEMU) query-cpu-model-expansion type=full model={"name":"rv64"} {"return": {"model": {"name": "rv64", "props": {"zicond": false, "x-zvfh": false, "mmu": true, "x-zvfbfwma": false, "x-zvfbfmin": false, "xtheadbs": false, "xtheadbb": false, "xtheadba": false, "xtheadmemidx": false, "smstateen": false, "zfinx": false, "Zve64f": false, "Zve32f": false, "x-zvfhmin": false, "xventanacondops": false, "xtheadcondmov": false, "svpbmt": false, "zbs": true, "zbc": true, "zbb": true, "zba": true, "zicboz": true, "xtheadmac": false, "Zfh": false, "Zfa": true, "zbkx": false, "zbkc": false, "zbkb": false, "Zve64d": false, "x-zfbfmin": false, "zk": false, "x-epmp": false, "xtheadmempair": false, "zkt": false, "zks": false, "zkr": false, "zkn": false, "Zfhmin": false, "zksh": false, "zknh": false, "zkne": false, "zknd": false, "zhinx": false, "Zicsr": true, "sscofpmf": false, "Zihintntl": true, "sstc": true, "xtheadcmo": false, "x-zvbb": false, "zksed": false, "x-zvkned": false, "xtheadsync": false, "x-zvkg": false, "zhinxmin": false, "svadu": true, "xtheadfmv": false, "x-zvksed": false, "svnapot": false, "pmp": true, "x-zvknhb": false, "x-zvknha": false, "xtheadfmemidx": false, "x-zvksh": false, "zdinx": false, "zicbom": true, "Zihintpause": true, "svinval": false, "zcf": false, "zce": false, "zcd": false, "zcb": false, "zca": false, "x-ssaia": false, "x-smaia": false, "zmmul": false, "x-zvbc": false, "Zifencei": true, "zcmt": false, "zcmp": false, "Zawrs": true}}}} Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv/kvm/kvm-cpu.c: add missing property getters()Daniel Henrique Barboza
We got along without property getters in the KVM driver because we never needed them. But the incoming query-cpu-model-expansion API will use property getters and setters to retrieve the CPU characteristics. Add the missing getters for the KVM driver for both MISA and multi-letter extension properties. We're also adding an special getter for absent multi-letter properties that KVM doesn't implement that always return false. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Add HS-mode virtual interrupt and IRQ filtering support.Rajnesh Kanwal
This change adds support for inserting virtual interrupts from HS-mode into VS-mode using hvien and hvip csrs. This also allows for IRQ filtering from HS-mode. Also, the spec doesn't mandate the interrupt to be actually supported in hardware. Which allows HS-mode to assert virtual interrupts to VS-mode that have no connection to any real interrupt events. This is defined as part of the AIA specification [0], "6.3.2 Virtual interrupts for VS level". [0]: https://github.com/riscv/riscv-aia/releases/download/1.0/riscv-interrupts-1.0.pdf Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231016111736.28721-7-rkanwal@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Add M-mode virtual interrupt and IRQ filtering support.Rajnesh Kanwal
This change adds support for inserting virtual interrupts from M-mode into S-mode using mvien and mvip csrs. IRQ filtering is a use case of this change, i-e M-mode can stop delegating an interrupt to S-mode and instead enable it in MIE and receive those interrupts in M-mode and then selectively inject the interrupt using mvien and mvip. Also, the spec doesn't mandate the interrupt to be actually supported in hardware. Which allows M-mode to assert virtual interrupts to S-mode that have no connection to any real interrupt events. This is defined as part of the AIA specification [0], "5.3 Interrupt filtering and virtual interrupts for supervisor level". [0]: https://github.com/riscv/riscv-aia/releases/download/1.0/riscv-interrupts-1.0.pdf Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231016111736.28721-6-rkanwal@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Split interrupt logic from riscv_cpu_update_mip.Rajnesh Kanwal
This is to allow virtual interrupts to be inserted into S and VS modes. Given virtual interrupts will be maintained in separate mvip and hvip CSRs, riscv_cpu_update_mip will no longer be in the path and interrupts need to be triggered for these cases from rmw_hvip64 and rmw_mvip64 functions. Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231016111736.28721-5-rkanwal@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Set VS* bits to one in mideleg when H-Ext is enabledRajnesh Kanwal
With H-Ext supported, VS bits are all hardwired to one in MIDELEG denoting always delegated interrupts. This is being done in rmw_mideleg but given mideleg is used in other places when routing interrupts this change initializes it in riscv_cpu_realize to be on the safe side. Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231016111736.28721-4-rkanwal@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Check for async flag in case of RISCV_EXCP_SEMIHOST.Rajnesh Kanwal
RISCV_EXCP_SEMIHOST is set to 0x10, which can be a local interrupt id as well. This change moves RISCV_EXCP_SEMIHOST to switch case so that async flag check is performed before invoking semihosting logic. Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231016111736.28721-3-rkanwal@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: Without H-mode mask all HS mode inturrupts in mie.Rajnesh Kanwal
Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231016111736.28721-2-rkanwal@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: rename ext_icboz to ext_zicbozDaniel Henrique Barboza
Add a leading 'z' to improve grepping. When one wants to search for uses of zicboz they're more likely to do 'grep -i zicboz' than 'grep -i icboz'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231012164604.398496-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: rename ext_icbom to ext_zicbomDaniel Henrique Barboza
Add a leading 'z' to improve grepping. When one wants to search for uses of zicbom they're more likely to do 'grep -i zicbom' than 'grep -i icbom'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231012164604.398496-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-07target/riscv: rename ext_icsr to ext_zicsrDaniel Henrique Barboza
Add a leading 'z' to improve grepping. When one wants to search for uses of zicsr they're more likely to do 'grep -i zicsr' than 'grep -i icsr'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231012164604.398496-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 12:47:31 +0000