aboutsummaryrefslogtreecommitdiff
path: root/target/riscv
AgeCommit message (Collapse)Author
2023-10-12target/riscv: make CPUCFG() macro publicDaniel Henrique Barboza
The RISC-V KVM driver uses a CPUCFG() macro that calculates the offset of a certain field in the struct RISCVCPUConfig. We're going to use this macro in target/riscv/cpu.c as well in the next patches. Make it public. Rename it to CPU_CFG_OFFSET() for more clarity while we're at it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: use offset in isa_ext_is_enabled/update_enabledDaniel Henrique Barboza
We'll have future usage for a function where, given an offset of the struct RISCVCPUConfig, the flag is updated to a certain val. Change all existing callers to use edata->ext_enable_offset instead of 'edata'. 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: <20230912132423.268494-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: deprecate the 'any' CPU typeDaniel Henrique Barboza
The 'any' CPU type was introduced in commit dc5bd18fa5725 ("RISC-V CPU Core Definition"), being around since the beginning. It's not an easy CPU to use: it's undocumented and its name doesn't tell users much about what the CPU is supposed to bring. 'git log' doesn't help us either in knowing what was the original design of this CPU type. The closest we have is a comment from Alistair [1] where he recalls from memory that the 'any' CPU is supposed to behave like the newly added 'max' CPU. He also suggested that the 'any' CPU should be removed. The default CPUs are rv32 and rv64, so removing the 'any' CPU will have impact only on users that might have a script that uses '-cpu any'. And those users are better off using the default CPUs or the new 'max' CPU. We would love to just remove the code and be done with it, but one does not simply remove a feature in QEMU. We'll put the CPU in quarantine first, letting users know that we have the intent of removing it in the future. [1] https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02891.html Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: add 'max' CPU typeDaniel Henrique Barboza
The 'max' CPU type is used by tooling to determine what's the most capable CPU a current QEMU version implements. Other archs such as ARM implements this type. Let's add it to RISC-V. What we consider "most capable CPU" in this context are related to ratified, non-vendor extensions. This means that we want the 'max' CPU to enable all (possible) ratified extensions by default. The reasoning behind this design is (1) vendor extensions can conflict with each other and we won't play favorities deciding which one is default or not and (2) non-ratified extensions are always prone to changes, not being stable enough to be enabled by default. All this said, we're still not able to enable all ratified extensions due to conflicts between them. Zfinx and all its dependencies aren't enabled because of a conflict with RVF. zce, zcmp and zcmt are also disabled due to RVD conflicts. When running with 64 bits we're also disabling zcf. MISA bits RVG, RVJ and RVV are also being set manually since they're default disabled. This is the resulting 'riscv,isa' DT for this new CPU: rv64imafdcvh_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_ zfh_zfhmin_zca_zcb_zcd_zba_zbb_zbc_zbkb_zbkc_zbkx_zbs_zk_zkn_zknd_ zkne_zknh_zkr_zks_zksed_zksh_zkt_zve32f_zve64f_zve64d_ smstateen_sscofpmf_sstc_svadu_svinval_svnapot_svpbmt Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: limit cfg->vext_spec log messageDaniel Henrique Barboza
Inside riscv_cpu_validate_v() we're always throwing a log message if the user didn't set a vector version via 'vext_spec'. We're going to include one case with the 'max' CPU where env->vext_ver will be set in the cpu_init(). But that alone will not stop the "vector version is not specified" message from appearing. The usefulness of this log message is debatable for the generic CPUs, but for a 'max' CPU type, where we are supposed to deliver a CPU model with all features possible, it's strange to force users to set 'vext_spec' to get rid of this message. Change riscv_cpu_validate_v() to not throw this log message if env->vext_ver is already set. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Message-ID: <20230912132423.268494-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: add riscv_cpu_add_kvm_unavail_prop_array()Daniel Henrique Barboza
Use a helper in riscv_cpu_add_kvm_properties() to eliminate some of its code repetition. 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: <20230912132423.268494-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: add riscv_cpu_add_qdev_prop_array()Daniel Henrique Barboza
The code inside riscv_cpu_add_user_properties() became quite repetitive after recent changes. Add a helper to hide the repetition away. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: split vendor exts from riscv_cpu_extensions[]Daniel Henrique Barboza
Our goal is to make riscv_cpu_extensions[] hold only ratified, non-vendor extensions. Create a new riscv_cpu_vendor_exts[] array for them, changing riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties() accordingly. 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: <20230912132423.268494-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: split non-ratified exts from riscv_cpu_extensions[]Daniel Henrique Barboza
Create a new riscv_cpu_experimental_exts[] to store the non-ratified extensions properties. Once they are ratified we'll move them back to riscv_cpu_extensions[]. riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties() are changed to keep adding non-ratified properties to users. 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: <20230912132423.268494-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: add DEFINE_PROP_END_OF_LIST() to riscv_cpu_options[]Daniel Henrique Barboza
Add DEFINE_PROP_END_OF_LIST() and eliminate the ARRAY_SIZE() usage when iterating in the riscv_cpu_options[] array, making it similar to what we already do when working with riscv_cpu_extensions[]. We also have a more sophisticated motivation behind this change. In the future we might need to export riscv_cpu_options[] to other files, and ARRAY_LIST() doesn't work properly in that case because the array size isn't exposed to the header file. Here's a future sight of what we would deal with: ./target/riscv/kvm.c:1057:5: error: nested extern declaration of 'riscv_cpu_add_misa_properties' [-Werror=nested-externs] n file included from ../target/riscv/kvm.c:19: home/danielhb/work/qemu/include/qemu/osdep.h:473:31: error: invalid application of 'sizeof' to incomplete type 'const RISCVCPUMultiExtConfig[]' 473 | #define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + \ | ^ ./target/riscv/kvm.c:1047:29: note: in expansion of macro 'ARRAY_SIZE' 1047 | for (int i = 0; i < ARRAY_SIZE(_array); i++) { \ | ^~~~~~~~~~ ./target/riscv/kvm.c:1059:5: note: in expansion of macro 'ADD_UNAVAIL_KVM_PROP_ARRAY' 1059 | ADD_UNAVAIL_KVM_PROP_ARRAY(obj, riscv_cpu_extensions); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ home/danielhb/work/qemu/include/qemu/osdep.h:473:31: error: invalid application of 'sizeof' to incomplete type 'const RISCVCPUMultiExtConfig[]' 473 | #define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + \ | ^ ./target/riscv/kvm.c:1047:29: note: in expansion of macro 'ARRAY_SIZE' 1047 | for (int i = 0; i < ARRAY_SIZE(_array); i++) { \ Homogenize the present and change the future by using DEFINE_PROP_END_OF_LIST() in riscv_cpu_options[]. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: split kvm prop handling to its own helperDaniel Henrique Barboza
Future patches will split the existing Property arrays even further, and the existing code in riscv_cpu_add_user_properties() will start to scale bad with it because it's dealing with KVM constraints mixed in with TCG constraints. We're going to pay a high price to share a couple of common lines of code between the two. Create a new kvm_riscv_cpu_add_kvm_properties() helper that will be forked from riscv_cpu_add_user_properties() if we're running KVM. The helper includes all properties that a KVM CPU will add. The rest of riscv_cpu_add_user_properties() body will then be relieved from having to deal with KVM constraints. The helper was declared in kvm_stubs.h, while being implemented in cpu.c, to allow '--enable-debug' builds to work. The compiler won't remove the kvm_riscv_cpu_add_kvm_properties() reference when 'kvm_enabled()' is false if we end up with an unused function. Even though being a KVM only helper we can't implement it in kvm.c due to its many dependencies inside cpu.c, so make it public in kvm_riscv.h and keep its implementation in cpu.c for now. We'll move it to kvm.c in the near future. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: skip 'bool' check when filtering KVM propsDaniel Henrique Barboza
After the introduction of riscv_cpu_options[] all properties in riscv_cpu_extensions[] are booleans. This check is now obsolete. 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: <20230912132423.268494-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: split CPU options from riscv_cpu_extensions[]Daniel Henrique Barboza
We'll add a new CPU type that will enable a considerable amount of extensions. To make it easier for us we'll do a few cleanups in our existing riscv_cpu_extensions[] array. Start by splitting all CPU non-boolean options from it. Create a new riscv_cpu_options[] array for them. Add all these properties in riscv_cpu_add_user_properties() as it is already being done today. 'mmu' and 'pmp' aren't really extensions in the usual way we think about RISC-V extensions. These are closer to CPU features/options, so move both to riscv_cpu_options[] too. In the near future we'll need to match all extensions with all entries in isa_edata_arr[], and so it happens that both 'mmu' and 'pmp' do not have a riscv,isa string (thus, no priv spec version restriction). This further emphasizes the point that these are more a CPU option than an extension. No functional changes made. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-11hw/core/cpu: Return static value with gdb_arch_name()Akihiko Odaki
All implementations of gdb_arch_name() returns dynamic duplicates of static strings. It's also unlikely that there will be an implementation of gdb_arch_name() that returns a truly dynamic value due to the nature of the function returning a well-known identifiers. Qualify the value gdb_arch_name() with const and make all of its implementations return static strings. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230912224107.29669-8-akihiko.odaki@daynix.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231009164104.369749-15-alex.bennee@linaro.org>
2023-10-07meson: Rename target_softmmu_arch -> target_system_archPhilippe Mathieu-Daudé
Finish the convertion started with commit de6cd7599b ("meson: Replace softmmu_ss -> system_ss"). If the $target_type is 'system', then use the target_system_arch[] source set :) Mechanical change doing: $ sed -i -e s/target_softmmu_arch/target_system_arch/g \ $(git grep -l target_softmmu_arch) Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231004090629.37473-13-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-10-07tcg: Correct invalid mentions of 'softmmu' by 'system-mode'Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231004090629.37473-6-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-10-04accel/tcg: Remove cpu_set_cpustate_pointersRichard Henderson
This function is now empty, so remove it. In the case of m68k and tricore, this empties the class instance initfn, so remove those as well. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-04accel/tcg: Replace CPUState.env_ptr with cpu_env()Richard Henderson
Reviewed-by: Anton Johansson <anjo@rev.ng> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-03tcg: Rename cpu_env to tcg_envRichard Henderson
Allow the name 'cpu_env' to be used for something else. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-03accel/tcg: Move CPUNegativeOffsetState into CPUStateRichard Henderson
Retain the separate structure to emphasize its importance. Enforce CPUArchState always follows CPUState without padding. Reviewed-by: Anton Johansson <anjo@rev.ng> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-10-03target/*: Add instance_align to all cpu base classesRichard Henderson
The omission of alignment has technically been wrong since 269bd5d8f61, where QEMU_ALIGNED was added to CPUTLBDescFast. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-09-29target/riscv: vector_helper: Fixup local variables shadowingAlistair Francis
Local variables shadowing other local variables or parameters make the code needlessly hard to understand. Bugs love to hide in such code. Evidence: "[PATCH v3 1/7] migration/rdma: Fix save_page method to fail on polling error". This patch removes the local variable shadowing. Tested by adding: --extra-cflags='-Wshadow=local -Wno-error=shadow=local -Wno-error=shadow=compatible-local' To configure Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925043023.71448-4-alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2023-09-29target/riscv: cpu: Fixup local variables shadowingAlistair Francis
Local variables shadowing other local variables or parameters make the code needlessly hard to understand. Bugs love to hide in such code. Evidence: "[PATCH v3 1/7] migration/rdma: Fix save_page method to fail on polling error". This patch removes the local variable shadowing. Tested by adding: --extra-cflags='-Wshadow=local -Wno-error=shadow=local -Wno-error=shadow=compatible-local' To configure Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925043023.71448-3-alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2023-09-11target/riscv: don't read CSR in riscv_csrrw_do64Nikita Shubin
As per ISA: "For CSRRWI, if rd=x0, then the instruction shall not read the CSR and shall not cause any of the side effects that might occur on a CSR read." trans_csrrwi() and trans_csrrw() call do_csrw() if rd=x0, do_csrw() calls riscv_csrrw_do64(), via helper_csrw() passing NULL as *ret_value. Signed-off-by: Nikita Shubin <n.shubin@yadro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230808090914.17634-1-nikita.shubin@maquefel.me> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Align the AIA model to v1.0 ratified specTommy Wu
According to the new spec, when vsiselect has a reserved value, attempts from M-mode or HS-mode to access vsireg, or from VS-mode to access sireg, should preferably raise an illegal instruction exception. Signed-off-by: Tommy Wu <tommy.wu@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230816061647.600672-1-tommy.wu@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv/pmp.c: respect mseccfg.RLB for pmpaddrX changesLeon Schuermann
When the rule-lock bypass (RLB) bit is set in the mseccfg CSR, the PMP configuration lock bits must not apply. While this behavior is implemented for the pmpcfgX CSRs, this bit is not respected for changes to the pmpaddrX CSRs. This patch ensures that pmpaddrX CSR writes work even on locked regions when the global rule-lock bypass is enabled. Signed-off-by: Leon Schuermann <leons@opentitan.org> Reviewed-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230829215046.1430463-1-leon@is.currently.online> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Allocate itrigger timers only onceAkihiko Odaki
riscv_trigger_init() had been called on reset events that can happen several times for a CPU and it allocated timers for itrigger. If old timers were present, they were simply overwritten by the new timers, resulting in a memory leak. Divide riscv_trigger_init() into two functions, namely riscv_trigger_realize() and riscv_trigger_reset() and call them in appropriate timing. The timer allocation will happen only once for a CPU in riscv_trigger_realize(). Fixes: 5a4ae64cac ("target/riscv: Add itrigger support when icount is enabled") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230818034059.9146-1-akihiko.odaki@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Use accelerated helper for AES64KS1IArd Biesheuvel
Use the accelerated SubBytes/ShiftRows/AddRoundKey AES helper to implement the first half of the key schedule derivation. This does not actually involve shifting rows, so clone the same value into all four columns of the AES vector to counter that operation. Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20230831154118.138727-1-ardb@kernel.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11hw/intc/riscv_aplic.c fix non-KVM --enable-debug buildDaniel Henrique Barboza
Commit 6df0b37e2ab breaks a --enable-debug build in a non-KVM environment with the following error: /usr/bin/ld: libqemu-riscv64-softmmu.fa.p/hw_intc_riscv_aplic.c.o: in function `riscv_kvm_aplic_request': ./qemu/build/../hw/intc/riscv_aplic.c:486: undefined reference to `kvm_set_irq' collect2: error: ld returned 1 exit status This happens because the debug build will poke into the 'if (is_kvm_aia(aplic->msimode))' block and fail to find a reference to the KVM only function riscv_kvm_aplic_request(). There are multiple solutions to fix this. We'll go with the same solution from the previous patch, i.e. add a kvm_enabled() conditional to filter out the block. But there's a catch: riscv_kvm_aplic_request() is a local function that would end up being used if the compiler crops the block, and this won't work. Quoting Richard Henderson's explanation in [1]: "(...) the compiler won't eliminate entire unused functions with -O0" We'll solve it by moving riscv_kvm_aplic_request() to kvm.c and add its declaration in kvm_riscv.h, where all other KVM specific public functions are already declared. Other archs handles KVM specific code in this manner and we expect to do the same from now on. [1] https://lore.kernel.org/qemu-riscv/d2f1ad02-eb03-138f-9d08-db676deeed05@linaro.org/ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20230830133503.711138-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11riscv: zicond: make non-experimentalVineet Gupta
zicond is now codegen supported in both llvm and gcc. This change allows seamless enabling/testing of zicond in downstream projects. e.g. currently riscv-gnu-toolchain parses elf attributes to create a cmdline for qemu but fails short of enabling it because of the "x-" prefix. Signed-off-by: Vineet Gupta <vineetg@rivosinc.com> Message-ID: <20230808181715.436395-1-vineetg@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: fix satp_mode_finalize() when satp_mode.supported = 0Daniel Henrique Barboza
In the same emulated RISC-V host, the 'host' KVM CPU takes 4 times longer to boot than the 'rv64' KVM CPU. The reason is an unintended behavior of riscv_cpu_satp_mode_finalize() when satp_mode.supported = 0, i.e. when cpu_init() does not set satp_mode_max_supported(). satp_mode_max_from_map(map) does: 31 - __builtin_clz(map) This means that, if satp_mode.supported = 0, satp_mode_supported_max wil be '31 - 32'. But this is C, so satp_mode_supported_max will gladly set it to UINT_MAX (4294967295). After that, if the user didn't set a satp_mode, set_satp_mode_default_map(cpu) will make cfg.satp_mode.map = cfg.satp_mode.supported So satp_mode.map = 0. And then satp_mode_map_max will be set to satp_mode_max_from_map(cpu->cfg.satp_mode.map), i.e. also UINT_MAX. The guard "satp_mode_map_max > satp_mode_supported_max" doesn't protect us here since both are UINT_MAX. And finally we have 2 loops: for (int i = satp_mode_map_max - 1; i >= 0; --i) { Which are, in fact, 2 loops from UINT_MAX -1 to -1. This is where the extra delay when booting the 'host' CPU is coming from. Commit 43d1de32f8 already set a precedence for satp_mode.supported = 0 in a different manner. We're doing the same here. If supported == 0, interpret as 'the CPU wants the OS to handle satp mode alone' and skip satp_mode_finalize(). We'll also put a guard in satp_mode_max_from_map() to assert out if map is 0 since the function is not ready to deal with it. Cc: Alexandre Ghiti <alexghiti@rivosinc.com> Fixes: 6f23aaeb9b ("riscv: Allow user to set the satp mode") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230817152903.694926-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Update CSR bits name for svadu extensionWeiwei Li
The Svadu specification updated the name of the *envcfg bit from HADE to ADUE. 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: <20230816141916.66898-1-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Create an KVM AIA irqchipYong-Xuan Wang
We create a vAIA chip by using the KVM_DEV_TYPE_RISCV_AIA and then set up the chip with the KVM_DEV_RISCV_AIA_GRP_* APIs. We also extend KVM accelerator to specify the KVM AIA mode. The "riscv-aia" parameter is passed along with --accel in QEMU command-line. 1) "riscv-aia=emul": IMSIC is emulated by hypervisor 2) "riscv-aia=hwaccel": use hardware guest IMSIC 3) "riscv-aia=auto": use the hardware guest IMSICs whenever available otherwise we fallback to software emulation. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230727102439.22554-4-yongxuan.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: check the in-kernel irqchip supportYong-Xuan Wang
We check the in-kernel irqchip support when using KVM acceleration. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230727102439.22554-3-yongxuan.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Fix zfa fleq.d and fltq.dLIU Zhiwei
Commit a47842d ("riscv: Add support for the Zfa extension") implemented the zfa extension. However, it has some typos for fleq.d and fltq.d. Both of them misused the fltq.s helper function. Fixes: a47842d ("riscv: Add support for the Zfa extension") Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Message-ID: <20230728003906.768-1-zhiwei_liu@linux.alibaba.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: Implement WARL behaviour for mcountinhibit/mcounterenRob Bradford
These are WARL fields - zero out the bits for unavailable counters and special case the TM bit in mcountinhibit which is hardwired to zero. This patch achieves this by modifying the value written so that any use of the field will see the correctly masked bits. Tested by modifying OpenSBI to write max value to these CSRs and upon subsequent read the appropriate number of bits for number of PMUs is enabled and the TM bit is zero in mcountinhibit. Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Message-ID: <20230802124906.24197-1-rbradford@rivosinc.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: Refactor some of the generic vector functionalityKiran Ostrolenk
Move some macros out of `vector_helper` and into `vector_internals`. This ensures they can be used by both vector and vector-crypto helpers (latter implemented in proceeding commits). Signed-off-by: Kiran Ostrolenk <kiran.ostrolenk@codethink.co.uk> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Max Chou <max.chou@sifive.com> Message-ID: <20230711165917.2629866-8-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Refactor translation of vector-widening instructionDickon Hood
Zvbb (implemented in later commit) has a widening instruction, which requires an extra check on the enabled extensions. Refactor GEN_OPIVX_WIDEN_TRANS() to take a check function to avoid reimplementing it. Signed-off-by: Dickon Hood <dickon.hood@codethink.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Max Chou <max.chou@sifive.com> Message-ID: <20230711165917.2629866-7-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Move vector translation checksNazar Kazakov
Move the checks out of `do_opiv{v,x,i}_gvec{,_shift}` functions and into the corresponding macros. This enables the functions to be reused in proceeding commits without check duplication. Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Max Chou <max.chou@sifive.com> Message-ID: <20230711165917.2629866-6-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-09-11target/riscv: Remove redundant "cpu_vl == 0" checksNazar Kazakov
Remove the redundant "vl == 0" check which is already included within the vstart >= vl check, when vl == 0. Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230711165917.2629866-4-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Refactor vector-vector translation macroKiran Ostrolenk
Refactor the non SEW-specific stuff out of `GEN_OPIVV_TRANS` into function `opivv_trans` (similar to `opivi_trans`). `opivv_trans` will be used in proceeding vector-crypto commits. Signed-off-by: Kiran Ostrolenk <kiran.ostrolenk@codethink.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Max Chou <max.chou@sifive.com> Message-ID: <20230711165917.2629866-3-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Refactor some of the generic vector functionalityKiran Ostrolenk
Take some functions/macros out of `vector_helper` and put them in a new module called `vector_internals`. This ensures they can be used by both vector and vector-crypto helpers (latter implemented in proceeding commits). Signed-off-by: Kiran Ostrolenk <kiran.ostrolenk@codethink.co.uk> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230711165917.2629866-2-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-16 06:15:01 +0000