aboutsummaryrefslogtreecommitdiff
path: root/target/riscv
AgeCommit message (Collapse)Author
2024-06-05target/riscv/kvm.c: Fix the hart bit setting of AIAYong-Xuan Wang
In AIA spec, each hart (or each hart within a group) has a unique hart number to locate the memory pages of interrupt files in the address space. The number of bits required to represent any hart number is equal to ceil(log2(hmax + 1)), where hmax is the largest hart number among groups. However, if the largest hart number among groups is a power of 2, QEMU will pass an inaccurate hart-index-bit setting to Linux. For example, when the guest OS has 4 harts, only ceil(log2(3 + 1)) = 2 bits are sufficient to represent 4 harts, but we passes 3 to Linux. The code needs to be updated to ensure accurate hart-index-bit settings. Additionally, a Linux patch[1] is necessary to correctly recover the hart index when the guest OS has only 1 hart, where the hart-index-bit is 0. [1] https://lore.kernel.org/lkml/20240415064905.25184-1-yongxuan.wang@sifive.com/t/ Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Cc: qemu-stable <qemu-stable@nongnu.org> Message-ID: <20240515091129.28116-1-yongxuan.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 190b867f28cb5781f3cd01a3deb371e4211595b1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-06-05target/riscv: rvzicbo: Fixup CBO extension register calculationAlistair Francis
When running the instruction ``` cbo.flush 0(x0) ``` QEMU would segfault. The issue was in cpu_gpr[a->rs1] as QEMU does not have cpu_gpr[0] allocated. In order to fix this let's use the existing get_address() helper. This also has the benefit of performing pointer mask calculations on the address specified in rs1. The pointer masking specificiation specifically states: """ Cache Management Operations: All instructions in Zicbom, Zicbop and Zicboz """ So this is the correct behaviour and we previously have been incorrectly not masking the address. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reported-by: Fabian Thomas <fabian.thomas@cispa.de> Fixes: e05da09b7cfd ("target/riscv: implement Zicbom extension") Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Cc: qemu-stable <qemu-stable@nongnu.org> Message-ID: <20240514023910.301766-1-alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit c5eb8d6336741dbcb98efcc347f8265bf60bc9d1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-06-05target/riscv: do not set mtval2 for non guest-page faultsAlexei Filippov
Previous patch fixed the PMP priority in raise_mmu_exception() but we're still setting mtval2 incorrectly. In riscv_cpu_tlb_fill(), after pmp check in 2 stage translation part, mtval2 will be set in case of successes 2 stage translation but failed pmp check. In this case we gonna set mtval2 via env->guest_phys_fault_addr in context of riscv_cpu_tlb_fill(), as this was a guest-page-fault, but it didn't and mtval2 should be zero, according to RISCV privileged spec sect. 9.4.4: When a guest page-fault is taken into M-mode, mtval2 is written with either zero or guest physical address that faulted, shifted by 2 bits. *For other traps, mtval2 is set to zero...* Signed-off-by: Alexei Filippov <alexei.filippov@syntacore.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240503103052.6819-1-alexei.filippov@syntacore.com> Cc: qemu-stable <qemu-stable@nongnu.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 6c9a344247132ac6c3d0eb9670db45149a29c88f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-06-05target/riscv: prioritize pmp errors in raise_mmu_exception()Daniel Henrique Barboza
raise_mmu_exception(), as is today, is prioritizing guest page faults by checking first if virt_enabled && !first_stage, and then considering the regular inst/load/store faults. There's no mention in the spec about guest page fault being a higher priority that PMP faults. In fact, privileged spec section 3.7.1 says: "Attempting to fetch an instruction from a PMP region that does not have execute permissions raises an instruction access-fault exception. Attempting to execute a load or load-reserved instruction which accesses a physical address within a PMP region without read permissions raises a load access-fault exception. Attempting to execute a store, store-conditional, or AMO instruction which accesses a physical address within a PMP region without write permissions raises a store access-fault exception." So, in fact, we're doing it wrong - PMP faults should always be thrown, regardless of also being a first or second stage fault. The way riscv_cpu_tlb_fill() and get_physical_address() work is adequate: a TRANSLATE_PMP_FAIL error is immediately reported and reflected in the 'pmp_violation' flag. What we need is to change raise_mmu_exception() to prioritize it. Reported-by: Joseph Chan <jchan@ventanamicro.com> Fixes: 82d53adfbb ("target/riscv/cpu_helper.c: Invalid exception on MMU translation stage") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240413105929.7030-1-alexei.filippov@syntacore.com> Cc: qemu-stable <qemu-stable@nongnu.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 68e7c86927afa240fa450578cb3a4f18926153e4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-06-05target/riscv: rvv: Remove redudant SEW checking for vector fp narrow/widen ↵Max Chou
instructions If the checking functions check both the single and double width operators at the same time, then the single width operator checking functions (require_rvf[min]) will check whether the SEW is 8. Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Cc: qemu-stable <qemu-stable@nongnu.org> Message-ID: <20240322092600.1198921-5-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 93cb52b7a3ccc64e8d28813324818edae07e21d5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-06-05target/riscv: rvv: Check single width operator for vfncvt.rod.f.f.wMax Chou
The opfv_narrow_check needs to check the single width float operator by require_rvf. Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Cc: qemu-stable <qemu-stable@nongnu.org> Message-ID: <20240322092600.1198921-4-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 692f33a3abcaae789b08623e7cbdffcd2c738c89) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-06-05target/riscv: rvv: Check single width operator for vector fp widen instructionsMax Chou
The require_scale_rvf function only checks the double width operator for the vector floating point widen instructions, so most of the widen checking functions need to add require_rvf for single width operator. The vfwcvt.f.x.v and vfwcvt.f.xu.v instructions convert single width integer to double width float, so the opfxv_widen_check function doesn’t need require_rvf for the single width operator(integer). Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Cc: qemu-stable <qemu-stable@nongnu.org> Message-ID: <20240322092600.1198921-3-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 7a999d4dd704aa71fe6416871ada69438b56b1e5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-06-05target/riscv: rvv: Fix Zvfhmin checking for vfwcvt.f.f.v and vfncvt.f.f.w ↵Max Chou
instructions According v spec 18.4, only the vfwcvt.f.f.v and vfncvt.f.f.w instructions will be affected by Zvfhmin extension. And the vfwcvt.f.f.v and vfncvt.f.f.w instructions only support the conversions of * From 1*SEW(16/32) to 2*SEW(32/64) * From 2*SEW(32/64) to 1*SEW(16/32) Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Cc: qemu-stable <qemu-stable@nongnu.org> Message-ID: <20240322092600.1198921-2-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 17b713c0806e72cd8edc6c2ddd8acc5be0475df6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-06-05target/riscv/cpu.c: fix Zvkb extension configYangyu Chen
This code has a typo that writes zvkb to zvkg, causing users can't enable zvkb through the config. This patch gets this fixed. Signed-off-by: Yangyu Chen <cyy@cyyself.name> Fixes: ea61ef7097d0 ("target/riscv: Move vector crypto extensions to riscv_cpu_extensions") Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Max Chou <max.chou@sifive.com> Reviewed-by:  Weiwei Li <liwei1518@gmail.com> Message-ID: <tencent_7E34EEF0F90B9A68BF38BEE09EC6D4877C0A@qq.com> Cc: qemu-stable <qemu-stable@nongnu.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit ff33b7a9699e977a050a1014c617a89da1bf8295) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-06-05target/riscv: Fix the element agnostic function problemHuang Tao
In RVV and vcrypto instructions, the masked and tail elements are set to 1s using vext_set_elems_1s function if the vma/vta bit is set. It is the element agnostic policy. However, this function can't deal the big endian situation. This patch fixes the problem by adding handling of such case. Signed-off-by: Huang Tao <eric.huang@linux.alibaba.com> Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Cc: qemu-stable <qemu-stable@nongnu.org> Message-ID: <20240325021654.6594-1-eric.huang@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 75115d880c6d396f8a2d56aab8c12236d85a90e0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-06-05target/riscv/kvm: tolerate KVM disable ext errorsDaniel Henrique Barboza
Running a KVM guest using a 6.9-rc3 kernel, in a 6.8 host that has zkr enabled, will fail with a kernel oops SIGILL right at the start. The reason is that we can't expose zkr without implementing the SEED CSR. Disabling zkr in the guest would be a workaround, but if the KVM doesn't allow it we'll error out and never boot. In hindsight this is too strict. If we keep proceeding, despite not disabling the extension in the KVM vcpu, we'll not add the extension in the riscv,isa. The guest kernel will be unaware of the extension, i.e. it doesn't matter if the KVM vcpu has it enabled underneath or not. So it's ok to keep booting in this case. Change our current logic to not error out if we fail to disable an extension in kvm_set_one_reg(), but show a warning and keep booting. It is important to throw a warning because we must make the user aware that the extension is still available in the vcpu, meaning that an ill-behaved guest can ignore the riscv,isa settings and use the extension. The case we're handling happens with an EINVAL error code. If we fail to disable the extension in KVM for any other reason, error out. We'll also keep erroring out when we fail to enable an extension in KVM, since adding the extension in riscv,isa at this point will cause a guest malfunction because the extension isn't enabled in the vcpu. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Cc: qemu-stable <qemu-stable@nongnu.org> Message-ID: <20240422171425.333037-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 1215d45b2aa97512a2867e401aa59f3d0c23cb23) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-27target/riscv/kvm: change timer regs size to u64Daniel Henrique Barboza
KVM_REG_RISCV_TIMER regs are always u64 according to the KVM API, but at this moment we'll return u32 regs if we're running a RISCV32 target. Use the kvm_riscv_reg_id_u64() helper in RISCV_TIMER_REG() to fix it. Reported-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231208183835.2411523-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 10f86d1b845087d14b58d65dd2a6e3411d1b6529) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-27target/riscv/kvm: change KVM_REG_RISCV_FP_D to u64Daniel Henrique Barboza
KVM_REG_RISCV_FP_D regs are always u64 size. Using kvm_riscv_reg_id() in RISCV_FP_D_REG() ends up encoding the wrong size if we're running with TARGET_RISCV32. Create a new helper that returns a KVM ID with u64 size and use it with RISCV_FP_D_REG(). Reported-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231208183835.2411523-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 450bd6618fda3d2e2ab02b2fce1c79efd5b66084) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-04-27target/riscv/kvm: change KVM_REG_RISCV_FP_F to u32Daniel Henrique Barboza
KVM_REG_RISCV_FP_F regs have u32 size according to the API, but by using kvm_riscv_reg_id() in RISCV_FP_F_REG() we're returning u64 sizes when running with TARGET_RISCV64. The most likely reason why no one noticed this is because we're not implementing kvm_cpu_synchronize_state() in RISC-V yet. Create a new helper that returns a KVM ID with u32 size and use it in RISCV_FP_F_REG(). Reported-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231208183835.2411523-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 49c211ffca00fdf7c0c29072c224e88527a14838) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-27target/riscv/kvm: fix timebase-frequency when using KVM accelerationYong-Xuan Wang
The timebase-frequency of guest OS should be the same with host machine. The timebase-frequency value in DTS should be got from hypervisor when using KVM acceleration. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Message-ID: <20240314061510.9800-1-yongxuan.wang@sifive.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 385e575cd5ab2436c123e4b7f8c9b383a64c0dbe) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fix due to missing other changes in this area in 8.2.x)
2024-03-27target/riscv: Fix mode in riscv_tlb_fillIrina Ryapolova
Need to convert mmu_idx to privilege mode for PMP function. Signed-off-by: Irina Ryapolova <irina.ryapolova@syntacore.com> Fixes: b297129ae1 ("target/riscv: propagate PMP permission to TLB page") Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240320172828.23965-1-irina.ryapolova@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit e06adebb08325c39e4c9b652139426c10f021abb) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-27target/riscv: rvv: Remove the dependency of Zvfbfmin to ZfbfminMax Chou
According to the Zvfbfmin definition in the RISC-V BF16 extensions spec, the Zvfbfmin extension only requires either the V extension or the Zve32f extension. Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240321170929.1162507-1-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit c9b07fe14d3525cd3f2fc01f46eeb3d4ed7c3603) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-27target/riscv/vector_helper.c: optimize loops in ldst helpersDaniel Henrique Barboza
Change the for loops in ldst helpers to do a single increment in the counter, and assign it env->vstart, to avoid re-reading from vstart every time. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240314175704.478276-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 0a11629c915f61df798919db51a18ffe4649cb65) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-27target/riscv/vector_helpers: do early exit when vstart >= vlDaniel Henrique Barboza
We're going to make changes that will required each helper to be responsible for the 'vstart' management, i.e. we will relieve the 'vstart < vl' assumption that helpers have today. Helpers are usually able to deal with vstart >= vl, i.e. doing nothing aside from setting vstart = 0 at the end, but the tail update functions will update the tail regardless of vstart being valid or not. Unifying the tail update process in a single function that would handle the vstart >= vl case isn't trivial (see [1] for more info). This patch takes a blunt approach: do an early exit in every single vector helper if vstart >= vl, unless the helper is guarded with vstart_eq_zero in the translation. For those cases the helper is ready to deal with cases where vl might be zero, i.e. throwing exceptions based on it like vcpop_m() and first_m(). Helpers that weren't changed: - vcpop_m(), vfirst_m(), vmsetm(), GEN_VEXT_VIOTA_M(): these are guarded directly with vstart_eq_zero; - GEN_VEXT_VCOMPRESS_VM(): guarded with vcompress_vm_check() that checks vstart_eq_zero; - GEN_VEXT_RED(): guarded with either reduction_check() or reduction_widen_check(), both check vstart_eq_zero; - GEN_VEXT_FRED(): guarded with either freduction_check() or freduction_widen_check(), both check vstart_eq_zero. Another exception is vext_ldst_whole(), who operates on effective vector length regardless of the current settings in vtype and vl. [1] https://lore.kernel.org/qemu-riscv/1590234b-0291-432a-a0fa-c5a6876097bc@linux.alibaba.com/ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240314175704.478276-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit df4252b2ecaf93b601109373a17427d1867046e8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-27target/riscv: always clear vstart in whole vec move insnsDaniel Henrique Barboza
These insns have 2 paths: we'll either have vstart already cleared if vstart_eq_zero or we'll do a brcond to check if vstart >= maxsz to call the 'vmvr_v' helper. The helper will clear vstart if it executes until the end, or if vstart >= vl. For starters, the check itself is wrong: we're checking vstart >= maxsz, when in fact we should use vstart in bytes, or 'startb' like 'vmvr_v' is calling, to do the comparison. But even after fixing the comparison we'll still need to clear vstart in the end, which isn't happening too. We want to make the helpers responsible to manage vstart, including these corner cases, precisely to avoid these situations: - remove the wrong vstart >= maxsz cond from the translation; - add a 'startb >= maxsz' cond in 'vmvr_v', and clear vstart if that happens. This way we're now sure that vstart is being cleared in the end of the execution, regardless of the path taken. Fixes: f714361ed7 ("target/riscv: rvv-1.0: implement vstart CSR") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240314175704.478276-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 7e53e3ddf6dff200098e112c5370ab16d2d5dbd1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-27target/riscv/vector_helper.c: fix 'vmvr_v' memcpy endianessDaniel Henrique Barboza
vmvr_v isn't handling the case where the host might be big endian and the bytes to be copied aren't sequential. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Fixes: f714361ed7 ("target/riscv: rvv-1.0: implement vstart CSR") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240314175704.478276-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 768e7b329c0be22035da077fe76221dd0a47103b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-27trans_rvv.c.inc: set vstart = 0 in int scalar move insnsDaniel Henrique Barboza
trans_vmv_x_s, trans_vmv_s_x, trans_vfmv_f_s and trans_vfmv_s_f aren't setting vstart = 0 after execution. This is usually done by a helper in vector_helper.c but these functions don't use helpers. We'll set vstart after any potential 'over' brconds, and that will also mandate a mark_vs_dirty() too. Fixes: dedc53cbc9 ("target/riscv: rvv-1.0: integer scalar move instructions") 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: <20240314175704.478276-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 0848f7c18ef50de9f955e7eeb4363d92766a41bf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-03-27target/riscv/vector_helper.c: set vstart = 0 in GEN_VEXT_VSLIDEUP_VX()Daniel Henrique Barboza
The helper isn't setting env->vstart = 0 after its execution, as it is expected from every vector instruction that completes successfully. 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> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Message-ID: <20240314175704.478276-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit d3646e31ce6d1e02e46e6eabdbc2e637c0cbece7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-08target/riscv: Fix mcycle/minstret increment behaviorXu Lu
The mcycle/minstret counter's stop flag is mistakenly updated on a copy on stack. Thus the counter increments even when the CY/IR bit in the mcountinhibit register is set. This commit corrects its behavior. Fixes: 3780e33732f88 (target/riscv: Support mcycle/minstret write operation) Signed-off-by: Xu Lu <luxu.kernel@bytedance.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 5cb0e7abe1635cb82e0033260dac2b910d142f8c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-12-26target/riscv/kvm: do not use non-portable strerrorname_np()Natanael Copa
strerrorname_np is non-portable and breaks building with musl libc. Use strerror(errno) instead, like we do other places. Cc: qemu-stable@nongnu.org Fixes: commit 082e9e4a58ba (target/riscv/kvm: improve 'init_multiext_cfg' error msg) Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2041 Buglink: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15541 Signed-off-by: Natanael Copa <ncopa@alpinelinux.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit d424db235434b8356c6b2d9420b846c7ddcc83ea)
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>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-13 06:07:38 +0000