summary refs log tree commit diff stats
path: root/rust/qemu-api/src (unfollow)
Commit message (Collapse)AuthorFilesLines
2025-03-04hw/intc/aplic: refine kvm_msicfgaddrYong-Xuan Wang1-11/+13
Let kvm_msicfgaddr use the same format with mmsicfgaddr and smsicfgaddr. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20250224025722.3999-4-yongxuan.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04hw/intc/aplic: refine the APLIC realizeYong-Xuan Wang1-23/+26
When the APLIC is emulated in the kernel, the GPIO output lines to CPUs can be remove. In this case the APLIC trigger CPU interrupts by KVM APIs. This patch also move the code that claim the CPU interrupts to the beginning of APLIC realization. This can avoid the unnecessary resource allocation before checking failed. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20250224025722.3999-3-yongxuan.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04hw/intc/imsic: refine the IMSIC realizeYong-Xuan Wang1-21/+26
When the IMSIC is emulated in the kernel, the GPIO output lines to CPUs and aia_ireg_rmw_fn setting can be remove. In this case the IMSIC trigger CPU interrupts by KVM APIs, and the RMW of IREG is handled in kernel. This patch also move the code that claim the CPU interrupts to the beginning of IMSIC realization. This can avoid the unnecessary resource allocation before checking failed. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20250224025722.3999-2-yongxuan.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04binfmt: Add --ignore-family optionAndrea Bolognani1-3/+16
Until now, the script has worked under the assumption that a host CPU can run binaries targeting any CPU in the same family. That's a fair enough assumption when it comes to running i386 binaries on x86_64, but it doesn't quite apply in the general case. For example, while riscv64 CPUs could theoretically run riscv32 applications natively, in practice there exist few (if any?) CPUs that implement the necessary silicon; moreover, even if you had one such CPU, your host OS would most likely not have enabled the necessary kernel bits. This new option gives distro packagers the ability to opt out of the assumption, likely on a per-architecture basis, and make things work out of the box for a larger fraction of their user base. As an interesting side effect, this makes it possible to enable execution of 64-bit binaries on 32-bit CPUs of the same family, which is a perfectly valid use case that apparently hadn't been considered until now. Link: https://src.fedoraproject.org/rpms/qemu/pull-request/72 Thanks: David Abdurachmanov <davidlt@rivosinc.com> Thanks: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-ID: <20250127182924.103510-4-abologna@redhat.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04binfmt: Normalize host CPU architectureAndrea Bolognani1-19/+25
Right now information regarding the family each CPU type belongs to is recorded in two places: the large data table at the top of the script, and the qemu_host_family() function. We can make things better by mapping host CPU architecture to QEMU target in the few cases where the two don't already match and then using the data table to look up the family, same as we're already doing for the guest CPU architecture. Being able to reason in terms of QEMU target regardless of whether we're looking at the host or guest CPU architecture will come in handy to implement upcoming changes. A couple of entries are dropped in the process: BePC and Power Macintosh. I'm quite certain neither of those have ever been reported as CPU architectures by Linux. I believe many more of the entries that are carried forward could be dropped as well, but I don't have the same level of confidence there so I decided to play it safe just in case. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-ID: <20250127182924.103510-3-abologna@redhat.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04binfmt: Shuffle things aroundAndrea Bolognani1-7/+10
This should make no difference from the functional point of view and it's just preparation for upcoming changes. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-ID: <20250127182924.103510-2-abologna@redhat.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04target/riscv/kvm: Add some exts supportQuan Zhou1-0/+5
When the Sscofpmf/Svade/Svadu/Smnpm/Ssnpm exts is available expose it to the guest so that guest can use it. Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <303616ccad2b5309768157b50d93b3e89fecc9cb.1740371468.git.zhouquan@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-03-04docs/specs/riscv-iommu.rst: add HPM support infoDaniel Henrique Barboza1-0/+2
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250224190826.1858473-12-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
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>