summary refs log tree commit diff stats
path: root/docs/sphinx/dbusparser.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2025-03-04hw/riscv: add IOMMU HPM trace eventsDaniel Henrique Barboza2-0/+15
Add a handful of trace events to allow for an easier time debugging the HPM feature. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250224190826.1858473-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04hw/riscv/riscv-iommu.c: add RISCV_IOMMU_CAP_HPM capTomasz Jeznach1-0/+21
Now that we have every piece in place we can advertise CAP_HTM to software, allowing any HPM aware driver to make use of the counters. HPM is enabled/disabled via the 'hpm-counters' attribute. Default value is 31, max value is also 31. Setting it to zero will disable HPM support. Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250224190826.1858473-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04hw/riscv/riscv-iommu: add hpm events mmio writeTomasz Jeznach4-1/+93
To support hpm events mmio writes, done via riscv_iommu_process_hpmevt_write(), we're also adding the 'hpm-counters' IOMMU property that are used to determine the amount of counters available in the IOMMU. Note that everything we did so far didn't change any IOMMU behavior because we're still not advertising HPM capability to software. This will be done in the next patch. Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250224190826.1858473-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04hw/riscv/riscv-iommu: add IOHPMCYCLES mmio writeTomasz Jeznach3-1/+21
RISCV_IOMMU_REG_IOHPMCYCLES writes are done by riscv_iommu_process_hpmcycle_write(), called by the mmio write callback via riscv_iommu_process_hpm_writes(). Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250224190826.1858473-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04hw/riscv/riscv-iommu: add IOCOUNTINH mmio writesTomasz Jeznach3-0/+99
RISCV_IOMMU_REG_IOCOUNTINH is done by riscv_iommu_process_iocntinh_cy(), which is called during riscv_iommu_mmio_write() callback via a new riscv_iommu_pricess_hpm_writes() helper. Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250224190826.1858473-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04hw/riscv/riscv-iommu: instantiate hpm_timerTomasz Jeznach4-0/+42
The next HPM related changes requires the HPM overflow timer to be initialized by the riscv-iommu base emulation. Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250224190826.1858473-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04hw/riscv/riscv-iommu: add riscv_iommu_hpm_incr_ctr()Tomasz Jeznach4-15/+162
This function will increment a specific counter, generating an interrupt when an overflow occurs. Some extra changes in riscv-iommu.c were required to add this new helper in riscv-iommu-hpm.c: - RISCVIOMMUContext was moved to riscv-iommu.h, making it visible in riscv-iommu-hpm.c; - riscv_iommu_notify() is now public. No behavior change is made since HPM support is not being advertised yet. Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250224190826.1858473-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04hw/riscv/riscv-iommu: add riscv-iommu-hpm fileTomasz Jeznach5-2/+110
The HPM (Hardware Performance Monitor) support consists of almost 7 hundred lines that would be put on top of the base riscv-iommu emulation. To avoid clogging riscv-iommu.c, add a separated riscv-iommu-hpm file that will contain HPM specific code. We'll start by adding riscv_iommu_hpmcycle_read(), a helper that will be called during the riscv_iommu_mmio_read() callback. This change will have no effect on the existing emulation since we're not declaring HPM feature support. Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250224190826.1858473-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04hw/riscv/riscv-iommu-bits.h: HPM bitsTomasz Jeznach1-0/+47
Add the relevant HPM (High Performance Monitor) bits that we'll be using in the next patches. Signed-off-by: Tomasz Jeznach <tjeznach@rivosinc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250224190826.1858473-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04hw/riscv/riscv-iommu.h: add missing headersDaniel Henrique Barboza1-0/+2
This header is incomplete, i.e. it is using definitions that are being supplied by the .c files that are including it. Adding this header into a fresh .c file will result in errors: /home/danielhb/work/qemu/hw/riscv/riscv-iommu.h:30:17: error: field ‘parent_obj’ has incomplete type 30 | DeviceState parent_obj; | ^~~~~~~~~~ /home/danielhb/work/qemu/hw/riscv/riscv-iommu.h:50:5: error: unknown type name ‘dma_addr_t’; did you mean ‘in_addr_t’? 50 | dma_addr_t cq_addr; /* Command queue base physical address */ | ^~~~~~~~~~ | in_addr_t (...) /home/danielhb/work/qemu/hw/riscv/riscv-iommu.h:62:5: error: unknown type name ‘QemuThread’; did you mean ‘GThread’? 62 | QemuThread core_proc; /* Background processing thread */ | ^~~~~~~~~~ | GThread /home/danielhb/work/qemu/hw/riscv/riscv-iommu.h:63:5: error: unknown type name ‘QemuCond’ 63 | QemuCond core_cond; /* Background processing wake up signal */ | ^~~~~~~~ /home/danielhb/work/qemu/hw/riscv/riscv-iommu.h:71:18: error: field ‘trap_as’ has incomplete type 71 | AddressSpace trap_as; | ^~~~~~~ /home/danielhb/work/qemu/hw/riscv/riscv-iommu.h:72:18: error: field ‘trap_mr’ has incomplete type 72 | MemoryRegion trap_mr; | ^~~~~~~ /home/danielhb/work/qemu/hw/riscv/riscv-iommu.h:80:18: error: field ‘regs_mr’ has incomplete type 80 | MemoryRegion regs_mr; | ^~~~~~~ Fix it by adding the missing headers for these definitions. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250224190826.1858473-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
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-04linux-headers: Update to Linux v6.14-rc3Daniel Henrique Barboza13-35/+146
Update headers to retrieve the latest KVM caps for RISC-V. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20250221153758.652078-2-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-04disas/riscv: Add missing Sdtrig CSRsRob Bradford1-1/+3
This reflects the latest frozen version of the RISC-V Debug specification (1.0.0-rc4) which includes the Sdtrig extension. Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250206153410.236636-3-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04disas/riscv: Fix minor whitespace issuesRob Bradford1-6/+6
Some extra spaces made into into the RISC-V opcode data table. Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250206153410.236636-2-rbradford@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-04MAINTAINERS: Remove Bin Meng from RISC-V maintainersAlistair Francis1-4/+1
Bin Meng has been a long time contributor and maintainer for QEMU RISC-V and has been very beneficial to the RISC-V ecosystem. Unfortunately his email has started to bounce so this patch is removing them from MAINTAINERS. If in the future Bin Meng wants to return we will happily re-add them. Note that I'm not removing Bin Meng as a "SD (Secure Card)" maintainer. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20250128060546.1374394-1-alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04hw/riscv/virt: Add serial alias in DTBVasilis Liaskovitis1-0/+3
Add an "aliases" node with a "serial0" entry for the single UART in the riscv virt machine. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2774 Signed-off-by: Vasilis Liaskovitis <vliaskovitis@suse.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250116161007.39710-1-vliaskovitis@suse.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04goldfish_rtc: Fix tick_offset migrationRodrigo Dias Correa1-30/+13
Instead of migrating the raw tick_offset, goldfish_rtc migrates a recalculated value based on QEMU_CLOCK_VIRTUAL. As QEMU_CLOCK_VIRTUAL stands still across a save-and-restore cycle, the guest RTC becomes out of sync with the host RTC when the VM is restored. As described in the bug description, it looks like this calculation was copied from pl031 RTC, which had its tick_offset migration fixed by Commit 032cfe6a79c8 ("pl031: Correctly migrate state when using -rtc clock=host"). Migrate the tick_offset directly, adding it as a version-dependent field to VMState. Keep the old behavior when migrating from previous versions. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2033 Signed-off-by: Rodrigo Dias Correa <r@drigo.nl> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250114212150.228241-1-r@drigo.nl> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04hw/riscv/riscv-iommu-bits: Remove duplicate definitionsJason Chien1-16/+6
The header contains duplicate macro definitions. This commit eliminates the duplicate part. Signed-off-by: Jason Chien <jason.chien@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250115141730.30858-2-jason.chien@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04hw/riscv/riscv-iommu: Remove redundant struct membersJason Chien1-5/+0
Initially, the IOMMU would create a thread, but this thread was removed in the merged version. The struct members for thread control should have been removed as well, but they were not removed in commit 0c54acb8243 ("hw/riscv: add RISC-V IOMMU base emulation"). Signed-off-by: Jason Chien <jason.chien@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250115141730.30858-1-jason.chien@sifive.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 Barboza2-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 Barboza2-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-04hw/intc/riscv_aplic: Remove redundant "hart_idx" maskingHuang Borong1-1/+0
Remove the redundant masking of "hart_idx", as the same operation is performed later during address calculation. This change impacts the "hart_idx" value in the final qemu_log_mask() call. The original "hart_idx" parameter should be used for logging to ensure accuracy, rather than the masked value. Signed-off-by: Huang Borong <huangborong@bosc.ac.cn> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20250115035105.19600-1-huangborong@bosc.ac.cn> 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-03-04scripts/checkpatch: Fix a typoPhilippe Mathieu-Daudé1-2/+2
When running checkpatch.pl on a commit adding a file without SPDX tag we get: Undefined subroutine &main::WARNING called at ./scripts/checkpatch.pl line 1694. The WARNING level is reported by the WARN() method. Fix the typo. Fixes: fa4d79c64da ("scripts: mandate that new files have SPDX-License-Identifier") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20250303172508.93234-1-philmd@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2025-02-28scripts: forbid use of arbitrary SPDX tags besides license identifiersDaniel P. Berrangé1-0/+12
While SPDX-License-Identifier is a well known SPDX tag, there are a great many more besides that[1]. These are mostly focused on making machine readable metadata available to the 'reuse' tool and similar. They cover concepts like author names, copyright owners, and much more. It is even possible to define source file line groups and apply different SPDX tags to regions of code within a file. At this time we're only interested in adopting SPDX for recording the file global licensing info, so detect & reject any other SPDX metadata. If we want to explicitly collect extra data in SPDX format, we can evaluate each data item on its merits when someone wants to propose it at a later date. [1] https://spdx.github.io/spdx-spec/v2.2.2/file-tags/ https://spdx.github.io/spdx-spec/v2.2.2/file-information/ Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>