aboutsummaryrefslogtreecommitdiff
path: root/target/riscv/cpu_cfg.h
AgeCommit message (Collapse)Author
2024-03-22target/riscv: do not enable all named features by defaultDaniel Henrique Barboza
Commit 3b8022269c added the capability of named features/profile extensions to be added in riscv,isa. To do that we had to assign priv versions for each one of them in isa_edata_arr[]. But this resulted in a side-effect: vendor CPUs that aren't running priv_version_latest started to experience warnings for these profile extensions [1]: | $ qemu-system-riscv32 -M sifive_e | qemu-system-riscv32: warning: disabling zic64b extension for hart 0x00000000 because privilege spec version does not match | qemu-system-riscv32: warning: disabling ziccamoa extension for hart 0x00000000 because privilege spec version does not match This is benign as far as the CPU behavior is concerned since disabling both extensions is a no-op (aside from riscv,isa). But the warnings are unpleasant to deal with, especially because we're sending user warnings for extensions that users can't enable/disable. Instead of enabling all named features all the time, separate them by priv version. During finalize() time, after we decided which priv_version the CPU is running, enable/disable all the named extensions based on the priv spec chosen. This will be enough for a bug fix, but as a future work we should look into how we can name these extensions in a way that we don't need an explicit ext_name => priv_ver as we're doing here. The named extensions being added in isa_edata_arr[] that will be enabled/disabled based solely on priv version can be removed from riscv_cpu_named_features[]. 'zic64b' is an extension that can be disabled based on block sizes so it'll retain its own flag and entry. [1] https://lists.gnu.org/archive/html/qemu-devel/2024-03/msg02592.html Reported-by: Clément Chigot <chigot@adacore.com> Fixes: 3b8022269c ("target/riscv: add riscv,isa to named features") 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> Tested-by: Clément Chigot <chigot@adacore.com> Message-ID: <20240312203214.350980-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-08RISC-V: Add support for ZtsoPalmer Dabbelt
The Ztso extension is already ratified, this adds it as a CPU property and adds various fences throughout the port in order to allow TSO targets to function on weaker hosts. We need no fences for AMOs as they're already SC, the places we need barriers are described. These fences are placed in the RISC-V backend rather than TCG as is planned for x86-on-arm64 because RISC-V allows heterogeneous (and likely soon dynamic) hart memory models. Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-ID: <20240207122256.902627-2-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-08target/riscv: add remaining named featuresDaniel Henrique Barboza
The RVA22U64 and RVA22S64 profiles mandates certain extensions that, until now, we were implying that they were available. We can't do this anymore since named features also has a riscv,isa entry. Let's add them to riscv_cpu_named_features[]. Instead of adding one bool for each named feature that we'll always implement, i.e. can't be turned off, add a 'ext_always_enabled' bool in cpu->cfg. This bool will be set to 'true' in TCG accel init, and all named features will point to it. This also means that KVM won't see these features as always enable, which is our intention. If any accelerator adds support to disable one of these features, we'll have to promote them to regular extensions and allow users to disable it via command line. After this patch, here's the riscv,isa from a buildroot using the 'rva22s64' CPU: # cat /proc/device-tree/cpus/cpu@0/riscv,isa rv64imafdc_zic64b_zicbom_zicbop_zicboz_ziccamoa_ziccif_zicclsm_ziccrse_ zicntr_zicsr_zifencei_zihintpause_zihpm_za64rs_zfhmin_zca_zcd_zba_zbb_ zbs_zkt_ssccptr_sscounterenw_sstvala_sstvecd_svade_svinval_svpbmt# 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: <20240215223955.969568-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-08target/riscv: add riscv,isa to named featuresDaniel Henrique Barboza
Further discussions after the introduction of rva22 support in QEMU revealed that what we've been calling 'named features' are actually regular extensions, with their respective riscv,isa DTs. This is clarified in [1]. [2] is a bug tracker asking for the profile spec to be less cryptic about it. As far as QEMU goes we understand extensions as something that the user can enable/disable in the command line. This isn't the case for named features, so we'll have to reach a middle ground. We'll keep our existing nomenclature 'named features' to refer to any extension that the user can't control in the command line. We'll also do the following: - 'svade' and 'zic64b' flags are renamed to 'ext_svade' and 'ext_zic64b'. 'ext_svade' and 'ext_zic64b' now have riscv,isa strings and priv_spec versions; - skip name feature check in cpu_bump_multi_ext_priv_ver(). Now that named features have a riscv,isa and an entry in isa_edata_arr[] we don't need to gate the call to cpu_cfg_ext_get_min_version() anymore. [1] https://github.com/riscv/riscv-profiles/issues/121 [2] https://github.com/riscv/riscv-profiles/issues/142 Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240215223955.969568-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv: Add Zaamo and Zalrsc extension infrastructureRob Bradford
These extensions represent the atomic operations from A (Zaamo) and the Load-Reserved/Store-Conditional operations from A (Zalrsc) Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240123111030.15074-2-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/cpu.c: remove cpu->cfg.vlenDaniel Henrique Barboza
There is no need to keep both 'vlen' and 'vlenb'. All existing code that requires 'vlen' is retrieving it via 'vlenb << 3'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122161107.26737-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv: add 'vlenb' field in cpu->cfgDaniel Henrique Barboza
Our usage of 'vlenb' is overwhelming superior than the use of 'vlen'. We're using 'vlenb' most of the time, having to do 'vlen >> 3' or 'vlen / 8' in every instance. In hindsight we would be better if the 'vlenb' property was introduced instead of 'vlen'. That's not what happened, and now we can't easily get rid of it due to user scripts all around. What we can do, however, is to change our internal representation to use 'vlenb'. Add a 'vlenb' field in cpu->cfg. It'll be set via the existing 'vlen' property, i.e. setting 'vlen' will also set 'vlenb'. We'll replace all 'vlen >> 3' code to use 'vlenb' directly. Start with the single instance we have in target/riscv/cpu.c. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122161107.26737-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv: rework 'vext_spec'Daniel Henrique Barboza
The same rework did in 'priv_spec' is done for 'vext_spec'. This time is simpler, since we only accept one value ("v1.0") and we'll always have env->vext_ver set to VEXT_VERSION_1_00_0, thus we don't need helpers to convert string to 'vext_ver' back and forth like we needed for 'priv_spec'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv: rework 'priv_spec'Daniel Henrique Barboza
'priv_spec' and 'vext_spec' are two string options used as a fancy way of setting integers in the CPU state (cpu->env.priv_ver and cpu->env.vext_ver). It requires us to deal with string parsing and to store them in cpu_cfg. We must support these string options, but we don't need to store them. We have a precedence for this kind of arrangement in target/ppc/compat.c, ppc_compat_prop_get|set, getters and setters used for the 'max-cpu-compat' class property of the pseries ppc64 machine. We'll do the same with both 'priv_spec' and 'vext_spec'. For 'priv_spec', the validation from riscv_cpu_validate_priv_spec() will be done by the prop_priv_spec_set() setter, while also preventing it to be changed for vendor CPUs. Add two helpers that converts env->priv_ver back and forth to its string representation. These helpers allow us to get a string and set 'env->priv_ver' and return a string giving the current env->priv_ver value. In other words, make the cpu->cfg.priv_spec string obsolete. Last but not the least, move the reworked 'priv_spec' option to riscv_cpu_properties[]. After all said and done, we don't need to store the 'priv_spec' string in the CPU state, and we're now protecting vendor CPUs from priv_ver changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,priv_spec="v1.12.0" qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.priv_spec=v1.12.0: CPU 'sifive-e51' does not allow changing the value of 'priv_spec' Current 'priv_spec' val: v1.10.0 $ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/cpu_cfg.h: remove unused fieldsDaniel Henrique Barboza
user_spec, bext_spec and bext_ver aren't being used. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: implement svadeDaniel Henrique Barboza
'svade' is a RVA22S64 profile requirement, a profile we're going to add shortly. It is a named feature (i.e. not a formal extension, not defined in riscv,isa DT at this moment) defined in [1] as: "Page-fault exceptions are raised when a page is accessed when A bit is clear, or written when D bit is clear.". As far as the spec goes, 'svade' is one of the two distinct modes of handling PTE_A and PTE_D. The other way, i.e. update PTE_A/PTE_D when they're cleared, is defined by the 'svadu' extension. Checking cpu_helper.c, get_physical_address(), we can verify that QEMU is compliant with that: we will update PTE_A/PTE_D if 'svadu' is enabled, or throw a page-fault exception if 'svadu' isn't enabled. So, as far as we're concerned, 'svade' translates to 'svadu must be disabled'. We'll implement it like 'zic64b': an internal flag that profiles can enable. The flag will not be exposed to users. [1] https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-20-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/tcg: add 'zic64b' supportDaniel Henrique Barboza
zic64b is defined in the RVA22U64 profile [1] as a named feature for "Cache blocks must be 64 bytes in size, naturally aligned in the address space". It's a fantasy name for 64 bytes cache blocks. The RVA22U64 profile mandates this feature, meaning that applications using this profile expects 64 bytes cache blocks. To make the upcoming RVA22U64 implementation complete, we'll zic64b as a 'named feature', not a regular extension. This means that: - it won't be exposed to users; - it won't be written in riscv,isa. This will be extended to other named extensions in the future, so we're creating some common boilerplate for them as well. zic64b is default to 'true' since we're already using 64 bytes blocks. If any cache block size (cbo{m,p,z}_blocksize) is changed to something different than 64, zic64b is set to 'false'. Our profile implementation will then be able to check the current state of zic64b and take the appropriate action (e.g. throw a warning). [1] https://github.com/riscv/riscv-profiles/releases/download/v1.0/profiles.pdf Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: add zicbop extension flagDaniel Henrique Barboza
QEMU already implements zicbom (Cache Block Management Operations) and zicboz (Cache Block Zero Operations). Commit 59cb29d6a5 ("target/riscv: add Zicbop cbo.prefetch{i, r, m} placeholder") added placeholders for what would be the instructions for zicbop (Cache Block Prefetch Operations), which are now no-ops. The RVA22U64 profile mandates zicbop, which means that applications that run with this profile might expect zicbop to be present in the riscv,isa DT and might behave badly if it's absent. Adding zicbop as an extension will make our future RVA22U64 implementation more in line with what userspace expects and, if/when cache block prefetch operations became relevant to QEMU, we already have the extension flag to turn then on/off as needed. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: Add support for Zacas extensionWeiwei Li
Add support for amocas.w/d/q instructions which are part of the ratified Zacas extension: https://github.com/riscv/riscv-zacas Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231207153842.32401-2-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
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: 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: 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: 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: 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: 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: 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-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: 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>
2023-11-07target/riscv: rename ext_ifencei to ext_zifenceiDaniel Henrique Barboza
Add a leading 'z' to improve grepping. When one wants to search for uses of zifencei they're more likely to do 'grep -i zifencei' than 'grep -i ifencei'. 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-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Add Zihintntl extension ISA string to DTSJason Chien
RVA23 Profiles states: The RVA23 profiles are intended to be used for 64-bit application processors that will run rich OS stacks from standard binary OS distributions and with a substantial number of third-party binary user applications that will be supported over a considerable length of time in the field. The chapter 4 of the unprivileged spec introduces the Zihintntl extension and Zihintntl is a mandatory extension presented in RVA23 Profiles, whose purpose is to enable application and operating system portability across different implementations. Thus the DTS should contain the Zihintntl ISA string in order to pass to software. The unprivileged spec states: Like any HINTs, these instructions may be freely ignored. Hence, although they are described in terms of cache-based memory hierarchies, they do not mandate the provision of caches. These instructions are encoded with non-used opcode, e.g. ADD x0, x0, x2, which QEMU already supports, and QEMU does not emulate cache. Therefore these instructions can be considered as a no-op, and we only need to add a new property for the Zihintntl extension. Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Jason Chien <jason.chien@sifive.com> Message-ID: <20230726074049.19505-2-jason.chien@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Add Zvksed ISA extension supportMax Chou
This commit adds support for the Zvksed vector-crypto extension, which consists of the following instructions: * vsm4k.vi * vsm4r.[vv,vs] Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> [lawrence.hunter@codethink.co.uk: Moved SM4 functions from crypto_helper.c to vcrypto_helper.c] [nazar.kazakov@codethink.co.uk: Added alignment checks, refactored code to use macros, and minor style changes] Signed-off-by: Max Chou <max.chou@sifive.com> Message-ID: <20230711165917.2629866-16-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Add Zvkg ISA extension supportNazar Kazakov
This commit adds support for the Zvkg vector-crypto extension, which consists of the following instructions: * vgmul.vv * vghsh.vv Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Co-authored-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> [max.chou@sifive.com: Replaced vstart checking by TCG op] Signed-off-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> [max.chou@sifive.com: Exposed x-zvkg property] [max.chou@sifive.com: Replaced uint by int for cross win32 build] Message-ID: <20230711165917.2629866-13-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Add Zvksh ISA extension supportLawrence Hunter
This commit adds support for the Zvksh vector-crypto extension, which consists of the following instructions: * vsm3me.vv * vsm3c.vi Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Co-authored-by: Kiran Ostrolenk <kiran.ostrolenk@codethink.co.uk> [max.chou@sifive.com: Replaced vstart checking by TCG op] Signed-off-by: Kiran Ostrolenk <kiran.ostrolenk@codethink.co.uk> Signed-off-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> [max.chou@sifive.com: Exposed x-zvksh property] Message-ID: <20230711165917.2629866-12-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Add Zvknh ISA extension supportKiran Ostrolenk
This commit adds support for the Zvknh vector-crypto extension, which consists of the following instructions: * vsha2ms.vv * vsha2c[hl].vv Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Co-authored-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Co-authored-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> [max.chou@sifive.com: Replaced vstart checking by TCG op] Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Signed-off-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> Signed-off-by: Kiran Ostrolenk <kiran.ostrolenk@codethink.co.uk> Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> [max.chou@sifive.com: Exposed x-zvknha & x-zvknhb properties] [max.chou@sifive.com: Replaced SEW selection to happened during translation] Message-ID: <20230711165917.2629866-11-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Add Zvkned ISA extension supportNazar Kazakov
This commit adds support for the Zvkned vector-crypto extension, which consists of the following instructions: * vaesef.[vv,vs] * vaesdf.[vv,vs] * vaesdm.[vv,vs] * vaesz.vs * vaesem.[vv,vs] * vaeskf1.vi * vaeskf2.vi Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Co-authored-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> Co-authored-by: William Salmon <will.salmon@codethink.co.uk> [max.chou@sifive.com: Replaced vstart checking by TCG op] Signed-off-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> Signed-off-by: William Salmon <will.salmon@codethink.co.uk> Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> [max.chou@sifive.com: Imported aes-round.h and exposed x-zvkned property] [max.chou@sifive.com: Fixed endian issues and replaced the vstart & vl egs checking by helper function] [max.chou@sifive.com: Replaced bswap32 calls in aes key expanding] Message-ID: <20230711165917.2629866-10-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Add Zvbb ISA extension supportDickon Hood
This commit adds support for the Zvbb vector-crypto extension, which consists of the following instructions: * vrol.[vv,vx] * vror.[vv,vx,vi] * vbrev8.v * vrev8.v * vandn.[vv,vx] * vbrev.v * vclz.v * vctz.v * vcpop.v * vwsll.[vv,vx,vi] Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Co-authored-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Co-authored-by: William Salmon <will.salmon@codethink.co.uk> Co-authored-by: Kiran Ostrolenk <kiran.ostrolenk@codethink.co.uk> [max.chou@sifive.com: Fix imm mode of vror.vi] Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Signed-off-by: William Salmon <will.salmon@codethink.co.uk> Signed-off-by: Kiran Ostrolenk <kiran.ostrolenk@codethink.co.uk> Signed-off-by: Dickon Hood <dickon.hood@codethink.co.uk> Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> [max.chou@sifive.com: Exposed x-zvbb property] Message-ID: <20230711165917.2629866-9-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Add Zvbc ISA extension supportLawrence Hunter
This commit adds support for the Zvbc vector-crypto extension, which consists of the following instructions: * vclmulh.[vx,vv] * vclmul.[vx,vv] Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Co-authored-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Co-authored-by: Max Chou <max.chou@sifive.com> Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Signed-off-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> Signed-off-by: Max Chou <max.chou@sifive.com> [max.chou@sifive.com: Exposed x-zvbc property] Message-ID: <20230711165917.2629866-5-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10riscv: Add support for the Zfa extensionChristoph Müllner
This patch introduces the RISC-V Zfa extension, which introduces additional floating-point instructions: * fli (load-immediate) with pre-defined immediates * fminm/fmaxm (like fmin/fmax but with different NaN behaviour) * fround/froundmx (round to integer) * fcvtmod.w.d (Modular Convert-to-Integer) * fmv* to access high bits of float register bigger than XLEN * Quiet comparison instructions (fleq/fltq) Zfa defines its instructions in combination with the following extensions: * single-precision floating-point (F) * double-precision floating-point (D) * quad-precision floating-point (Q) * half-precision floating-point (Zfh) Since QEMU does not support the RISC-V quad-precision floating-point ISA extension (Q), this patch does not include the instructions that depend on this extension. All other instructions are included in this patch. The Zfa specification can be found here: https://github.com/riscv/riscv-isa-manual/blob/master/src/zfa.tex The Zfa specifciation is frozen and is in public review since May 3, 2023: https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/SED4ntBkabg The patch also includes a TCG test for the fcvtmod.w.d instruction. The test cases test for correct results and flag behaviour. Note, that the Zfa specification requires fcvtmod's flag behaviour to be identical to a fcvt with the same operands (which is also tested). Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-Id: <20230710071243.282464-1-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: Add properties for BF16 extensionsWeiwei Li
Add ext_zfbfmin/zvfbfmin/zvfbfwma properties. Add require check for BF16 extensions. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230615063302.102409-2-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10disas/riscv: Add support for XThead* instructionsChristoph Müllner
Support for emulating XThead* instruction has been added recently. This patch adds support for these instructions to the RISC-V disassembler. Co-developed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-Id: <20230612111034.3955227-9-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: Factor out extension tests to cpu_cfg.hChristoph Müllner
This patch moves the extension test functions that are used to gate vendor extension decoders, into cpu_cfg.h. This allows to reuse them in the disassembler. This patch does not introduce new functionality. However, the patch includes a small change: The parameter for the extension test functions has been changed from 'DisasContext*' to 'const RISCVCPUConfig*' to keep the code in cpu_cfg.h self-contained. Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Message-Id: <20230612111034.3955227-3-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-06-13target/riscv: Split RISCVCPUConfig declarations from cpu.h into cpu_cfg.hWeiwei Li
Split RISCVCPUConfig declarations to prepare for passing it to disas. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230523093539.203909-3-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-17 16:50:50 +0000