aboutsummaryrefslogtreecommitdiff
path: root/target/riscv
AgeCommit message (Collapse)AuthorFilesLines
2025-03-04target/riscv/kvm: add extensions after 6.14-rc3 updateDaniel Henrique Barboza1-0/+3
Expose ziccrse, zabha and svvptc. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20250221153758.652078-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv/cpu.c: create flag for ziccrseDaniel Henrique Barboza3-1/+7
At this moment ziccrse is a TCG always enabled named feature for priv_ver > 1.11 that has no exclusive flag. In the next patch we'll make the KVM driver turn ziccrse off if the extension isn't available in the host, and we'll need an ext_ziccrse flag in the CPU state for that. Create an exclusive flag for it like we do with other named features. As with any named features we already have, it won't be exposed to users. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20250221153758.652078-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: Respect mseccfg.RLB bit for TOR mode PMP entryRob Bradford1-1/+1
When running in TOR mode (Top of Range) the next PMP entry controls whether the entry is locked. However simply checking if the PMP_LOCK bit is set is not sufficient with the Smepmp extension which now provides a bit (mseccfg.RLB (Rule Lock Bypass)) to disregard the lock bits. In order to respect this bit use the convenience pmp_is_locked() function rather than directly checking PMP_LOCK since this function checks mseccfg.RLB. Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20250210153713.343626-1-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: Add support to access ctrsource, ctrtarget, ctrdata regs.Rajnesh Kanwal3-2/+185
CTR entries are accessed using ctrsource, ctrtarget and ctrdata registers using smcsrind/sscsrind extension. This commits extends the csrind extension to support CTR registers. ctrsource is accessible through xireg CSR, ctrtarget is accessible through xireg1 and ctrdata is accessible through xireg2 CSR. CTR supports maximum depth of 256 entries which are accessed using xiselect range 0x200 to 0x2ff. This commits also adds properties to enable CTR extension. CTR can be enabled using smctr=true and ssctr=true now. Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250212-b4-ctr_upstream_v6-v7-1-4e8159ea33bf@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: remove warnings about Smdbltrp/Smrnmi being disabledClément Léger1-5/+3
As raised by Richard Henderson, these warnings are displayed in user only as well. Since they aren't really useful for the end-user, remove them and add a "TODO" note in the leading comments. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20250213145640.117275-1-cleger@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: Mask out upper sscofpmf bits during validationAtish Patra1-1/+1
As per the ISA definition, the upper 8 bits in hpmevent are defined by Sscofpmf for privilege mode filtering and overflow bits while the lower 56 bits are desginated for platform specific hpmevent values. For the reset case, mhpmevent value should have zero in lower 56 bits. Software may set the OF bit to indicate disable interrupt. Ensure that correct value is checked after masking while clearing the event encodings. Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Message-ID: <20250206-pmu_minor_fixes-v2-2-1bb0f4aeb8b4@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: Fix the hpmevent maskAtish Patra1-3/+2
As per the latest privilege specification v1.13[1], the sscofpmf only reserves first 8 bits of hpmeventX. Update the corresponding masks accordingly. [1]https://github.com/riscv/riscv-isa-manual/issues/1578 Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250206-pmu_minor_fixes-v2-1-1bb0f4aeb8b4@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: log guest errors when reserved bits are set in PTEsjulia1-1/+26
For instance, QEMUs newer than b6ecc63c569bb88c0fcadf79fb92bf4b88aefea8 would silently treat this akin to an unmapped page (as required by the RISC-V spec, admittedly). However, not all hardware platforms do (e.g. CVA6) which leads to an apparent QEMU bug. Instead, log a guest error so that in future, incorrectly set up page tables can be debugged without bisecting QEMU. Signed-off-by: julia <midnight@trainwit.ch> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20250203061852.2931556-1-midnight@trainwit.ch> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: machine: Add Control Transfer Record state descriptionRajnesh Kanwal1-0/+25
Add a subsection to machine.c to migrate CTR CSR state Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250205-b4-ctr_upstream_v6-v6-6-439d8e06c8ef@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: Add CTR sctrclr instruction.Rajnesh Kanwal6-0/+50
CTR extension adds a new instruction sctrclr to quickly clear the recorded entries buffer. Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250205-b4-ctr_upstream_v6-v6-5-439d8e06c8ef@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: Add support to record CTR entries.Rajnesh Kanwal8-0/+430
This commit adds logic to records CTR entries of different types and adds required hooks in TCG and interrupt/Exception logic to record events. This commit also adds support to invoke freeze CTR logic for breakpoint exceptions and counter overflow interrupts. Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250205-b4-ctr_upstream_v6-v6-4-439d8e06c8ef@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: Add support for Control Transfer Records extension CSRs.Rajnesh Kanwal3-0/+151
This commit adds support for [m|s|vs]ctrcontrol, sctrstatus and sctrdepth CSRs handling. Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250205-b4-ctr_upstream_v6-v6-3-439d8e06c8ef@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: Add Control Transfer Records CSR definitions.Rajnesh Kanwal1-0/+145
The Control Transfer Records (CTR) extension provides a method to record a limited branch history in register-accessible internal chip storage. This extension is similar to Arch LBR in x86 and BRBE in ARM. The Extension has been stable and the latest release can be found here https://github.com/riscv/riscv-control-transfer-records/releases/tag/v1.0_rc5 Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250205-b4-ctr_upstream_v6-v6-2-439d8e06c8ef@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: Remove obsolete sfence.vm instructionRajnesh Kanwal2-6/+0
Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Jason Chien <jason.chien@sifive.com> Message-ID: <20250205-b4-ctr_upstream_v6-v6-1-439d8e06c8ef@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: add RVA23S64 profileDaniel Henrique Barboza2-0/+40
Add RVA23S64 as described in [1]. This profile inherits all mandatory extensions of RVA23U64 and RVA22S64, making it a child of both profiles. A new "rva23s64" profile CPU is also added. This is the generated riscv,isa for it (taken via -M dumpdtb): rv64imafdcbvh_zic64b_zicbom_zicbop_zicboz_ziccamoa_ziccif_zicclsm_ ziccrse_zicond_zicntr_zicsr_zifencei_zihintntl_zihintpause_zihpm_zimop_ zmmul_za64rs_zaamo_zalrsc_zawrs_zfa_zfhmin_zca_zcb_zcd_zcmop_zba_zbb_zbs_ zkt_zvbb_zve32f_zve32x_zve64f_zve64d_zve64x_zvfhmin_zvkb_zvkt_shcounterenw_ sha_shgatpa_shtvala_shvsatpa_shvstvala_shvstvecd_smnpm_smstateen_ssccptr_ sscofpmf_sscounterenw_ssnpm_ssstateen_sstc_sstvala_sstvecd_ssu64xl_ supm_svade_svinval_svnapot_svpbmt [1] https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.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: <20250115184316.2344583-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: add RVA23U64 profileDaniel Henrique Barboza2-0/+34
Add RVA23U64 as described in [1]. Add it as a child of RVA22U64 since all RVA22U64 mandatory extensions are also present in RVA23U64. What's left then is to list the mandatory extensions that are RVA23 only. A new "rva23u64" CPU is also added. [1] https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.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: <20250115184316.2344583-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: change priv_ver check in validate_profile()Daniel Henrique Barboza1-1/+1
The S profiles do a priv_ver check during validation to see if the running priv_ver is compatible with it. This check is done by comparing if the running priv_ver is equal to the priv_ver the profile specifies. There is an universe where we added RVA23S64 support based on both RVA23U64 and RVA22S64 and this error is being thrown: qemu-system-riscv64: warning: Profile rva22s64 requires priv spec v1.12.0, but priv ver v1.13.0 was set We're enabling RVA22S64 (priv_ver 1.12) as a dependency of RVA23S64 (priv_ver 1.13) and complaining to users about what we did ourselves. There's no drawback in allowing a profile to run in an env that has a priv_ver newer than it's required by it. So, like Hiro Nakamura saves the future by changing the past, change the priv_ver check now to allow profiles to run in a newer priv_ver. This universe will have one less warning to deal with. 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: <20250115184316.2344583-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: add profile u_parent and s_parentDaniel Henrique Barboza3-12/+32
The current 'parent' mechanic for profiles allows for one profile to be a child of a previous/older profile, enabling all its extensions (and the parent profile itself) and sparing us from tediously listing all extensions for every profile. This works fine for u-mode profiles. For s-mode profiles this is not enough: a s-mode profile extends not only his equivalent u-mode profile but also the previous s-mode profile. This means, for example, that RVA23S64 extends both RVA23U64 and RVA22S64. To fit this usage, rename the existing 'parent' to 'u_parent' and add a new 's_parent' attribute for profiles. Handle both like we were doing with the previous 'parent' attribute, i.e. if set, enable it. This change does nothing for the existing profiles but will make RVA23S64 simpler. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20250115184316.2344583-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: use RVB in RVA22U64Daniel Henrique Barboza1-1/+1
From the time we added RVA22U64 until now the spec didn't declare 'RVB' as a dependency, using zba/zbb/zbs instead. Since then the RVA22 spec [1] added the following in the 'RVA22U64 Mandatory Extensions' section: "B Bit-manipulation instructions Note: The B extension comprises the Zba, Zbb, and Zbs extensions. At the time of RVA22U64's ratification, the B extension had not yet been defined, and so RVA22U64 explicitly mandated Zba, Zbb, and Zbs instead. Mandating B is equivalent." It is also equivalent to QEMU (see riscv_cpu_validate_b() in target/riscv/tcg/tcg-cpu.c). Finally, RVA23U64 [2] directly mentions RVB as a mandatory extension, not citing zba/zbb/zbs. To make it clear that RVA23U64 will extend RVA22U64 (i.e. RVA22 is a parent of RVA23), use RVB in RVA22U64 as well. (bios-tables-test change: RVB added to riscv,isa) [1] https://github.com/riscv/riscv-profiles/blob/main/src/profiles.adoc#61-rva22u64-profile [2] https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc#rva23u64-profile 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: <20250115184316.2344583-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: add ssu64xlDaniel Henrique Barboza1-0/+1
ssu64xl is defined in RVA22 as: "sstatus.UXL must be capable of holding the value 2 (i.e., UXLEN=64 must be supported)." This is always true in TCG and it's mandatory for RVA23, so claim support for it. 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: <20250115184316.2344583-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: throw debug exception before page faultDaniel Henrique Barboza1-0/+18
In the RISC-V privileged ISA section 3.1.15 table 15, it is determined that a debug exception that is triggered from a load/store has a higher priority than a possible fault that this access might trigger. This is not the case ATM as shown in [1]. Adding a breakpoint in an address that deliberately will fault is causing a load page fault instead of a debug exception. The reason is that we're throwing in the page fault as soon as the fault occurs (end of riscv_cpu_tlb_fill(), raise_mmu_exception()), not allowing the installed watchpoints to trigger. Call cpu_check_watchpoint() in the page fault path to search and execute any watchpoints that might exist for the address, never returning back to the fault path. If no watchpoints are found cpu_check_watchpoint() will return and we'll fall-through the regular path to raise_mmu_exception(). [1] https://gitlab.com/qemu-project/qemu/-/issues/2627 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2627 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: <20250121170626.1992570-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv/debug.c: use wp size = 4 for 32-bit CPUsDaniel Henrique Barboza1-2/+4
The mcontrol select bit (19) is always zero, meaning our triggers will always match virtual addresses. In this condition, if the user does not specify a size for the trigger, the access size defaults to XLEN. At this moment we're using def_size = 8 regardless of CPU XLEN. Use def_size = 4 in case we're running 32 bits. Fixes: 95799e36c1 ("target/riscv: Add initial support for the Sdtrig extension") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250121170626.1992570-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: rvv: Fix incorrect vlen comparison in prop_vlen_setMax Chou1-2/+3
In prop_vlen_set function, there is an incorrect comparison between vlen(bit) and vlenb(byte). This will cause unexpected error when user applies the `vlen=1024` cpu option with a vendor predefined cpu type that the default vlen is 1024(vlenb=128). Fixes: 4f6d036ccc ("target/riscv/cpu.c: remove cpu->cfg.vlen") Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20250124090539.2506448-1-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv: rvv: Fix unexpected behavior of vector reduction instructions ↵Max Chou1-2/+6
when vl is 0 According to the Vector Reduction Operations section in the RISC-V "V" Vector Extension spec, "If vl=0, no operation is performed and the destination register is not updated." The vd should be updated when vl is larger than 0. Fixes: fe5c9ab1fc ("target/riscv: vector single-width integer reduction instructions") Fixes: f714361ed7 ("target/riscv: rvv-1.0: implement vstart CSR") Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20250124101452.2519171-1-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv/cpu_helper.c: fix bad_shift in riscv_cpu_interrupt()Daniel Henrique Barboza1-1/+3
Coverity reported a BAD_SHIFT issue in the following code: > 2097 >>>> CID 1590355: Integer handling issues (BAD_SHIFT) >>>> In expression "hdeleg >> cause", right shifting by more than 63 bits has undefined behavior. The shift amount, "cause", is at least 64. > 2098 vsmode_exc = env->virt_enabled && (((hdeleg >> cause) & 1) || vs_injected); > 2099 /* It is not clear to me how the tool guarantees that '"cause" is at least 64', but indeed there's no guarantees that it would be < 64 in the 'async = true' code path. A simple fix to avoid a potential UB is to add a 'cause < 64' guard like 'mode' is already doing right before 'vsmode_exc'. Resolves: Coverity CID 1590355 Fixes: 967760f62c ("target/riscv: Implement Ssdbltrp exception handling") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250121184847.2109128-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv/csr.c: fix deadcode in aia_smode32()Daniel Henrique Barboza1-4/+0
Coverity reported a DEADCODE ticket in this function, as follows: >>>> CID 1590358: Control flow issues (DEADCODE) >>>> Execution cannot reach this statement: "return ret;". > 380 return ret; > 381 } The cause is that the 'if (ret != RISCV_EXCP_NONE)' conditional is duplicated: ret = smstateen_acc_ok(env, 0, SMSTATEEN0_AIA); if (ret != RISCV_EXCP_NONE) { return ret; } if (ret != RISCV_EXCP_NONE) { return ret; } Remove the duplication to fix the deadcode. Resolves: Coverity CID 1590358 Fixes: dbcb6e1ccf ("target/riscv: Enable S*stateen bits for AIA") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250121184847.2109128-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv/csr.c: fix deadcode in rmw_xiregi()Daniel Henrique Barboza1-7/+1
Coverity found a DEADCODE issue in rmw_xiregi() claiming that we can't reach 'RISCV_EXCP_VIRT_INSTRUCTION_FAULT' at the 'done' label: > 2652 done: >>>> CID 1590357: Control flow issues (DEADCODE) >>>> Execution cannot reach the expression "RISCV_EXCP_VIRT_INSTRUCTION_FAULT" inside this statement: "return (env->virt_enabled &...". > 2653 return (env->virt_enabled && virt) ? > 2654 RISCV_EXCP_VIRT_INSTRUCTION_FAULT : RISCV_EXCP_ILLEGAL_INST; This happens because 'virt' is being set to 'false' and it will remain as 'false' in any code path where 'done' will be called. The label can be safely reduced to: done: return RISCV_EXCP_ILLEGAL_INST; And that will leave us with the following usage of a 'goto' skipping a single 'return' to do another single 'return': } else { goto done; } return rmw_xireg_csrind(env, csrno, isel, val, new_val, wr_mask); done: return RISCV_EXCP_ILLEGAL_INST; Which we will eliminate it and just do 'return RISCV_EXCP_ILLEGAL_INST' instead. Resolves: Coverity CID 1590357 Fixes: 5e33a20827 ("target/riscv: Support generic CSR indirect access") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250121184847.2109128-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv/csr.c: fix 'ret' deadcode in rmw_xireg()Daniel Henrique Barboza1-6/+1
Coverity found a second DEADCODE issue in rmw_xireg() claiming that we can't reach 'RISCV_EXCP_NONE' at the 'done' label: > 2706 done: > 2707 if (ret) { > 2708 return (env->virt_enabled && virt) ? > 2709 RISCV_EXCP_VIRT_INSTRUCTION_FAULT : RISCV_EXCP_ILLEGAL_INST; > 2710 } >>>> CID 1590356: Control flow issues (DEADCODE) >>>> Execution cannot reach this statement: "return RISCV_EXCP_NONE;". > 2711 return RISCV_EXCP_NONE; Our label is now reduced after fixing another deadcode in the previous patch but the problem reported here still remains: done: if (ret) { return RISCV_EXCP_ILLEGAL_INST; } return RISCV_EXCP_NONE; This happens because 'ret' changes only once at the start of the function: ret = smstateen_acc_ok(env, 0, SMSTATEEN0_SVSLCT); if (ret != RISCV_EXCP_NONE) { return ret; } So it's a guarantee that ret will be RISCV_EXCP_NONE (-1) if we ever reach the label, i.e. "if (ret)" will always be true, and the label can be even further reduced to: done: return RISCV_EXCP_ILLEGAL_INST; To make a better use of the label, remove the 'else' from the xiselect_aia_range() chain and let it fall-through to the 'done' label since they are now both returning RISCV_EXCP_ILLEGAL_INST. Resolves: Coverity CID 1590356 Fixes: dc0280723d ("target/riscv: Decouple AIA processing from xiselect and xireg") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250121184847.2109128-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv/csr.c: fix deadcode in rmw_xireg()Daniel Henrique Barboza1-5/+2
Coverity found a DEADCODE issue in rmw_xireg() claiming that we can't reach 'RISCV_EXCP_VIRT_INSTRUCTION_FAULT' at the 'done' label: done: if (ret) { return (env->virt_enabled && virt) ? RISCV_EXCP_VIRT_INSTRUCTION_FAULT : RISCV_EXCP_ILLEGAL_INST; } return RISCV_EXCP_NONE; This happens because the 'virt' flag, which is only used by 'done', is set to 'false' and it will always remain 'false' in any condition where we'll jump to 'done': switch (csrno) { (...) case CSR_VSIREG: isel = env->vsiselect; virt = true; break; default: goto done; }; 'virt = true' will never reach 'done' because we have a if/else-if/else block right before the label that will always return: if (xiselect_aia_range(isel)) { return ... } else if (...) { return ... } else { return RISCV_EXCP_ILLEGAL_INST; } All this means that we can preserve the current logic by reducing the 'done' label to: done: if (ret) { return RISCV_EXCP_ILLEGAL_INST; } return RISCV_EXCP_NONE; The flag 'virt' is now unused. Remove it. Fix the 'goto done' identation while we're at it. Resolves: Coverity CID 1590359 Fixes: dc0280723d ("target/riscv: Decouple AIA processing from xiselect and xireg") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250121184847.2109128-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-02-25target/riscv: move 128-bit check to TCG realizePaolo Bonzini2-7/+9
Besides removing non-declarative code in instance_init, this also fixes an issue with query-cpu-model-expansion. Just invoking it for the x-rv128 CPU model causes QEMU to exit immediately. With this patch it is possible to do {'execute': 'query-cpu-model-expansion', 'arguments':{'type': 'full', 'model': {'name': 'x-rv128'}}} Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-02-25target/riscv: remove unused macro DEFINE_CPUPaolo Bonzini1-9/+0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-02-18tcg: Remove TCG_OVERSIZED_GUESTRichard Henderson1-12/+1
This is now prohibited in configuration. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-02-14target/riscv: Fix minor whitespace issue in riscv_cpu_propertiesRob Bradford1-3/+3
The mvendorid/mimpid/marchid properties have the wrong amount of whitespace ahead of them. Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2025-02-10Merge tag 'pull-qapi-2025-02-10-v2' of https://repo.or.cz/qemu/armbru into ↵Stefan Hajnoczi1-2/+2
staging QAPI patches patches for 2025-02-10 # -----BEGIN PGP SIGNATURE----- # # iQJGBAABCAAwFiEENUvIs9frKmtoZ05fOHC0AOuRhlMFAmeqEXESHGFybWJydUBy # ZWRoYXQuY29tAAoJEDhwtADrkYZTaOEP/2VYKkb2VzPdWzyQcEx66MJ+1RjcEy1A # JtD6mTdpEuti5NgrUUOSHjrd6P3DVNZL8SMPD21F4/I1t0u+ztfCtx65YKrKo8hV # jCnYS5w2i/YT3Cpz052yEhUoPgxj4kQiR3gqbLkpBKV7lh6wZ3+gVTNW8DJzPW/R # MmE9vkOCLhjmkodxRiVa7df73qMEm4nfbmQjM9SWBU55AC2xElptjJo0Sc7sMT3n # HdoLjXKfjUCIpmI3LfbRvS3Tyxd9gQn/la2yf3gaXJ0qrbP4xyu5VCzAOla5myuC # XyakLUu9DOsfNuHXvKX+M8jE7pf6wibLMfVhPigACob2LAa4Zo7LvCKqjhclTNhK # +/PvTGrirnGweNWXz5/2tG97F7oSzX2m182LyuloQbaehXAtpAuHehSCQUet6HOu # CEUOeV7D13nxcgxXT1GvQIqsTYRtIJvY8DM3tRoCAzDv/KNdXF4M/ybtUHmyHUkg # kspwCRfQJ1sNRdmj7oBtmWvvbYBk/zKvt84yOQZFYocmofp18KVLDN+hzEAHvHQE # 4t8yCktjrGGC0bCgIaQkBaeU7nxMWXBOOlYcejnXTR4VPTDTRKMAosmAotcd9d5H # QgGjcMhbDPJHavi36JdJQgxuwl4LskwLCdenBfXhmH8ePIWhjIqqzcdDJy0UcH0x # pX8L/Jsd42qD # =jFK8 # -----END PGP SIGNATURE----- # gpg: Signature made Mon 10 Feb 2025 09:47:13 EST # gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653 # gpg: issuer "armbru@redhat.com" # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * tag 'pull-qapi-2025-02-10-v2' of https://repo.or.cz/qemu/armbru: qapi: expose all schema features to code qapi: rename 'special_features' to 'features' qapi: change 'unsigned special_features' to 'uint64_t features' qapi: cope with feature names containing a '-' qapi/ui: Fix documentation of upper bound value in InputMoveEvent qapi: fix colon in Since tag section qapi: Move and rename qapi/qmp/dispatch.h to qapi/qmp-registry.h qapi: Move include/qapi/qmp/ to include/qobject/ Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-02-10qapi: Move include/qapi/qmp/ to include/qobject/Daniel P. Berrangé1-2/+2
The general expectation is that header files should follow the same file/path naming scheme as the corresponding source file. There are various historical exceptions to this practice in QEMU, with one of the most notable being the include/qapi/qmp/ directory. Most of the headers there correspond to source files in qobject/. This patch corrects most of that inconsistency by creating include/qobject/ and moving the headers for qobject/ there. This also fixes MAINTAINERS for include/qapi/qmp/dispatch.h: scripts/get_maintainer.pl now reports "QAPI" instead of "No maintainers found". Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> #s390x Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20241118151235.2665921-2-armbru@redhat.com> [Rebased]
2025-02-08target/*: Remove TARGET_LONG_BITS from cpu-param.hRichard Henderson1-2/+0
This is now handled by the configs/targets/*.mak fragment. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2025-01-19target/riscv: Support Supm and Sspm as part of Zjpm v1.0Alexey Baturo2-0/+25
The Zjpm v1.0 spec states there should be Supm and Sspm extensions that are used in profile specification. Enabling Supm extension enables both Ssnpm and Smnpm, while Sspm enables only Smnpm. Signed-off-by: Alexey Baturo <baturo.alexey@gmail.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20250113194410.1307494-1-baturo.alexey@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-01-19target/riscv: Add Smdbltrp ISA extension enable switchClément Léger2-0/+12
Add the switch to enable the Smdbltrp ISA extension and disable it for the max cpu. Indeed, OpenSBI when Smdbltrp is present, M-mode double trap is enabled by default and MSTATUS.MDT needs to be cleared to avoid taking a double trap. OpenSBI does not currently support it so disable it for the max cpu to avoid breaking regression tests. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20250116131539.2475785-1-cleger@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-01-19target/riscv: Implement Smdbltrp behaviorClément Léger1-16/+41
When the Smsdbltrp ISA extension is enabled, if a trap happens while MSTATUS.MDT is already set, it will trigger an abort or an NMI is the Smrnmi extension is available. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250110125441.3208676-9-cleger@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-01-19target/riscv: Implement Smdbltrp sret, mret and mnret behaviorClément Léger1-0/+12
When the Ssdbltrp extension is enabled, SSTATUS.MDT field is cleared when executing sret if executed in M-mode. When executing mret/mnret, SSTATUS.MDT is cleared. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250110125441.3208676-8-cleger@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-01-19target/riscv: Add Smdbltrp CSRs handlingClément Léger4-0/+18
Add `ext_smdbltrp`in RISCVCPUConfig and implement MSTATUS.MDT behavior. Also set MDT to 1 at reset according to the specification. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250110125441.3208676-7-cleger@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-01-19target/riscv: Add Ssdbltrp ISA extension enable switchClément Léger1-0/+2
Add the switch to enable the Ssdbltrp ISA extension. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250110125441.3208676-6-cleger@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-01-19target/riscv: Implement Ssdbltrp exception handlingClément Léger3-6/+39
When the Ssdbltrp ISA extension is enabled, if a trap happens in S-mode while SSTATUS.SDT isn't cleared, generate a double trap exception to M-mode. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250110125441.3208676-5-cleger@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-01-19target/riscv: Implement Ssdbltrp sret, mret and mnret behaviorClément Léger1-1/+34
When the Ssdbltrp extension is enabled, SSTATUS.SDT field is cleared when executing sret. When executing mret/mnret, SSTATUS.SDT is cleared when returning to U, VS or VU and VSSTATUS.SDT is cleared when returning to VU from HS. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250110125441.3208676-4-cleger@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-01-19target/riscv: Add Ssdbltrp CSRs handlingClément Léger5-12/+84
Add ext_ssdbltrp in RISCVCPUConfig and implement MSTATUS.SDT, {H|M}ENVCFG.DTE and modify the availability of MTVAL2 based on the presence of the Ssdbltrp ISA extension. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250110125441.3208676-3-cleger@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-01-19target/riscv: Fix henvcfg potentially containing stale bitsClément Léger1-2/+8
With the current implementation, if we had the following scenario: - Set bit x in menvcfg - Set bit x in henvcfg - Clear bit x in menvcfg then, the internal variable env->henvcfg would still contain bit x due to both a wrong menvcfg mask used in write_henvcfg() as well as a missing update of henvcfg upon menvcfg update. This can lead to some wrong interpretation of the context. In order to update henvcfg upon menvcfg writing, call write_henvcfg() after writing menvcfg. Clearing henvcfg upon writing the new value is also needed in write_henvcfg() as well as clearing henvcfg upper part when writing it with write_henvcfgh(). Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250110125441.3208676-2-cleger@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-01-19target/riscv: Add configuration for S[m|s]csrind, Smcdeleg/SsccfgAtish Patra1-0/+4
Add configuration options so that they can be enabled/disabld from qemu commandline. Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Message-ID: <20250110-counter_delegation-v5-11-e83d797ae294@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-01-19target/riscv: Add implied rule for counter delegation extensionsAtish Patra1-1/+11
The counter delegation/configuration extensions depend on the following extensions. 1. Smcdeleg - To enable counter delegation from M to S 2. S[m|s]csrind - To enable indirect access CSRs Add an implied rule so that these extensions are enabled by default if the sscfg extension is enabled. Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Message-ID: <20250110-counter_delegation-v5-10-e83d797ae294@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-01-19target/riscv: Invoke pmu init after feature enableAtish Patra1-14/+14
The dependant ISA features are enabled at the end of cpu_realize in finalize_features. Thus, PMU init should be invoked after that only. Move the init invocation to riscv_tcg_cpu_finalize_features. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Message-ID: <20250110-counter_delegation-v5-9-e83d797ae294@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-01-19target/riscv: Add counter delegation/configuration supportKaiwen Xue1-12/+292
The Smcdeleg/Ssccfg adds the support for counter delegation via S*indcsr and Ssccfg. It also adds a new shadow CSR scountinhibit and menvcfg enable bit (CDE) to enable this extension and scountovf virtualization. Signed-off-by: Kaiwen Xue <kaiwenx@rivosinc.com> Co-developed-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Message-ID: <20250110-counter_delegation-v5-8-e83d797ae294@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
generated by cgit v1.1 at 2025-09-20 02:35:21 +0000