summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
13 daysUpdate version for 10.0.13 releasev10.0.13staging-10.0stable-10.0Michael Tokarev
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 daystarget/riscv/tcg: sret in virtual user mode raises virtual instruction exceptionChristian S. Lima
Currently, when a `sret` is executed in virtual user mode, qemu raise an `illegal instruction exception`, but in this case the correct behavior is to raise a `virtual instruction exception` and the code already contains a check to it, but it's not enough to catch. This patch is useful to improve the correctness of the virtualization of the risc v architecture. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3622 Signed-off-by: Christian S. Lima <christianslima@proton.me> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20260808031849.59726-1-christianslima@proton.me> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 85d38315fd19cda7fcfec5350f27cdfa15742600) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 daystarget/riscv: enforce even register constraints for Zdinx fcvt pairswangyang
fcvt.d.h and fcvt.h.d access a 64-bit double held in a register pair, so under Zdinx/Zhinxmin the odd-rd (fcvt.d.h) and odd-rs1 (fcvt.h.d) encodings are reserved. Add the missing REQUIRE_EVEN checks so those encodings raise an illegal-instruction exception instead of retiring. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4109 Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: wangyang <wangyang25@otcaix.iscas.ac.cn> Message-ID: <ea287909fd6043e0bbcdbfdcb0cc8063@wangyang25.otcaix.iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit e68cc2e5cd28333ac76d757ed2db7d2f7635d09a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 daystarget/riscv: reject FMV.X.W/FMV.W.X under Zfinxwangyang
Zfinx explicitly excludes the FMV transfer instructions, but trans_fmv_x_w/trans_fmv_w_x used REQUIRE_ZFINX_OR_F so a Zfinx-only CPU accepted them. Require RVF instead so the transfers trap with an illegal instruction when only Zfinx is present. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4108 Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: wangyang <wangyang25@otcaix.iscas.ac.cn> Message-ID: <36c7cfebd27b4b6e8bcdd00e09e9dda0@wangyang25.otcaix.iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit af1e669cef162e8d9b5f2f176e8b909d61c4b530) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 daystarget/riscv: honor zicbo* envcfg gating in linux-user modewangyang
In user-only builds check_zicbo_envcfg() skipped the envcfg check entirely (#if !defined(CONFIG_USER_ONLY)), so cbo.inval/cbo.flush/ cbo.zero retired unconditionally in linux-user even though the machine-level envcfg fields are never initialized. Give the user-mode build a senvcfg-based gate, and initialize SENVCFG_CBZE at reset when ext_zicboz is enabled so cbo.zero stays usable while cbo.inval/cbo.flush remain illegal, matching the user-mode view of a typical firmware/kernel setup. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4107 Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: wangyang <wangyang25@otcaix.iscas.ac.cn> Message-ID: <9b2f22fc402b48b8ba81f72be8ed04bc@wangyang25.otcaix.iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 12289f2f9a0f1ffa6a75c2b189a0273dc455dfb0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 daysdisas/riscv: Fix typo in th.lbib formatRichard Henderson
th.lbib should format the same as th.lbia, and the other increment insns, with the address register in parenthesis. Cc: qemu-stable@nongnu.org Fixes: 318df7238b9 ("disas/riscv: Add support for XThead* instructions") Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20260812223142.349142-41-richard.henderson@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit ecbd3a031f12669da98cdf929cbc7dbb88d3450f) (Mjt: fix-up across v11.1.0-496-g7de6afd53186 "disas/riscv: Drop explicit zero of rv_opcode_data fields") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 daysdisas/riscv: Fix isa decoding of rev8Richard Henderson
The encoding of rev8 is different for rv32 and rv64. Cc: qemu-stable@nongnu.org Fixes: 02c1b569a15 ("disas/riscv: Add Zb[abcs] instructions") Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20260812223142.349142-40-richard.henderson@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit d610e55c8390a8bfd15d0a4f1521d7fc46e4e0b7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 daysdisas/riscv: Fix rv32 encoding of zext.hRichard Henderson
For rv64, pack with rs2 = 0 does not encode zext.h. Cc: qemu-stable@nongnu.org Fixes: 02c1b569a15 ("disas/riscv: Add Zb[abcs] instructions") Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20260812223142.349142-39-richard.henderson@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit d4151cf2675124e26b3383ae06f7352a23f17399) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 daystarget/riscv: allow menvcfg/henvcfg LPE and SSE bits on RV32A-Shehab
The Zicfilp landing-pad enable (LPE, bit 2) and Zicfiss shadow-stack enable (SSE, bit 3) controls live in the low 32 bits of menvcfg and henvcfg, and the CFI specification defines them for both RV32 and RV64. QEMU only adds MENVCFG_LPE/MENVCFG_SSE (and the henvcfg equivalents) to the writable mask inside the "riscv_cpu_mxl(env) == MXL_RV64" block, so on RV32 these bits are silently dropped and the features cannot be enabled. This is inconsistent with write_senvcfg(), which already handles SENVCFG_LPE/SENVCFG_SSE regardless of MXLEN. Hoist the LPE/SSE mask handling out of the RV64-only block in write_menvcfg() and write_henvcfg() so the bits become writable on RV32 as well. The upper-half writers (write_menvcfgh/write_henvcfgh) are unaffected because these bits reside in the low 32 bits. Reproducible on qemu-system-riscv32 -cpu rv32,zicfilp=true,zicfiss=true: an M-mode write of menvcfg.{LPE,SSE} reads back as zero, while the same program on rv64 keeps the bits set. Fixes: 4923f672e3d7 ("target/riscv: Introduce elp state and enabling controls for zicfilp") Fixes: 8205bc127a83 ("target/riscv: introduce ssp and enabling controls for zicfiss") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4045 Signed-off-by: A-Shehab <ahshehab24@gmail.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Message-ID: <20260726080537.13913-1-ahshehab24@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit bd1ee9ab3c39f269d8bea8acf83ea833a69a6e10) (Mjt: introduce `RISCVCPUConfig *cfg` variable in write_henvcfg() from v10.0.0-1878-gdff5f515409f "target/riscv: Enable/Disable S/VS-mode Timer when STCE bit is changed") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 dayshw/riscv/riscv-iommu: preserve requested perm in spa_fetch()Andrew Jones
b18e3f0e2d0f fixed spa_fetch() faults whose TTYP used the leaf PTE permission instead of the original request permission. However, it kept that request-narrowed value in iotlb->perm after a successful walk, and riscv_iommu_translate() caches iotlb->perm for later accesses to the same IOVA. That means a write to an RW mapping can cache the entry as write-only. A later read then hits the cache and faults even though the mapping allows it, which showed up in NVMe testing as bogus completions and controller timeouts. Keep the requested permission in a separate req_perm and use it for all permission checks and fault-type decisions. Accumulate the leaf permissions separately and copy them to iotlb->perm only after the full walk succeeds, so cached entries describe the mapping rather than the current request. Since faults leave iotlb->perm as the original request, the S-stage and G-stage TTYP fixes remain intact. Fixes: b18e3f0e2d0f ("hw/riscv/riscv-iommu.c: fix fault type for spa_fetch() faults") Fixes: 12422e1f4493 in 10.0.x Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Message-ID: <20260717144525.1154204-1-andrew.jones@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit aa51eec004461f671f878145d3fc921c6cabee48) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 dayshw/riscv/riscv-iommu: fix U-bit check to apply only to leaf S/VS-stage PTEsAndrew Jones
Commit b795ea0ba471 ("hw/riscv/riscv-iommu.c: fault when !PTE_U and no priv access") placed its check ahead of the leaf-vs-non-leaf branch in riscv_iommu_spa_fetch(), so it fires on every PTE walked, including non-leaf/table entries. Per the RISC-V privileged spec's address translation algorithm (Sv39/Sv48/etc., the "leaf PTE has been reached" step, followed separately by the U-bit permission check), the U bit is only defined and checked for the leaf PTE reached at the end of the walk -- non-leaf PTEs don't carry a meaningful U bit at all. Move the check after the leaf/non-leaf branch, alongside the other leaf-only checks, mirroring how the G_STAGE U-bit check (added in 9158c900ab30) is already correctly placed. Fixes: b795ea0ba471 ("hw/riscv/riscv-iommu.c: fault when !PTE_U and no priv access") Fixes: 5952919d777c in 10.0.x 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> Message-ID: <20260717112340.1071148-1-andrew.jones@oss.qualcomm.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit f16fd27b3fe3c305d95c61d3516e458c45c6e8c9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 daysdisas/riscv: Decode unsigned vector immediates as unsignedTANG Tiancheng
rv_codec_v_i decodes all .vi operands with operand_vimm(), which sign-extends bits 19:15. That matches spec operands named imm, but not the .vi forms whose operand is uimm; uimm=31 is decoded as -1 and printed by the shared 6-bit 'u' formatter as 63. Add rv_codec_v_i_u/operand_vuimm() for the 5-bit uimm forms: vsll.vi, vsrl.vi, vsra.vi, vnsrl.wi, vnsra.wi, vssrl.vi, vssra.vi, vnclipu.wi, vnclip.wi, vslideup.vi, vslidedown.vi, vrgather.vi, vaeskf1.vi, vaeskf2.vi, vsm3c.vi, vsm4k.vi and vwsll.vi. The remaining rv_codec_v_i entries are the signed imm forms. Fixes: 07f4964d1785 ("disas/riscv.c: rvv: Add disas support for vector instructions") Fixes: 9d92f56d4a44 ("disas/riscv: Add support for vector crypto extensions") Signed-off-by: TANG Tiancheng <lyndra@linux.alibaba.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20260703-b4-disas-xthead-fix-riscv-next-v4-4-84c566330bc7@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 00cec77a7f9f80eb6dc8f0c27009403729e3641e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 daysdisas/riscv: Use signed type for vector immediatesTANG Tiancheng
operand_vimm() sign-extends the 5-bit vector immediate field in bits 19:15, but returns uint32_t. This sends negative immediates through an unsigned type before they are assigned to rv_decode.imm. Return int32_t to match the signed value extracted by the helper. Signed-off-by: TANG Tiancheng <lyndra@linux.alibaba.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20260703-b4-disas-xthead-fix-riscv-next-v4-3-84c566330bc7@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 7899d3c6bdb008dd301b474f3524bad5f37a411e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 daysdisas/riscv: Fix 6-bit immediate extractionTANG Tiancheng
rv_codec_r2_imm6 is used for XThead instructions whose 6-bit immediate field is encoded in bits 25:20. The old expression left-shifted by 38 and then right-shifted by 60, so it kept only bits 25:22. Use extract32() to decode bits 25:20 directly. This fixes the immediate printed for th.srri and th.tst. Fixes: 318df7238b9f ("disas/riscv: Add support for XThead* instructions") Suggested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: TANG Tiancheng <lyndra@linux.alibaba.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20260703-b4-disas-xthead-fix-riscv-next-v4-2-84c566330bc7@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 7a8454ef293085a45686929577b7d5a5daded242) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 daysdisas/riscv: Fix th.srri decodingTANG Tiancheng
target/riscv/xthead.decode defines th.srri as funct6=000100 in bits 31:26, with the 6-bit immediate in bits 25:20. decode_xtheadbb() switches on bits 31:25, i.e. funct6 plus imm[5]. Therefore valid th.srri encodings are 0001000 and 0001001. The current 0000100 and 0000101 cases use the wrong funct6 value and decode valid th.srri instructions as illegal. Fix the cases to match funct6=000100 with both imm[5] values. Fixes: 318df7238b9f ("disas/riscv: Add support for XThead* instructions") Signed-off-by: TANG Tiancheng <lyndra@linux.alibaba.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20260703-b4-disas-xthead-fix-riscv-next-v4-1-84c566330bc7@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 6985cfc87512e96c0abfa7fffc836e7bd3889048) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 daystarget/riscv: use SXL instead of MXL for read_sstatusAbhigyan Kumar
According to the RISC-V spec, a 64-bit system can have M-mode in 64-bit with S-mode being 32-bit (SXL bits or mstatus[35:34] being 1). In this case, read_sstatus should use SXL. QEMU doesn't allow changing the SXL bits in mstatus in M-mode. This was because of the missing MSTATUS64_SXL mask in write_mstatus. Now, both the SXL field in mstatus can be safely modified in M-mode and read_sstatus correctly uses SXL not MXL. Fixes: b550f89457 ("target/riscv: Compute mstatus.sd on demand") Signed-off-by: Abhigyan Kumar <314abh@gmail.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Message-ID: <20260723142254.1683113-1-314abh@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit ebef6685a1a29b0b106b6ff3931ffc22c489e0ae) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 daystarget/riscv: Fix PC sync in trans_sspopchk for CFI exception handlingMax Chou
Move gen_update_pc call before conditional logic to ensure consistent PC state regardless of execution path. Previously, the host instructions generated to update the cpu_pc were only executed in the failure path when shadow stack validation failed. This created inconsistent PC synchronization. This inconsistency caused issues in CF_PCREL mode where subsequent instructions calculated wrong relative offsets from stale pc_save values, and could lead to incorrect exception return addresses. This fix ensures PC is always synchronized before any helper that might raise an exception, maintaining consistent translator state across all execution paths. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4118 Signed-off-by: Max Chou <max.chou@sifive.com> [ahshehab: rebased on current master; file moved to target/riscv/tcg/insn_trans/ and the ssp load is now 64-bit wide] Tested-by: A-Shehab <ahshehab24@gmail.com> Signed-off-by: A-Shehab <ahshehab24@gmail.com> Reviewed-by: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com> Message-ID: <20260730181852.1622-1-ahshehab24@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 4a884ba94b43f5b2a640f4ea882655503f9ae954) (Mjt: back-port the changes back to 11.0.x, to the original patch state) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
14 dayshw/watchdog: Add lower bound check for watchdogNumberChinmay Rath
Add missing lower bound check for H_WATCHDOG H_CALL's watchdogNumber parameter as per PAPR documentation ver 12.10.00 section 14.15.5 'H_WATCHDOG'. Closes : https://gitlab.com/qemu-project/qemu/-/work_items/3600 Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com> Reported-by: huntr bubble <bubblehuntr@gmail.com> Signed-off-by: Chinmay Rath <rathc@linux.ibm.com> Link: https://lore.kernel.org/qemu-devel/20260818104551.76023-1-rathc@linux.ibm.com [harshpb: corrected title prefix to hw/watchdog] Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> (cherry picked from commit eea4de1bd8e8bdaa9a69b130a1a154f7c113979f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-21tcg: Export tcg_gen_ussub_i{32,64,tl}Richard Henderson
Move from tcg-op-gvec.c to tcg-op.c. Use a temporary, to cover the possibility of operand overlap. (Cc for stable as this is a prerequisite for the bug fix in the next commit.) Cc: qemu-stable@nongnu.org Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Message-id: 20260811191540.79882-2-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit b4f6f672a3e100706ddc249c26c2c149cdac1636) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-21tcg: Defer tb_flush when initial thread region alloc failsRichard Henderson
A vCPU hotplug may happen at any time. When the new thread is started, the region pool may be exhausted. Do not abort. Rename tcg_region_thread_initial_alloc to differentiate it from tcg_region_initial_alloc__locked. The renamed function now uses tcg_region_alloc__locked and is prepared for failure. In tcg_tb_alloc, allow code_gen_ptr to be NULL. Treat that as any other region exhaustion. Reorg with while instead of goto. Tested-by: Yogesh Vyas <yvyas1991@gmail.com> Reviewed-by: Yogesh Vyas <yvyas1991@gmail.com> Reported-by: Anushree Mathur <anushree.mathur@linux.ibm.com> Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/2984 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit f5d2d8532f3c3cefb644fe9c1866a21b75f76faf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-21tcg: Return success from tcg_region_allocRichard Henderson
Invert the sense of the boolean result from 'error' to 'success'. Tested-by: Yogesh Vyas <yvyas1991@gmail.com> Reviewed-by: Yogesh Vyas <yvyas1991@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit fcdbc78ad4dea4b6baac581be5f7350ce47dc218) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-21tcg: Return success from tcg_region_alloc__lockedRichard Henderson
Invert the sense of the boolean result from 'error' to 'success'. Tested-by: Yogesh Vyas <yvyas1991@gmail.com> Reviewed-by: Yogesh Vyas <yvyas1991@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit e131c28b6eb24c0b7f7f21591b2b2c7568267337) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-21target/loongarch: check FPE before reading fcc in bceqz/bcnezJan Mercl
gen_cz_bc() loads env->cf[cj] without CHECK_FPE, unlike every other translator that touches an fcc register (trans_fcmp.c.inc and trans_fmov.c.inc, for movcf2gr/movgr2cf/movcf2fr/movfr2cf/fsel). A guest that manages the FPU lazily -- Linux clears CSR.EUEN.FPE in lose_fpu() on every context switch -- relies on the next fcc access raising a Floating-Point-Disabled exception so the kernel can restore that task's fcc. Because bceqz and bcnez never raise it, they branch on the condition flag left behind by whichever task last owned the FPU. Real Loongson hardware does raise the exception, so this is TCG-only. It surfaces as Go binaries dying at startup in runtime.check() with "fatal error: float64nan1" -- roughly one process start in a thousand once the guest has more runnable tasks than vCPUs -- and in general as a conditional branch silently taking the wrong path. With four tasks each executing 5M bcnez on a 2-vCPU guest, master mispredicts 89 of 20000000. With this patch, 0 of 100000000 over five runs; a Loongson-3C5000 is likewise 0 of 600000000. CHECK_FPE is defined in trans_farith.c.inc, which translate.c includes before trans_branch.c.inc, so it is already in scope. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4209 Cc: qemu-stable@nongnu.org Signed-off-by: Jan Mercl <0xjnml@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20260819132422.5164-1-0xjnml@gmail.com> Signed-off-by: Song Gao <gaosong@loongson.cn> (cherry picked from commit 215a4fc08f2aafce54c168cf41c64c79187430c1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-21meson: make linker warnings non-fatal on LinuxPaolo Bonzini
These cause a werror=true build to fail with Meson 1.12.0, as it now makes linker warnings fatal as well. Cc: qemu-stable@nongnu.org Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 501187d0bc62a46628acc25e0ea0187094f04246) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-21serial: clear transmit retry callback on unrealizePaolo Bonzini
The GSource is removed when resetting but remains active (and can cause use-after-free) on hot-unplug. Remove it before the character device is disconnected. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4125 Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit eb3f7fe382babbab44419603e81da56abb91d11a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-21target/i386: decode opcode extensions group 3 /1 as TESTAndrey Polivoda
According to Table A-6 in Volume 3 of AMD64 Architecture Programmer's Manual, opcodes F6 and F7 (opcode extensions group 3) with ModRM's reg field values of 0 and 1 can be used to encode a TEST instruction. Although Intel 64 and IA-32 Architectures Software Developer's Manual leaves the cell 1 of opcode extensions group 3 blank in the opcode table (Table A-6, Volume 2D), the instruction in a group 3 with reg field of ModRM byte set to 1 actually behaves like TEST instruction on Intel CPUs. Currently, QEMU decodes group 3 instruction as TEST only if reg field of ModRM byte is 0. When the reg field is 1, QEMU raises a #UD exception. This behavior does not match real Intel and AMD hardware. This patch fixes this issue by duplicating the existing [0x00] and [0x08] X86_OP_ENTRYrr(AND, ...) entries into slots [0x01] and [0x09] in the opcodes_grp3 table. Fixes: d7c41a60d0c5 ("target/i386: move C0-FF opcodes to new decoder (except for x87)") Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3580 Signed-off-by: Andrey Polivoda <apolivodaa433@gmail.com> Cc: qemu-devel@nongnu.org Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Link: https://lore.kernel.org/r/20260621032524.1138213-1-apolivodaa433@gmail.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 380b9596181760f371713604ea3472c56c19deb9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-21target/i386: allow transition to virtual-8086 mode only if CPL == 0 and CPU ↵Andrey Polivoda
is not in long mode According to the pseudocode for the IRET instruction in both the Intel 64 and IA-32 Architectures Software Developer's Manual and the AMD64 Architecture Programmer's Manual, a transition to virtual-8086 mode is allowed only if all of the following conditions are met: 1. The new EFLAGS.VM bit is set to 1. 2. The Current Privilege Level (CPL) is 0. 3. The CPU is in protected mode (and not in long mode). Currently, QEMU performs only the first check. This omission allows a transition to virtual-8086 mode from long mode, and also enables the guest's userspace to trigger this switch. During a legitimate transition, the EFLAGS register is updated in a way that allows modification of sensitive fields, such as IOPL and IF (which is expected, as only privileged code should be able to initiate this transition). However, due to the lack of appropriate checks, an unprivileged guest userspace process can now force this transition and freely modify these fields. This allows the userspace to: 1. Disable interrupts, preventing other processes from running on the CPU. 2. Gain direct hardware I/O access by elevating EFLAGS.IOPL to 3. 3. Crash the guest kernel by setting CS and SS to resemble segments with RPL = 0 and triggering an exception. Since the kernel is unaware that the process entered virtual-8086 mode, it will misinterpret the exception as originating from kernel space. This patch fixes this bug by adding the missing CPL and long mode checks before jumping to the `return_to_vm86` label. Fixes: 90a9fdae1f1a ("more ring 0 operations") Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3583 Signed-off-by: Andrey Polivoda <apolivodaa433@gmail.com> Cc: qemu-devel@nongnu.org Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Link: https://lore.kernel.org/r/20260622082119.11903-1-apolivodaa433@gmail.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 36f634fe4ab6b266031164ab8d1160e6d11addda) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-21target/i386: fix long mode segment override prefix decodingCraaijo, Jos
On x86, the ES/CS/SS/DS segment override prefixes are null prefixes in long mode, and should be ignored. (AMD APM Volume 3, Section 1.2.4) This patch fixes the prefix decoding to correctly ignore the prefixes in 64-bit mode. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3391 Signed-off-by: Jos Craaijo <jos.craaijo@ou.nl> Tested-by: Yudistira Putra <pyudistira519@gmail.com> Link: https://lore.kernel.org/r/20260623-fix-x86-long-mode-segment-override-decoding-v1-1-26d9d4b5804e@ou.nl Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 3589cd995b4facf34071e944fd8ec2294524e25a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-21target/i386: fix incorrect decoding of EXTRQ_iSimon Scherer
The decoding of the extrq instruction with an immediate operand (EXTRQ_i) is incorrect. Per the AMD manual the instruction encoding looks as follows: EXTRQ xmm1, imm8, imm8 66 0F 78 /0 ib ib The /0 indicates that the "Reg" field of the ModR/M byte must be equal to 0 and the XMM register operand is specified by the "R/M" field. However, qemu incorrectly uses the "Reg" field to extract the register operand. This patch instead extracts the XMM register operand from the "R/M" field. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3611 Signed-off-by: Simon Scherer <scherer.simon89@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Link: https://lore.kernel.org/r/20260625155613.192643-1-scherer.simon89@gmail.com [Check for the reg field to be 0. Make decoding of REPZ+66 consistent between 0F 78 and 0F 79. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit ce0ee66044be066cbbf076a7530fe4e8f638f847) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-21target/i386: Clear OF, SF, and AF for fcomi/fucomiSimon Scherer
helper_fcomi_ST0_FT0() and helper_fucomi_ST0_FT0() only cleared CC_Z, CC_P, and CC_C before merging in the comparison result, leaving CC_O, CC_S, and CC_A untouched from whatever they were set to beforehand. The Intel SDM documents FCOMI/FCOMIP/FUCOMI/FUCOMIP as setting OF, SF, and AF to 0 unconditionally. The AMD manual doesn't mention them at all. However, testing on multiple real Intel and AMD systems confirms all three are unconditionally cleared regardless of the comparison result or their prior value. Since fcomi_ccval[] only ever contains CC_C, CC_Z, 0, or CC_Z|CC_P|CC_C, and CC_O|CC_S|CC_Z|CC_A|CC_P|CC_C already covers every flag bit, CC_SRC can be assigned from fcomi_ccval[ret + 1] directly instead of ORing it into a masked cpu_cc_compute_all() result. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4133 Signed-off-by: Simon Scherer <scherer.simon89@gmail.com> Link: https://lore.kernel.org/r/20260807062831.19618-1-scherer.simon89@gmail.com Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 0924d9d3db3617f49ba9282acc6d85b349404ce6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-21target/i386: Use correct type for get_float_exception_flags() valuesPeter Maydell
The softfloat get_float_exception_flags() function returns 'int', but in various places in target/i386 we incorrectly store the returned value into a uint8_t. This currently has no ill effects because i386 doesn't care about any of the float_flag enum values above 0x40. However, we want to start using float_flag_input_denormal_used, which is 0x4000. Switch to using 'int' so that we can handle all the possible valid float_flag_* values. This includes changing the return type of save_exception_flags() and the argument to merge_exception_flags(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250519145114.2786534-3-peter.maydell@linaro.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 397ef415cad11c91318b512ecfaa27679ea7e351) (Mjt: pick this for 10.0.x also so that subsequent changes to apply cleanly) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-20tcg/optimize: Fix s_mask computation for shiftsRichard Henderson
Skip s_mask computation for logical right shift. Cc: qemu-stable@nongnu.org Fixes: 93a967fbb57 ("tcg/optimize: Propagate sign info for shifting") Reported-by: Jacob Young <jacobly@ziglang.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 5fe51606146cbf04dac07bf27256febbe56881e7) (Mjt: back-port to 10.0 across v10.0.0-1791-g03329e3ce460 "tcg/optimize: Build and use o_bits in fold_shift" and v10.0.0-425-g74dbd36f1f87 "tcg: Merge INDEX_op_shr_{i32,i64}") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-20tcg/optimize: INDEX_op_mul is commutativeRichard Henderson
Cc: qemu-stable@nongnu.org Fixes: 7a2f7084525 ("tcg/optimize: Sink commutative operand swapping into fold functions") Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 3181e53c13a1a68e2b54c94b1766f8e384c01b4c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17hw/elf_ops: defend against weird elf headersAlex Bennée
According to the ELF spec: PT_LOAD The array element specifies a loadable segment, described by p_filesz and p_memsz. The bytes from the file are mapped to the beginning of the memory segment. If the segment's memory size (p_memsz) is larger than the file size (p_filesz), the ``extra'' bytes are defined to hold the value 0 and to follow the segment's initialized area. The file size may not be larger than the memory size. Loadable segment entries in the program header table appear in ascending order, sorted on the p_vaddr member. which implies while both p_filesz and p_memsz can be zero we should never see a case where p_filesz is greater than the in memory size. Indeed it has been reported such a hand crafted ELF can blow up, for example during rom_reset(): address_space_set(rom->as, rom->addr + rom->datasize, 0, rom->romsize - rom->datasize, MEMTXATTRS_UNSPECIFIED); which could trigger and underflow leaving QEMU slowly filling a very large buffer. Cc: qemu-stable@nongnu.org Fixes: https://gitlab.com/qemu-project/qemu/-/work_items/4056 Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Message-ID: <20260812081405.3811787-1-alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> (cherry picked from commit 260d49d8e28378b1f4f6c255c15cc20617726920) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17hw/nvme: add SPDM_SOCKET Kconfig dependencyStefan Hajnoczi
The NVMe emulation code unconditionally calls spdm_socket_*() APIs. Add a Kconfig dependency to avoid build errors when NVME_PCI is enabled without SPDM_SOCKET. Fixes: 4f947b10d52 ("hw/nvme: Add SPDM over DOE support") Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Message-ID: <20260810214846.76805-1-stefanha@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> (cherry picked from commit 6dab35f5492b04083f70726a3048d89d8deb4a32) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17hw/block/pflash_cfi01: Restore ROMD mode after migrationBin Guo
pflash_post_load() did not restore the ROMD mode of the memory region. Although cmd and wcycle are migrated, the destination retains the default ROMD = true from realize. When the source was in a non-array mode (e.g. ID read, cmd = 0x90), reads on the destination bypass pflash_read() via the ROM fast path and return raw storage bytes instead of the command-specific response. Derive ROMD from the migrated cmd/wcycle in pflash_post_load. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4042 Cc: qemu-stable@nongnu.org Signed-off-by: Bin Guo <guobin@linux.alibaba.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMD: Including review comments from https://lore.kernel.org/qemu-devel/CAFEAcA-P6RH7nJK0KQ1H8576ULFA7nocB0EkhhZf6Rw3g0WCag@mail.gmail.com/ Confirming that this is correct is a bit tricky. It relies on: * when we set romd mode to true we also set wcycle = 0, cmd = 0 (which we do, in reset and in the mode_read_array code) * when we set romd mode to false at the top of pflash_write(), all paths out of that function either go through the mode_read_array path, or else update pfl->cmd to something non-zero * nowhere outside pflash_write() udpates cmd or wcycle except for the "clear them to 0 and set romd mode" places This is almost but not quite true. In pflash_read(), the default case for the pfl->cmd switch sets wcycle = 0 cmd = 0 but doesn't change the romd state. Luckily the "this should never happen" comment is true -- there's no way to get a pfl->cmd that falls into the default (except for being deliberately fed a bogus value via inbound migration). ] Message-ID: <20260803041808.58174-1-guobin@linux.alibaba.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> (cherry picked from commit 60d010f66f2ad7c15388a605e6f1a2114dc60185) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17hw/net/rtl8139: Send whole of vlan-tagged packet when doing loopbackPeter Maydell
In rtl8139_transfer_frame(), if we are transmitting a frame over loopback then we do this by calling qemu_receive_packet(). If we have an iovec rather than a simple buffer (which happens only when we're sending a packet where we are inserting a vlan tag), we have to convert this into a simple buffer first using iov_to_buf(). However, when we do this we forget to also update the 'size' local variable to the size of the new simple buffer, so we will truncate the packet by 4 bytes (the size of the vlan tag). Correct the logic so we don't truncate vlan-tagged packets when sending them over loopback. Cc: qemu-stable@nongnu.org Reported-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Bin Meng <bin.meng@processmission.com> Message-ID: <20260731093618.2961031-3-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> (cherry picked from commit f3a10c1c454789ad6bb0633118019f4c6544b4b3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17hw/net/rtl8139: Fix handling of VLAN tags on incoming short packetsPeter Maydell
The rtl8139 receive code handles VLAN tags in incoming packets by copying the VLAN tag to a special field in the receive descriptor, and copying only the actual payload data to the receive buffer. This code tries to ensure that it pads out the payload to at least MIN_BUF_SIZE bytes. In commit 63b901bfd30 we removed the main "pad short frames" code from this device because we switched to requiring net backends to do the padding. However we didn't notice that this broke the VLAN tag handling, which relied on the old code making the buffer at least MIN_BUF_SIZE + VLAN_HLEN bytes so that it could copy MIN_BUF_SIZE bytes into the receive buffer even after removing the VLAN tag. The result is that the guest can make us read 4 bytes off the end of a buffer by feeding itself a suitable short packet in loopback mode. The old behaviour is actually not correct, because the IEEE802.1Q standard says that the minimum ethernet frame size remains 64 bytes including the 4 checksum bytes, and so when a tag is present the payload data only needs to be 56 bytes. (A bridge implementation can choose to pad tagged frames out to 68 bytes, but it doesn't have to, and so all devices have to correctly handle incoming tagged frames that are 64 bytes long.) The RTL8139 datasheet isn't very communicative on this topic, but there's nothing that suggests it adds extra padding on receive that didn't exist in the incoming packet. Drop the last remnants of the padding handling from this device; this avoids overcopying into the guest when we receive a short VLAN tagged packet. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3518 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Bin Meng <bin.meng@processmission.com> Message-ID: <20260731093618.2961031-2-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> (cherry picked from commit 59fc7b747d56652e09708adff3afaca326e85a2a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17tests/qtest/ahci: regression test for ATAPI read vs. drainDenis V. Lunev
Add /ahci/cdrom/drain/{pio,dma}: issue a multi-sector ATAPI read whose byte-count limit spans two sectors so the device must rebuffer in the middle of the DRQ burst, hold the backend read in flight with a blkdebug delay, and fire x-blockdev-set-iothread -- which runs bdrv_drain_all_begin() exactly like a guest reset does through virtio_blk_stop_ioeventfd(). On the unfixed PIO path the nested sector fetch is queued behind the drain and the main loop wedges, so the test hangs. The DMA variant never rebuffers and serves as a sanity twin. Signed-off-by: Denis V. Lunev <den@openvz.org> (cherry picked from commit be1ee6a8f6e3b7192d57e900497b81a048f8d193) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17hw/ide/atapi: read the whole elementary transfer asynchronouslyDenis V. Lunev
An ATAPI PIO read whose byte-count limit spans more than one CD sector must fetch the later sectors of a DRQ burst from inside the completion of the first, asynchronous read. cd_read_sector_sync() did this with a synchronous blk_pread(), which runs blk_wait_while_drained() before issuing the request. If a drain is in progress when that completion runs -- as happens when a guest reset reaches virtio_blk_stop_ioeventfd() -> bdrv_drain_all_begin() while an ATAPI read is in flight on the same QEMU -- the nested read is queued until the drained section ends while the outer completion still holds blk->in_flight. bdrv_drain_all_begin() then waits forever for that in_flight count to drop: the main loop is wedged in the drain with the BQL held, and every other QMP/monitor operation blocks behind it. Read the whole elementary transfer in a single asynchronous request up front instead, so no read is ever issued in the middle of a burst. cd_read_sector() now reads all the sectors a burst spans (the raw 2352-byte case is unpacked in place on completion) and cd_read_sector_sync() is removed. The DMA path already batched its reads and is unchanged. Signed-off-by: Denis V. Lunev <den@openvz.org> (cherry picked from commit 12289dc700d910bca4b79bb8de71acff06097489) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17tests/qtest/ahci: cover raw (2352-byte) ATAPI CD readsDenis V. Lunev
Add /ahci/cdrom/{pio,dma}/raw: read several sectors with READ CD in raw mode (atapi_raw), so the ATAPI 2352-byte unpack path is exercised through the AHCI delivery, which IDE coverage does not reach. Each sector's 2048-byte payload is verified at its in-sector offset. The PIO case uses a byte-count limit of one raw sector per DRQ burst: libqos asserts a one-sector PIO transfer, and the multi-sector unpack loop is already covered by the IDE raw test. Signed-off-by: Denis V. Lunev <den@openvz.org> (cherry picked from commit 31f13e71afd1cfb55b02c6977c829f0813ab439c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17tests/qtest/libqos/ahci: support raw (2352-byte) READ CDDenis V. Lunev
ahci_exec() always builds ATAPI commands with a 2048-byte logical sector size, so it cannot drive a READ CD that returns full 2352-byte raw sectors. Add an atapi_raw option that sets the READ CD field-selector to 0xf8 and the command's sector size to 2352 before the transfer is sized, so the derived block count stays correct while the buffer and byte counts cover the raw sectors. Signed-off-by: Denis V. Lunev <den@openvz.org> (cherry picked from commit de86ef3dfd337ec5a74b43d7d042ab937d0166bf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17tests/qtest/ide-test: cover raw (2352-byte) ATAPI CD readsDenis V. Lunev
READ CD with the field-selector set to 0xf8 returns full 2352-byte raw sectors (sync + header + 2048 data + EDC/ECC), driving the ATAPI raw read path that READ10 never touches. Add a send_scsi_cdb_read_cd() helper and a CDROM_RAW flag to cdrom_read_impl(), then exercise both PIO and DMA. The PIO case uses a byte-count limit spanning several raw sectors so the device must rebuffer mid-burst, and each sector's 2048-byte payload is verified at its in-sector offset. Signed-off-by: Denis V. Lunev <den@openvz.org> (cherry picked from commit 502dbdfd9687e967dfe5eefce7123ecf9baa798c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17tests/qtest/ide-test: add a multi-sector ATAPI DMA read testDenis V. Lunev
test_cdrom_pio_large() already exercises a multi-sector PIO read. Add the DMA counterpart through the same cdrom_read_impl() helper so the multi-block ATAPI DMA read path gets equivalent coverage. Signed-off-by: Denis V. Lunev <den@openvz.org> (cherry picked from commit fe543c2d787a611f1efa34107818a8eee90bb5dc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17tests/qtest/ide-test: parametrize the ATAPI CD-ROM read testDenis V. Lunev
cdrom_pio_impl() and test_cdrom_dma() duplicate the same image setup and data-integrity check around two different transfer mechanisms. Fold them into a single cdrom_read_impl(nblocks, flags) helper, with a CDROM_PIO/CDROM_DMA flag selecting the transfer, so further read coverage can be added once for both paths. No functional change: /ide/cdrom/pio, pio_large and dma run exactly as before. Signed-off-by: Denis V. Lunev <den@openvz.org> (cherry picked from commit ebec7c73229831c6574c70fec3cc28c778566277) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17hw/net/vmxnet3: Do not abort if guest provides bad interrupt numbersThomas Huth
vmxnet3_validate_interrupts() currently aborts via hw_error() if the guest provided bad interrupt numbers. This should not happen, QEMU should rather refuse to activate the device in this case instead. Thus propagate the error to the callers to handle it more gracefully there. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/539 Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-ID: <20260731113352.189066-1-thuth@redhat.com> (cherry picked from commit 46099d99005588b25eb07957cd9cdd688c4fc476) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17hw/usb/dev-uas: Don't abort if guest provided an undersized buffer for statusThomas Huth
QEMU currently aborts if the guest provides an undersized buffer for the status packet (8 bytes): hw/usb/core.c:623: usb_packet_copy: Assertion `p->actual_length + bytes <= iov->size' failed. If we hit this situation, log a guest error and continue by simply only providing the bytes that the guest asked for. (Note: This is e.g. similar to the UAS_PIPE_ID_COMMAND case that also clamps the length with: length = MIN(sizeof(iu), p->iov.size)) Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3900 Reported-by: Feifan Qian <bea1e@proton.me> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-ID: <20260730163901.1154791-1-thuth@redhat.com> (cherry picked from commit 15700a66ecb53c52717c913c2c4501372c0115ab) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17hw/intc/loongarch_pch_pic: Validate htmsi_vector before indexing parent_irqBin Guo
pch_pic_update_irq() used the guest-writable htmsi_vector[irq] value as an index into parent_irq[] without checking bounds. A value >= irq_num (64 in the array, but only 32 are used by the virt machine) causes an out-of-bounds read and a guest-triggerable QEMU crash. Validate the vector before calling qemu_set_irq() in both the raise and lower paths and log a guest error if it is out of range. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4114 Cc: qemu-stable@nongnu.org Signed-off-by: Bin Guo <guobin@linux.alibaba.com> Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> (cherry picked from commit 80776c4df92c3d58f89608b61e355092a7d524ed) (Mjt: #include qemu/log.h) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17migration/multifd: Replace assert() with error_setg() in recv pathsPeter Xu
QPL and UADK multifd backends use assert() to validate wire-controlled fields like per-page compressed lengths and packet size consistency. These asserts will stop working with -DNDEBUG builds, so may stop working. Replace all assert() calls in the receive path with proper error_setg() so validation failures are reported gracefully rather than crashing or silently ignored. While at it, touch up an assert() in qatzip recv path too. Cc: qemu-stable <qemu-stable@nongnu.org> Cc: Yuan Liu <yuan1.liu@intel.com> Cc: Yichen Wang <yichen.wang@bytedance.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20260728210417.1925078-4-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com> (cherry picked from commit cf45083edc2b760a952836187aba7ec4139418c0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2026-08-17migration/multifd: Validate next_packet_size in zlib/zstd recvPeter Xu
The zlib and zstd multifd compression backends read next_packet_size from the incoming migration stream and use it directly as the read length into a fixed-size buffer (MULTIFD_PACKET_SIZE * 2 = 1MB). A malicious migration source can set next_packet_size bigger than allocated, causing a heap buffer overflow write on the destination. Add a check against zbuff_len before reading, matching what the qatzip backend already does. Also replace the assert(in_size == 0) for empty packets with proper error reporting, since the value is wire-controlled, meanwhile assert() stops working with -DNDEBUG builds. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3737 Reported-by: xlabai <xlabai@tencent.com> Reported-by: Jules Denardou <jules.denardou@datadoghq.com> Reported-by: Tristan Madani <tristan@talencesecurity.com> Reported-by: david korczynski (@david1766) Reported-by: huntr bubble (@bubblehuntr) Cc: qemu-stable <qemu-stable@nongnu.org> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20260728210417.1925078-3-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com> (cherry picked from commit ac7fa2e9d457ff9c777be32617f3c46548c4cadf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-08 08:39:44 +0000