Merge snan_bit_is_one and no_signaling_nans into one control.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Unify handling of the two snan parameters, letting the
caller simply extract the msb.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Avoid exponent overflow as well as checking that we don't lose information with
opposing scaling. Use it in partsN(scalbn) and partsN(round_to_int_normal).
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
The nan test had been down below because it was unlikely.
But if we have to have one anyway because of denormals,
we might as well take care of them right away.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Jay Chang [Mon, 18 May 2026 07:01:43 +0000 (15:01 +0800)]
hw/riscv: riscv-iommu: Re-process command queue after clearing CMD_ILL
When software clears CMD_ILL or CQMF error bits by writing 1 to CQCSR,
the IOMMU should re-check the command queue and continue processing
pending commands if head != tail.
Per RISC-V IOMMU specification :
If command-queue access leads to a memory fault then the
command-queue-memory-fault bit is set to 1 and the commandqueue
stalls until this bit is cleared. To re-enable command
processing, software should clear this bit by writing 1.
Signed-off-by: Jay Chang <jay.chang@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com>
Message-ID: <20260518070143.8405-1-jay.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Jim Shu [Tue, 28 Apr 2026 16:01:03 +0000 (00:01 +0800)]
hw/intc: riscv_aplic: add trace events of APLIC read/write function
Add the trace events for APLIC read/write functions.
Signed-off-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260428160103.3551125-5-jim.shu@sifive.com>
[ Changes by AF:
- Init val to zero to avoid uninitialised build errors
] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Jim Shu [Tue, 28 Apr 2026 16:01:02 +0000 (00:01 +0800)]
hw/intc: riscv_imsic: Add reset API to IMSIC
Clearing IMSIC registers and qemu_irq in the reset function
Signed-off-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260428160103.3551125-4-jim.shu@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Jim Shu [Tue, 28 Apr 2026 16:01:01 +0000 (00:01 +0800)]
hw/intc: riscv_aplic: Add reset API to APLIC
Clearing APLIC registers and qemu_irq in the reset function
Signed-off-by: Jim Shu <jim.shu@sifive.com> Signed-off-by: Fea.Wang <fea.wang@sifive.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260428160103.3551125-3-jim.shu@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Jim Shu [Tue, 28 Apr 2026 16:01:00 +0000 (00:01 +0800)]
hw/intc: riscv_aplic: Fix level trigger IRQ in direct delivery mode
According to the AIA spec ch4.7 ("Precise effects on interrupt-pending
bits"), pending bit of APLIC should be set/cleared whenever the
rectified input value is high/low in the both level-trigger mode
and direct delivery mode.
Currently, QEMU APLIC only clears the pending bit when interrupt is
claimed in APLIC, but not clears it when the rectified input value is
low. (e.g. IRQ source signal is low in the LEVEL_HIGH/Level1 mode).
The software may receive an additional IRQ if the peripheral
triggers one after the software clears the APLIC IRQ but before it
clears the peripheral's IRQ.
Thus, we also clear the pending bit via the rectified input value in the
level-trigger mode.
This change doesn't affect MSI delivery mode. Calling
riscv_aplic_msi_irq_update() when IRQ pending is low will do nothing.
Signed-off-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Chao Liu <chao.liu.zevorn@gmail.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260428160103.3551125-2-jim.shu@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Zishun Yi [Tue, 12 May 2026 06:23:10 +0000 (14:23 +0800)]
hw/riscv/virt-acpi-build: Fix off-by-one error in RIMT ID mapping
In build_rimt(), the calculation of `num_ids` for the ID mapping array
incorrectly uses the same formula (`0xffff - s->pci_iommu_bdf`) for both
System IOMMU and PCI IOMMU topologies.
For a System IOMMU, `s->pci_iommu_bdf` is 0. This results in a `num_ids`
value of 0xffff. Since the source ID base starts at 0, the mapping only
covers Requester IDs from 0 to 0xfffe. The final valid PCI Requester ID
(0xffff) is erroneously omitted from the RIMT table.
Fix this by decoupling the `num_ids` calculation. For System IOMMUs,
explicitly set `num_ids` to 0x10000 to cover the entire PCI Requester ID
space.
This issue was discovered and reported by SpecHunter, an AI-driven
architecture specification analysis tool.
target/riscv/csr.c: fix read of pmpaddr(0-63) CSRs
The priv spec defines, for RV64, that the upper 10 bits of
pmpaddr0-pmpaddr63 are WARL and are supposed to be cleared.
After this patch, using the bug reproducer in [1], writing ffffffffffffffff in pmpaddr0 and reading it back now results in 003fffffffffffff. Here's the 'diff -cp' dump before and after
this change:
There is no more uses left for these arrays. isa_edata_arr[] is doing
everything we need, making our lives a little easier when adding new
extensions.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260512032926.1978818-15-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv/tcg: use isa_edata_arr[] to create user props
This change has been done twice now: one in riscv-qmp-cmds, another in
the KVM. We're now ready to do it for TCG.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260512032926.1978818-14-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv: do not set defaults in cpu prop callback
Do not rely on riscv_cpu_* arrays to set rv32/rv64 CPU defaults - add
them to the CPU definition like we do with all other CPUs (aside from
'max').
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260512032926.1978818-13-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv/tcg: use cfg_offset as cpu_set_multi_ext cb opaque
The cpu_get_multi_ext_cfg/cpu_set_multi_ext_cfg callbacks are using a
RISCVCPUMultiExtConfig pointer as opaque, but internally we're just
using multi_ext_cfg->offset.
Use multi_ext_cfg->offset as opaque instead.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260512032926.1978818-12-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv/tcg: use isa_edata_arr[] to enable max exts
Use isa_edata_arr[] to enable all feasible extensions. Filter
experimental and vendor extensions by checking if the riscv,isa or the
prop name starts with 'x'.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260512032926.1978818-11-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv/kvm: use isa_edata_arr[] for unavailable props
Use isa_edata_arr[] directly instead of going through 3 different arrays
to populate the unavailable KVM properties.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260512032926.1978818-10-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv/tcg: use isa_edata_arr[] in riscv_cpu_update_misa_x()
The non-standard extensions, in this particular function the vendor
extensions, are all riscv,isa names that starts with 'x'.
In theory this is a bit slower than using riscv_cpu_vendor_exts
(isa_edata_arr is longer) but riscv_cpu_update_misa_x() is executed only
once during finalize(), i.e. not a hot path. We're accepting a tiny
performance hit as as a tradeoff for the code simplication we'll have
later by removing all riscv_cpu_* arrays.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260512032926.1978818-9-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260512032926.1978818-8-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Deprecate riscv_cpu_enable_named_feat() by creating implied rules for
'sha' and 'ssstateen'. 'zic64' is always true given that our default
block size is set to 64.
With this change we homogeneize extension handling when enabling
profiles.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260512032926.1978818-7-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv/tcg: use only isa_edata_arr[] in cpu_cfg_ext_get_name()
We're using both isa_edata_arr[] and riscv_cpu_named_features[] to find
an extension name based on a cfg offset. This is reminiscent of a past
where isa_edata_arr[] didn't include entries for internal extensions.
At this point we can use just isa_edata_arr[].
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260512032926.1978818-6-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv/tcg: treat all exts equally in cpu_disable_priv_spec_isa_exts
Commit 7e4f75cadf ("target/riscv/tcg: hide warn for named feats when
disabling via priv_ver") changed the design of
disable_priv_spec_isa_exts to not warn when disabling what we were
calling "named features" at that time.
Back in that time we were adding RVA22 profile support and we were dealing
with a RVI innovation: named features. These can be define as cute
names for pre-existing behavior/parameters, e.g. 'zic64b' means all
cache blocks must have 64 bytes. They do get inserted in the riscv,isa
but they are not "real" extensions because users shouldn't be setting
them in the command line, or so we thought back then, and we attempted
to model that by calling it "named features".
This didn't age that well: ziccrse is a so called named feature as far as
TCG goes, but then KVM had to treat it as a regular extension that can be
user set and we made an exception: ziccrse is a named feature that is
user set by KVM.
"Named features" are regular extensions that might or might not be user
set, and might or might not warrant special handling during realize()
by setting other parameters. And we'll being treating them as such,
which will culminate in the end of riscv_cpu_named_features[] array in
the end.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260512032926.1978818-5-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv: make riscv-qmp-cmds use isa_data_arr[]
We want to reduce the usage of the riscv_cpu_* arrays in
target/riscv/cpu.c, centering everything in isa_edata_arr[] instead, to
reduce data duplication and make our lives a bit easier when adding new
extensions.
To do that we'll have to make isa_edata_arr[] do what the other arrays
are currently doing, not breaking existing semantics in the process.
The riscv_cpu_* arrays have a few exclusive uses:
- set default extensions for rv32 and rv64;
- create user CPU properties;
- misc uses around tcg-cpu.c and kvm-cpu.c.
We'll slowly make isa_edata_arr[] supersede these arrays. Start by
adding a new 'prop_name' field in RISCVIsaExtData. This field is needed
because not all extensions have properties and not all properties match
the riscv,isa string name.
Create two additional macros and reclassify existing isa_edata_arr[]
entries as follows:
- ISA_EXT_DATA_ENTRY creates an entry where prop_name == riscv,isa.
Most of our regular extensions fall into this category;
- ISA_EXPERIMENTAL_EXT_DATA_ENTRY: same as above but add a "x-" to the
prop name, i.e. prop_name == "x-" + riscv,isa;
- ISA_INTERNAL_EXT_DATA_ENTRY: used to declared internal extensions. By
'internal' we mean users/management can't set them on or off.
With these new macros we can start our simplification by changing
riscv-qmp-cmds to use isa_edata_arr[]. We'll just scroll through it
once and gather what we need.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260512032926.1978818-4-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
target/riscv/cpu.c: fix smctr/ssctr isa_edata_arr[] order
Noticed when realizing that 'svadu' was too far apart from 'svade'.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260512032926.1978818-3-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
PCI bus numbers may still be unassigned when QEMU initializes a PCI
device's bus-master address space. For devices behind bridges,
pci_bus_num() can return 0 at that point because the guest has not yet
programmed the bridge Secondary Bus Number register.
The RISC-V IOMMU currently stores a fixed device_id in RISCVIOMMUSpace
when the address space is created. If the guest later enumerates the
device on a non-zero bus, DMA translation still uses the stale device_id
and may look up the wrong device context in the DDT.
Store the stable PCIBus pointer and devfn in RISCVIOMMUSpace instead,
and compute the device_id from the current bus number when it is needed.
This keeps DMA translation and ATS invalidation in sync with guest PCI
bus enumeration.
Signed-off-by: Chengbo Gao <gaochengbo@bosc.ac.cn> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260514020637.2819308-1-gaochengbo@bosc.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Fix a mode-to-capability comparison error in
riscv_iommu_validate_device_ctx. The code was comparing fsc_mode (a
value) against a capability bitmask, making the SV32 support check
ineffective.
This issue was discovered and reported by SpecHunter, an AI-driven
architecture specification analysis tool.
Zishun Yi [Tue, 12 May 2026 05:22:40 +0000 (13:22 +0800)]
target/riscv: clear mseccfg on reset for all dependent extensions
Currently, the `mseccfg` CSR is only cleared to 0 during reset if the
`ext_smepmp` is enabled. However, this register is now shared by
several other extensions such as `zkr`, `smmpm`, and `zicfilp`.
Fix by clearing `mseccfg` if any dependent extension is present, and
adjusting the relevant comments.
This vulnerability was discovered and reported by SpecHunter, an
AI-driven architecture specification analysis tool.
Alistair Francis [Wed, 13 May 2026 05:18:41 +0000 (15:18 +1000)]
target/riscv: Update the local interrupt mask
The RISC-V spec describes bits 0-15 as standard fixed interrupts. The
AIA spec on the other hand describes bits 0-12 as standard fixed
interrupts. This conflict causes issues for us as we don't dynamically
determine if AIA is enabled when setting the *delegable_ints consts.
This means currently we incorrectly treat the LCOFIP bit as delegable,
even if AIA is disabled, which is incorrect (see the issues mentioned
below).
The AIA spec indicates that implementations can determine which bits of
13-63 in mvien are writable, so let's just make it bits 15-63 to match
the main spec.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3133
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3134
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3135
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3138
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3140 Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260513051841.1671987-1-alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Zishun Yi [Mon, 11 May 2026 12:48:28 +0000 (20:48 +0800)]
target/riscv: Add mseccfg to VMStateDescription
Currently, the Machine Security Configuration Register (mseccfg) was
missing from the live migration state. This omission causes the register
to be reset to zero on the destination host after migration.
Fixed by adding vmstate_mseccfg subsection
This vulnerability was discovered and reported by SpecHunter, an
AI-driven architecture specification analysis tool.
Zishun Yi [Mon, 11 May 2026 10:26:27 +0000 (18:26 +0800)]
target/riscv/pmp: Fix integer overflow in TOR and NA4 address computation
According to the RISC-V Privileged Manual: "The Sv32 page-based
virtual-memory scheme described in sv32 supports 34-bit physical
addresses for RV32, so the PMP scheme must support addresses wider than
XLEN for RV32."
However, the current QEMU implementation uses `target_ulong` (which
resolves to `uint32_t` on RV32) for PMP address variables. When
shifting these addresses left (e.g., `this_addr << 2`), an integer
overflow occurs, truncating the high bits of the 34-bit physical
address.
Fix this issue by changing the types of PMP address variables
(`this_addr` and `prev_addr`) to `hwaddr`.
This issue was discovered and reported by SpecHunter, an AI-driven
architecture specification analysis tool.
Zishun Yi [Fri, 8 May 2026 17:49:17 +0000 (01:49 +0800)]
target/riscv: Fix missing CDE check for scountinhibit
According to the RISC-V smcdeleg specification: "When menvcfg.CDE=0,
attempts to access scountinhibit raise an illegal-instruction
exception."
The current implementation of scountinhibit_pred() only checks the
hardware extensions (ext_ssccfg, ext_smcdeleg) and virtualization
status, but completely misses the runtime environment configuration
check (menvcfg.CDE). This allows S-mode to access scountinhibit even
when the M-mode has explicitly disabled counter delegation.
This issue was discovered by the SpecHunter tool
(https://github.com/yizishun/rv-isa-sec/blob/master/output/riscv-isa-manual/pr-2571/qemu.txt).
Fixes: 6247dc2ef70b ("target/riscv: Add counter delegation/configuration support") Signed-off-by: Zishun Yi <vulab@iscas.ac.cn> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Message-ID: <20260508174917.371667-1-vulab@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Zishun Yi [Mon, 11 May 2026 04:05:34 +0000 (12:05 +0800)]
target/riscv: Remove unconditional MENVCFG_CDE from mask
Currently, the MENVCFG_CDE (Counter Delegation Enable) bit is
unconditionally included in the base write mask for CSR_MENVCFG.
This make the subsequent conditional check
`(cfg->ext_smcdeleg ? MENVCFG_CDE : 0)` completely ineffective,
as a bitwise OR cannot clear a bit that is already set.
Fix this by removing MENVCFG_CDE from the initial base mask. The bit
will now only be writable when explicitly granted by the `ext_smcdeleg`
configuration.
This issue was discovered and reported by SpecHunter, an AI-driven
architecture specification analysis tool.
target/riscv: Fix tail handling for vmv.s.x and vfmv.s.f
The risc-v vector spec defines vmv.s.x and vfmv.s.f as writing
element 0 of the destination register while the remaining destination
elements follow the current tail policy. When QEMU runs with
rvv_ta_all_1s enabled, those elements must therefore become all 1s.
QEMU handled both instructions as translation-time special cases that
directly wrote vd[0] and skipped the usual tail processing. As a result,
vmv.s.x and vfmv.s.f left the remaining destination elements unchanged
instead of applying the configured tail policy.
Fix this by routing both instructions through a helper that writes
vd[0] and then treats the rest of the destination register as tail,
reusing the existing agnostic-element fill logic.
Signed-off-by: Zhongyao Chen <chen.zhongyao@zte.com.cn> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <202605061005.646A537u037157@mse-fl1.zte.com.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
"For exceptions that cannot occur in less privileged modes, the
corresponding medeleg bits should be read-only zero. In particular,
medeleg[11] is read-only zero."
QEMU incorrectly included RISCV_EXCP_M_ECALL in DELEGABLE_EXCPS. It
allowed the 11th bit to be written and read as set. Fixed by removing it
from the DELEGABLE_EXCPS mask, adhering to the specification.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3438 Signed-off-by: Abhigyan Kumar <314abh@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260427060849.749179-2-314abh@gmail.com>
[ Changes by AF:
- Remove comment
] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Frank Chang [Wed, 13 May 2026 03:05:03 +0000 (11:05 +0800)]
hw/char: Check interrupt after txctrl register is written
It's possible that the transmit watermark level (txctrl.txcnt) is
updated when the user writes to txctrl register, which may decrease the
transmit watermark level to less than the number of entries in the
transmit FIFO. In such a case, the interrupt should be raised so we need to
call sifive_uart_update_irq() to check and update interrupt when txctrl
register is written. Otherwise, the interrupt will have to be delayed
until next TX FIFO transmission is processed.
Suggested-by: Chao Liu <chao.liu.zevorn@gmail.com> Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260513030503.3665414-1-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Anton Blanchard [Fri, 17 Apr 2026 08:03:28 +0000 (08:03 +0000)]
target/riscv: rvv: Handle source overlap of vector widening reduction instructions
Widening reductions read vs2 as a vector of SEW elements and vs1[0] as a
scalar of 2*SEW. The ISA does not allow the same vector register to be read
with different EEWs, so they must not overlap.
vs1 is read as a scalar from element 0, so it is treated as a single vector
register (independent of LMUL) when checking overlap.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3208 Signed-off-by: Anton Blanchard <antonb@tenstorrent.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260417080328.31918-1-antonb@tenstorrent.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Andrew Jones [Fri, 8 May 2026 20:51:29 +0000 (15:51 -0500)]
hw/riscv/riscv-iommu: Fix Svnapot 64KB pages
The Svnapot extension encodes a 64KB leaf PTE by setting PTE_N and
storing bits [3:0] of the PPN as a NAPOT size indicator. The IOMMU
model wasn't checking PTE_N and therefore was using the raw (NAPOT-
encoded) PPN directly in the physical address, yielding an address
32 KB above the correct base.
Fix both riscv_iommu_spa_fetch() and pdt_memory_read() by mirroring
the Svnapot handling already present in target/riscv/cpu_helper.c:
The spec only defines napot_bits == 4 (64KB); any other value is
treated as a reserved encoding.
This is a fix, rather than new feature support, because the spec
says "IOMMU implementations must support the Svnapot standard
extension for NAPOT Translation Contiguity."
Fixes: 0c54acb8243d ("hw/riscv: add RISC-V IOMMU base emulation") Cc: qemu-stable@nongnu.org Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Reviewed-by: Tomasz Jeznach <tjeznach@rivosinc.com>
Message-ID: <20260508205129.377032-1-andrew.jones@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Zishun Yi [Mon, 11 May 2026 07:27:05 +0000 (15:27 +0800)]
target/riscv: Allow mseccfg access based on ext_zicfilp
The Zicfilp extension adds the MLPE field to the mseccfg CSR. According
to the RISC-V Privileged Specification, mseccfg exists if any extension
that adds a field to it is implemented.
Currently, the `have_mseccfg()` predicate function checks for Smepmp,
Zkr, and Smmpm, but misses Zicfilp. As a result, if a CPU is configured
with `zicfilp=true` but without the other extensions, accessing the
mseccfg CSR will incorrectly raise an illegal instruction exception.
This patch adds the missing check for `ext_zicfilp` to ensure the CSR
is properly accessible when the Zicfilp extension is enabled.
This issue was discovered and reported by SpecHunter, an AI-driven
architecture specification analysis tool.
Update OpenSBI and the pre-built opensbi32 and opensbi64 images to
version 1.8.1. We're going for the intermediate/bug fix release 1.8.1
directly due to a PMP related fix that was impacting QEMU profile CPUs.
Changelog for v1.8.1:
* Typo fix in comments of sbi_hartindex_to_hartid()
* Fix hart protection abstraction for platforms without PMP
Changelog for v1.8 includes, among other things:
- IPI device ratings
- SiFive CLINT v2 support
- SiFive PL2 cache controller driver
- SiFive Extensible Cache (EC) driver
- SiFive TMC0 based HSM driver
- SiFive SMC0 based system suspend driver
- MPXY RPMI mailbox driver for voltage service group
- MPXY RPMI mailbox driver for device power service group
- MPXY RPMI mailbox driver for performance service group
Check out the full release log at [1] for more info.
Signed-off-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260108160825.171794-1-daniel.barboza@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Mark the OpenSBI Firmware as maintained by me (Alistair Francis) and add
Daniel Henrique Barboza as a reviewer.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260506234243.1873782-1-alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Frank Chang [Fri, 24 Apr 2026 05:05:09 +0000 (13:05 +0800)]
target/riscv: Update MISA.X for non-standard extensions
MISA.X is set if there are any non-standard extensions.
We should set MISA.X when any of the vendor extensions is enabled.
Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260424050509.3935180-3-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Frank Chang [Fri, 24 Apr 2026 05:05:08 +0000 (13:05 +0800)]
target/riscv: Update MISA.C for Zc* extensions
MISA.C is set if the following extensions are selected:
* Zca and not F.
* Zca, Zcf and F (but not D) is specified (RV32 only).
* Zca, Zcf and Zcd if D is specified (RV32 only).
* Zca, Zcd if D is specified (RV64 only).
Therefore, MISA.C must be set according to the Zc* extension rules.
Warn the user if RVC is explicitly disabled but MISA.C is required by
the rules above.
Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Max Chou <max.chou@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20260424050509.3935180-2-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Alistair Francis [Thu, 30 Apr 2026 05:22:18 +0000 (15:22 +1000)]
target/riscv: Deprecate the shakti_c machine
The RISC-V shakti_c machine hasn't had meaningful contributions since 2021
and is currently unmaintained. The machine is scheduled to be removed as it
appears to have no users.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Chao Liu <chao.liu.zevorn@gmail.com>
Message-ID: <20260430052218.771358-3-alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Alistair Francis [Thu, 30 Apr 2026 05:22:17 +0000 (15:22 +1000)]
target/riscv: Remove spike as default machine
In QEMU 10.0 we deprecated the default spike machine, let's finally
remove spike as the default and require users to specify the machine.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Chao Liu <chao.liu.zevorn@gmail.com>
Message-ID: <20260430052218.771358-2-alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* tag 'pull-qapi-2026-05-21' of https://repo.or.cz/qemu/armbru:
qapi/net: Drop unused type String
qapi/net: Wean SLIRP off QAPI type String to improve documentation
qapi/net: Wean passt off QAPI type String to improve documentation
qapi/net: Rename NetDevPasstOptions to NetdevPasstOptions
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Thu, 21 May 2026 12:59:54 +0000 (08:59 -0400)]
Merge tag 'next-pull-request' of https://gitlab.com/peterx/qemu into staging
Migration and mem pull request
- Peter's fix on 2nd migration crashing if the 1st migration cancelled early
- Phil's patch to remove VMS_MULTIPLY_ELEMENTS across tree
- Peter's fix on possible division by zero in recent query-migrate change
- Aadeshveer's cleanup for current_migration references
- Fabiano's fix of auto-converge test
- Maciej's maintainer file update for CPR
- Fabiano's migration qtest refactor to stick with -incoming defer
- Bin's cleanup / fix series all over migration (part of)
- hongmianquan's cpr optimization to use ghash for fd bookkeeping
- Yong's email address update
* tag 'next-pull-request' of https://gitlab.com/peterx/qemu: (29 commits)
MAINTAINERS: Update email of Yong Huang
migration/cpr: use hashtable for cpr fds
migration/multifd: cache channel count in multifd_send_sync_main
migration/multifd: cache migrate_multifd_channels() in send/recv hot paths
migration/multifd: fix off-by-one in recv channel ID validation
migration/savevm: use stack-allocated bitmap in configuration_validate_capabilities
migration/vmstate: avoid per-element heap churn in vmsd ptr marker field
migration/global_state: replace strcpy("") with explicit NUL termination
tests/qtest/migration: Unify URIs
tests/qtest/migration: Stop passing URI into migrate_start
tests/qtest/migration: Use defer in dirty_limit test
tests/qtest/migration: Use defer for auto-converge
tests/qtest/migration: Use defer for cpr-tests
tests/qtest/migration: Use defer for all tests
tests/qtest/migration: Remove multifd compression hook
tests/qtest/migration: Set compression method in compression-tests
tests/qtest/migration: Defer by default in precopy_common
tests/qtest/migration: Use a default TCP URI for precopy
tests/qtest/migration: Use precopy_unix_common for ignore-shared test
tests/qtest/migration: Group unix migration tests
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
This can be replaced by object_new_with_props_from_qdict, which does
functionally the same job, but the caller does not own the returned
reference, instead the parent object owns it.
In one case we can use object_new_with_props_from_qdict_owned instead
since the object is not intended to have any parent.
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
qom: allow object_new_with_prop* to trigger module loading
The object_new_with_prop* methods will shortly be replacing the
user_creatable_add_type method. In order to do that, the
object_new_with_prop* methods must allow module loading to be
triggered for any types.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
qom: fix ability to create objects without a parent
object_new_with_propv allowed id/parent to be optional, in which case
the caller was expected to own the returned object. Unfortunately a
trailing object_unref() meant that the returned object was already
freed.
It is confusing to have a single method with two different ownership
scenarios for the returned object.
Make id/parent mandatory in object_new_with_propv once more, and add
a new object_new_with_propv_parentless that does not accept id/parent
at all and lets the caller own the returned reference.
The helper method has abstracted the way properties are represented
and set in order to facilitate the subsequent commit.
Unit tests are added to address the root cause that allowed the bug
to slip through in commit 6134d752.
Fixes: 6134d7522e5 ("qom: don't require user creatable objects to be registered") Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This will be used to replace user_creatable_add_type with an impl
that shares most code with object_new_with_props, and is not tied
to the user creatable interface.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This matches the location of the object_set_props and object_set_propv
methods, since this method is not inherently tied to the user creatable
interface. As part of this, object_set_props_from_qdict is also exposed
as a public API since it is still called from object_interfaces.c.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This matches the convention established by the object_set_props and
object_set_propv methods.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
qom: shorten name of object_set_properties_from_keyval
This matches the convention established by the object_set_props and
object_set_propv methods.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
qom: make errp last param in methods taking va_list
object_new_with_props can't put 'errp' last due to the use of
variadic arguments. That constraint does not apply to the use
of va_list with object_new_with_propv, so follow normal practice
with 'errp' placement.
The same rationale applies to object_set_propv.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The object_new_with_props/propv methods failed to validate the ID string
format, thus diverging from user_creatable_add_type.
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The objectg_new_with_propv/props methods failed to validate that the
QOM "id" was well formed. This allowed the vfio-user code to use an
invalid ID of "VFIO user" (space is not permitted) in its internal
code.
Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
qom: add trace events for object/property lifecycle
This adds tracing around object allocation & finalization, the addition &
deletion of properties, and the addition & deletion of children.
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
gitlab: remove I/O tests from build-tcg-disabled job
Now that we have dedicated CI jobs for running I/O tests on each
supported format/protocol, we no longer need to special case a
run of a hand picked set of tests in the build-tcg-disabled job.
Acked-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
CI is only exercising the qcow2 'auto' tests currently. As a result we
get no exposure of changes which cause regressions in other block format
drivers.
This adds new CI jobs for each block format, that will run the target
'make check-block-$FORMAT'. The jobs are separate so that we have the
ability to make each format gating or not, depending on their level
of reliability.
The 'centos' image is used to run the I/O tests since several tests
have an implicit dependency on x86_64-softmmu, and thus break with
other architecture targets. The 'centos' build job is the only one
that creates the x86_64-softmmu target in CI. Ideally this target
portability in I/O tests would be fixed to avoid this limitation.
Acked-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce a "_flaky_test" function for shell based I/O tests which
accepts a GitLab issue URL, and causes the I/O test to be skipped
unless the $QEMU_TEST_FLAKY_TESTS environment variable is set.
The equivalent "skip_flaky" test decorator is added for python based
I/O tests with the same behaviour.
This is used by:
* Test 151 which fails in QEMU private AWS runners due to failure
to make progress in time
* Test 181 which fails with a non-responsive QEMU on AWS runners
with the QED format
* Test 185 which fails in GitLab shared runners
* Test 308 which fails to see disk usage increase after fallocate
Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
iotests: fix check for sudo access in LUKS I/O test
The test did not cope with the possibility that 'sudo' was not installed
at all, merely that it was not configured. This broke tests in any CI
env which lacks 'sudo'.
Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The I/O test 128 uses 'dmsetup create' to create a device, optionally
using sudo to elevate privileges.
This dmsetup command works in GitLab CI, however, the test then fails
with a missing device name:
1..1
# running raw 128
not ok raw 128
----------------------------------- stderr -----------------------------------
--- /builds/berrange/qemu/tests/qemu-iotests/128.out
+++ /builds/berrange/qemu/build/scratch/raw-file-128/128.out.bad
@@ -1,5 +1,5 @@
QA output created by 128
== reading from error device ==
-read failed: Input/output error
+qemu-io: can't open device /dev/mapper/eiodev16546: Could not open '/dev/mapper/eiodev16546': No such file or directory
*** done
(test program exited with status code 1)
It is believed that this is due to the build env using a manually
populated /dev, such that the device mapper node won't ever appear.
It is not a race, since a test adding a sleep did not result in the
device appearing.
Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
iotests: use 'driver' as collective term for either format or protocol
The I/O tests integration previously exclusively tested block formats
and now also covers the NBD protocol. Replace references to 'format'
with 'driver', as a generic term to collectively apply to either a
format or protocol.
Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This introduces new suites for running I/O tests on NBD and LUKS
drivers, giving new make targets
* make check-block-luks
* make check-block-nbd
as well as adding their tests to 'make check-block SPEED=thorough'
Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
docs/devel/testing: expand documentation for 'make check-block'
Explain in greater detail what 'check-block' will run for each format,
and also document the new format specific targets.
Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
iotests: add a meson suite / make target per block I/O tests format
Currently each block format is classified as either 'quick', 'slow' or
'thorough' and this controls whether its I/O tests are added to the meson
suites 'block-quick', 'block-slow' or 'block-thorough'.
This suites are exposed the 'check-block' make target, accepting the
optional SPEED variable.
As we add more formats to the 'thorough' group, however, it becomes
increasingly large and time consuming to run. What is needed is a make
target that can exercise all tests for an individual format, regardless
of speed classification.
This makes use of the previous enhancement to mtest2make.py to introduce
new meson suites 'block-$FORMAT-optional', which translate to new top
level make targets 'check-block-$FORMAT'. These new targets always run
all tests and as such do not need the SPEED variable to be set, but are
not triggered by 'make check' or 'make check-block'.
Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The set of tests under the "thorough" speed, however, can get rather
large and it would be useful to have a way to expose further make
targets for directly running a particular subset of tests.
This needs a way to run a target without requiring the SPEED variable,
while also not having them enabled by default as if they were 'quick'
tests.
This modifies mtest2make.py to support this idea by allowing for a new
suffix '-optional' on a suite. When this is present, a correspondingly
named make target will be created without the '-optional' suffix which
will never be run automatically.
This is intended to be combined with use of other suites. For example,
a single NBD test might be added to two suites, 'block-thorough' and
'block-nbd-optional'.
This would allow running it as part of all the block tests with
'make check-block SPEED=thorough', and as part of a standalone target
'make check-block-nbd'.
Acked-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
scripts/mtest2make: ensure output has stable sorting
When debugging mtest2make.py changes it is important to be able to
compare the old and new output. This requires that any lists in the
output have stable sort ordering.
Acked-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
iotests: ensure all qcow2 I/O tests are able to be run via make
For block formats marked as 'quick', only tests in the 'auto' group are
added to the meson test suite.
The result of this is that qcow2 tests not in the 'auto' group cannot be
run at all, even if passing SPEED=slow or SPEED=thorough.
To fix this we need todo two passes over the I/O test list. First add
all tests from 'auto' group into the 'block' suite, so they are run by
default. Then on the second pass add any tests which were not in 'auto'
into the 'block-slow' suite, so they get run when SPEED=slow or
SPEED=thorough.
Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If a test is in the 'block-slow' or 'block-thorough' suite, there is no
need to also add it to the 'slow' or 'thorough' suites.
Acked-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
iotests: print reason when I/O test is skipped in TAP mode
The TAP output on a skipped test:
ok raw 181 # SKIP
is not informative.
The test program included a reason, and that should be displayed
in TAP mode (it is already shown in non-TAP mode):
ok raw 181 # SKIP Postcopy is not supported
Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
gitlab: ensure all meson jobs capture build/meson-logs by default
The build-without-defaults and build-tci jobs do not capture any
artifacts, despite running 'make check'. This has proved a repeated
bug with CI jobs, so introduce a new '.meson_job_template' rule
which always captures 'build/meson-logs'. Jobs can still provide
their own 'artifacts:' config which will override this default
behaviour.
Acked-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
John Snow [Tue, 31 Mar 2026 20:33:37 +0000 (16:33 -0400)]
python: bump qemu.qmp to v0.0.6
This release removes some deprecated warnings for our use of the old
sendmsg API on older python versions.
Acked-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> Signed-off-by: John Snow <jsnow@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The previous refactoring of credential creation failed to allocate
storage fo the anonymous TLS credentials on the client endpoint.
Fixes: 70f9fd8dbf7233bee497055a9b7825e3729ce853 Reported-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Tejus GK [Fri, 20 Mar 2026 08:39:41 +0000 (08:39 +0000)]
io: invert the return semantics of qio_channel_flush
With the kernel's zerocopy notification mechanism, the caller can
determine whether
* All syscalls successfully used zero copy
* At least one syscall failed to use zero copy
But, as of now QEMU's IO channel flush function semantics are like
* 1 => all syscalls failed to use zero copy
* 0 => at least one syscall successfully used zero copy
This is not aligned with what the kernel reports, and ends up reporting
false negatives for cases like when there's just a single successful
zerocopy amongst a collection of deferred zero-copies during a flush.
Fix this by inverting the return semantics of the IO flush function.
Suggested-by: Peter Xu <peterx@redhat.com> Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Tejus GK <tejus.gk@nutanix.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
qapi/net: Rename NetDevPasstOptions to NetdevPasstOptions
We have eighteen QAPI type names starting with Netdev. Commit 854ee02b222 (net: Add passt network backend) added a first one
starting with NetDev. Rename it for consistency.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260506105421.2461117-2-armbru@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
James Hilliard [Thu, 9 Apr 2026 03:54:42 +0000 (05:54 +0200)]
target/mips: add Octeon LA* atomic instructions
Implement the Octeon LA* read-modify-write atomic instruction family:
LAI/LAID, LAD/LADD, LAA/LAAD, LAS/LASD, LAC/LACD, and LAW/LAWD.
These operations are architecturally distinct from SAA/SAAD and are used
by existing Octeon user-mode code for atomic counters, bit operations,
and exchange-style updates.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Co-developed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <bd591571-121c-4eac-8ce6-e1e2234dcf3f@linaro.org>
James Hilliard [Mon, 11 May 2026 18:22:55 +0000 (12:22 -0600)]
target/mips: add Octeon QMAC instructions
QMAC.0x and QMACS.0x multiply the selected signed Q15 halfword lane from
rs by rt<15:0> and accumulate the Q31 product into the Octeon HI/LO
accumulator state.
QMAC updates the full 64-bit HI/LO accumulator. QMACS saturates the
32-bit Q31 result in LO and keeps HI<0> as the sticky saturation flag.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
[PMD: Add min32/max32 in trans_QMACS()] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20260520172313.23777-24-philmd@linaro.org>
projects / thirdparty / qemu.git / log
