Branch: refs/heads/staging-10.2
Home: https://github.com/qemu/qemu
Commit: b33a56328187f9cc4e90253b9450c0b84dc0cc5d
https://github.com/qemu/qemu/commit/b33a56328187f9cc4e90253b9450c0b84dc0cc5d
Author: Andrew Cooper <[email protected]>
Date: 2025-12-29 (Mon, 29 Dec 2025)
Changed paths:
M target/i386/tcg/user/seg_helper.c
Log Message:
-----------
target/i386: Fix #GP error code for INT instructions
While the (intno << shift) expression is correct for indexing the IDT based on
whether Long Mode is active, the error code itself was unchanged with AMD64,
and is still the index with 3 bits of metadata in the bottom.
Found when running a Xen unit test, all under QEMU. The unit test objected to
being told there was an error with IDT index 256 when INT $0x80 (128) was the
problem instruction:
...
Error: Unexpected fault 0x800d0802, #GP[IDT[256]]
...
Fixes: d2fd1af76777 ("x86_64 linux user emulation")
Signed-off-by: Andrew Cooper <[email protected]>
Link:
https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3160
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 60efba3c1bff0d78632d45c2dc927c5bc7a17ba8)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 59c9137156c1c82060563f679cdb56da5b949ae8
https://github.com/qemu/qemu/commit/59c9137156c1c82060563f679cdb56da5b949ae8
Author: Paolo Bonzini <[email protected]>
Date: 2025-12-29 (Mon, 29 Dec 2025)
Changed paths:
M target/i386/tcg/decode-new.c.inc
Log Message:
-----------
target/i386/tcg: ignore V3 in 32-bit mode
>From the manual: "In 64-bit mode all 4 bits may be used. [...]
In 32-bit and 16-bit modes bit 6 must be 1 (if bit 6 is not 1, the
2-byte VEX version will generate LDS instruction and the 3-byte VEX
version will ignore this bit)."
Cc: [email protected]
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 0db1b556e4bcd7a51f222cda9e14850f88fe3f88)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2af81f12518e69c0d6194fcb1edad00d761a69af
https://github.com/qemu/qemu/commit/2af81f12518e69c0d6194fcb1edad00d761a69af
Author: Alano Song <[email protected]>
Date: 2025-12-31 (Wed, 31 Dec 2025)
Changed paths:
M hw/i2c/imx_i2c.c
Log Message:
-----------
hw/i2c/imx: Fix trace func name error
Signed-off-by: Alano Song <[email protected]>
Fixes: e589c0ea9c9 ("hw/i2c/imx_i2c: Convert DPRINTF() to trace events")
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 3fbadbb3927a92db1932baee0c1188b05c0ac6b1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a7383751c2c462f416eee75c8e477feb44404af7
https://github.com/qemu/qemu/commit/a7383751c2c462f416eee75c8e477feb44404af7
Author: Cédric Le Goater <[email protected]>
Date: 2026-01-06 (Tue, 06 Jan 2026)
Changed paths:
M tests/functional/arm/test_aspeed_gb200nvl_bmc.py
Log Message:
-----------
tests/functional: Fix URL of gb200nvl-bmc image
Commit [1] moved the FW image of the gb200nvl-bmc machine and broke
the associated functional test. Fix that.
[1]
https://github.com/legoater/qemu-aspeed-boot/commit/52451b2472eeb40aa97e131aeea327e9d4a8a78a
Cc: Ed Tanous <[email protected]>
Cc: Patrick Williams <[email protected]>
Tested-by: Philippe Mathieu-Daudé <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit 75bcfb98a13d14beb2ea95fb3c51da01c7102325)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d6b9de8f9ee3828d8e1f70690615b1c191b7101a
https://github.com/qemu/qemu/commit/d6b9de8f9ee3828d8e1f70690615b1c191b7101a
Author: Jie Song <[email protected]>
Date: 2026-01-08 (Thu, 08 Jan 2026)
Changed paths:
M chardev/char-io.c
M chardev/char-socket.c
M include/chardev/char-io.h
M include/chardev/char.h
M monitor/qmp.c
Log Message:
-----------
monitor/qmp: cleanup SocketChardev listener sources early to avoid fd
handling race
When starting a dummy QEMU process with virsh version, monitor_init_qmp()
enables IOThread monitoring of the QMP fd by default. However, a race
condition exists during the initialization phase: the IOThread only removes
the main thread's fd watch when it reaches
qio_net_listener_set_client_func_full(),
which may be delayed under high system load.
This creates a window between monitor_qmp_setup_handlers_bh() and
qio_net_listener_set_client_func_full() where both the main thread and
IOThread are simultaneously monitoring the same fd and processing events.
This race can cause either the main thread or the IOThread to hang and
become unresponsive.
Fix this by proactively cleaning up the listener's IO sources in
monitor_init_qmp() before the IOThread initializes QMP monitoring,
ensuring exclusive fd ownership and eliminating the race condition.
Signed-off-by: Jie Song <[email protected]>
Reviewed-by: Marc-André Lureau <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit e714f1a3d4d1e66b9a3ff4be1ff999c32bbef29e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 682e043b17dab18e7c73adc4156b8c5ec619d740
https://github.com/qemu/qemu/commit/682e043b17dab18e7c73adc4156b8c5ec619d740
Author: Richard Henderson <[email protected]>
Date: 2026-01-13 (Tue, 13 Jan 2026)
Changed paths:
M tcg/optimize.c
Log Message:
-----------
tcg/optimize: Save o_mask in fold_masks_zosa_int
When adding o_mask to this function, we used it in a
couple of places but failed to save it for future use.
Also, update a related comment.
Cc: [email protected]
Fixes: 56f15f67ea1 ("tcg/optimize: Add one's mask to TempOptInfo")
Reported-by: Manos Pitsidianakis <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 7d2d577de0c72f3cf2eb43f1534e908070d3bc47)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b276b2ca228e8a0b1cd01234827be08fb451a8dd
https://github.com/qemu/qemu/commit/b276b2ca228e8a0b1cd01234827be08fb451a8dd
Author: Richard Henderson <[email protected]>
Date: 2026-01-13 (Tue, 13 Jan 2026)
Changed paths:
M tcg/optimize.c
Log Message:
-----------
tcg/optimize: Fix a_mask computation for orc
In computing a_mask, for or, we remove the bits from t1->o_mask
which are known to be zero. For orc, the bits known to be zero
are the inverse of those known to be one.
Cc: [email protected]
Fixes: cc4033ee47c ("tcg/optimize: Build and use zero, one and affected bits in
fold_orc")
Reviewed-by: Pierrick Bouvier <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 08b12bfb8f532dbc62e35c31d081ede1aa12098b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a53ba65fff5d4e944b179715adb0d89f35b5b3a6
https://github.com/qemu/qemu/commit/a53ba65fff5d4e944b179715adb0d89f35b5b3a6
Author: Paolo Bonzini <[email protected]>
Date: 2026-01-13 (Tue, 13 Jan 2026)
Changed paths:
M tcg/optimize.c
Log Message:
-----------
tcg/optimize: Do use affected bits
We inadvertently disabled affected bits optimizations on operations
that use fold_masks_zosa. These happen relatively often in x86 code
for extract/sextract; for example given the following:
mov %esi, %ebp
xor $0x1, %ebp
the optimizer is able to simplify the "extract_i64 rbp,tmp0,$0x0,$0x20"
produced by the second instruction to a move.
Cc: [email protected]
Fixes: 932522a9ddc ("tcg/optimize: Fold and to extract during optimize")
Signed-off-by: Paolo Bonzini <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 23b53ec3a8a279cb5acd5e022b464a4272fe9f8c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f34c0eb054f3a27c39d6068037a77ebf13d9a18f
https://github.com/qemu/qemu/commit/f34c0eb054f3a27c39d6068037a77ebf13d9a18f
Author: Richard Henderson <[email protected]>
Date: 2026-01-13 (Tue, 13 Jan 2026)
Changed paths:
M tcg/riscv/tcg-target.c.inc
Log Message:
-----------
tcg/riscv: Fix TCG_REG_TMP0 clobber in tcg_gen_dup{m,i}
TCG_REG_TMP0 may be used by set_vtype* to load the vtype
parameter, so delay any other use of TCG_REG_TMP0 until
the correct vtype has been installed.
Cc: [email protected]
Fixes: d4be6ee1111 ("tcg/riscv: Implement vector mov/dup{m/i}")
Reported-by: Zhijin Zeng <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit af6db3b71310ea63a018d517ba7d79e4e014db62)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e71e02caa7b89ec0de8caa5aeb6ac11c67726145
https://github.com/qemu/qemu/commit/e71e02caa7b89ec0de8caa5aeb6ac11c67726145
Author: Jean-Christian CÎRSTEA <[email protected]>
Date: 2026-01-13 (Tue, 13 Jan 2026)
Changed paths:
M linux-user/syscall.c
Log Message:
-----------
linux-user: allow null `pathname` for statx()/fstatat()
Since Linux 6.11, the path argument may be NULL.
Before this patch, qemu-*-linux-user failed with EFAULT when `pathname` was
specified as NULL, even for Linux kernel hosts > 6.10. This patch fixes this
issue by checking whether `arg2` is 0. If so, don't return EFAULT, but instead
perform the appropiate syscall and let the host's kernel handle null `pathname`.
Cc: [email protected]
Signed-off-by: Jean-Christian CÎRSTEA <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 82ae60c8b5cb98d610056a1e2d0ba72e9ef7907c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 86ce6e07739b98137e9401076f54a3e89f6a5fbd
https://github.com/qemu/qemu/commit/86ce6e07739b98137e9401076f54a3e89f6a5fbd
Author: Jim MacArthur <[email protected]>
Date: 2026-01-13 (Tue, 13 Jan 2026)
Changed paths:
M linux-user/elfload.c
Log Message:
-----------
linux-user/elfload.c: Correction to HWCAP2 accessor
get_elf_hwcap was used when get_elf_hwcap2 should have been.
Cc: [email protected]
Fixes: fcac98d0ba8b ("linux-user: Remove ELF_HWCAP2")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3259
Signed-off-by: Jim MacArthur <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit c333f9c4ee212297f3b9a8a6ef62396a63c48e61)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a8adf882fd43c1df51ebaa24d17b1720fae9542e
https://github.com/qemu/qemu/commit/a8adf882fd43c1df51ebaa24d17b1720fae9542e
Author: Matthew Lugg <[email protected]>
Date: 2026-01-13 (Tue, 13 Jan 2026)
Changed paths:
M linux-user/mmap.c
Log Message:
-----------
linux-user: fix mremap unmapping adjacent region
This typo meant that calls to `mremap` which shrink a mapping by some N
bytes would, when the virtual address space was pre-reserved (e.g.
32-bit guest on 64-bit host), unmap the N bytes following the *original*
mapping.
Signed-off-by: Matthew Lugg <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit aaed9ca1797d70a507371aea688c5cd60b074e2d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5ac0811f40976bf4339791a43c02516cc087462a
https://github.com/qemu/qemu/commit/5ac0811f40976bf4339791a43c02516cc087462a
Author: Matthew Lugg <[email protected]>
Date: 2026-01-13 (Tue, 13 Jan 2026)
Changed paths:
M linux-user/mmap.c
Log Message:
-----------
linux-user: fix mremap errors for invalid ranges
If an address range given to `mremap` is invalid (exceeds addressing
bounds on the guest), we were previously returning `ENOMEM`, which is
not correct. The manpage and the Linux kernel implementation both agree
that if `old_addr`/`old_size` refer to an invalid address, `EFAULT` is
returned, and if `new_addr`/`new_size` refer to an invalid address,
`EINVAL` is returned.
Signed-off-by: Matthew Lugg <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 2422884ec5a12037d2378f45ca1411d3f37c7081)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 860f8f3f5348bba50b468f50e4fb9030786d6d70
https://github.com/qemu/qemu/commit/860f8f3f5348bba50b468f50e4fb9030786d6d70
Author: Matthew Lugg <[email protected]>
Date: 2026-01-13 (Tue, 13 Jan 2026)
Changed paths:
M linux-user/mmap.c
Log Message:
-----------
linux-user: fix reserved_va page leak in do_munmap
The old logic had an off-by-one bug. For instance, assuming 4k pages on
host and guest, if 'len' is '4097' (indicating to unmap 2 pages), then
'last = start + 4096', so 'real_last = start + 4095', so ultimately
'real_len = 4096'. I do not believe this could cause any observable bugs
in guests, because `target_munmap` page-aligns the length it passes in.
However, calls to this function in `target_mremap` do not page-align the
length, so those calls could "drop" pages, leading to a part of the
reserved region becoming unmapped. At worst, a host allocation could get
mapped into that hole, then clobbered by a new guest mapping.
Signed-off-by: Matthew Lugg <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 81ceab30492ed251addae8539f7b69a069b0f984)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4cc64bd6c4cc11614b30cd7d3d42f6fe4ed47919
https://github.com/qemu/qemu/commit/4cc64bd6c4cc11614b30cd7d3d42f6fe4ed47919
Author: Matthew Lugg <[email protected]>
Date: 2026-01-13 (Tue, 13 Jan 2026)
Changed paths:
M tests/tcg/multiarch/test-mmap.c
Log Message:
-----------
tests: add tcg coverage for fixed mremap bugs
These tests cover the first two fixes in this patch series. The final
patch is not covered because the bug it fixes is not easily observable
by the guest.
Signed-off-by: Matthew Lugg <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 9290c10ae9d0c3ff433efbb7ecb0e781966c5404)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 639ffcbd640e0c08bd4fef548cd6f1834c053ff5
https://github.com/qemu/qemu/commit/639ffcbd640e0c08bd4fef548cd6f1834c053ff5
Author: Fabiano Rosas <[email protected]>
Date: 2026-01-13 (Tue, 13 Jan 2026)
Changed paths:
M hw/ppc/spapr.c
M target/ppc/cpu.h
M target/ppc/cpu_init.c
M target/ppc/machine.c
Log Message:
-----------
target/ppc: Fix env->quiesced migration
The commit referenced (from QEMU 10.0) has changed the way the pseries
machine marks a cpu as quiesced. Previously, the cpu->halted value
from QEMU common cpu code was (incorrectly) used. With the fix, the
env->quiesced variable starts being used, which improves on the
original situation, but also causes a side effect after migration:
The env->quiesced is set at reset and never migrated, which causes the
destination QEMU to stop delivering interrupts and hang the machine.
To fix the issue from this point on, start migrating the env->quiesced
value.
For QEMU versions < 10.0, sending the new element on the stream would
cause migration to be aborted, so add the appropriate compatibility
property to omit the new subsection.
Independently of this patch, all migrations from QEMU versions < 10.0
would result in a hang since the older QEMU never migrates
env->quiesced. This is bad because it leaves machines already running
on the old QEMU without a migration path into newer versions.
As a workaround, use a few heuristics to infer the new value of
env->quiesced based on cpu->halted, LPCR and PSSCR bits that are
usually set/cleared along with quiesced.
Note that this was tested with -cpu power9 and -machine ic-mode=xive
due to another bug affecting migration of XICS guests. Tested both
forward and backward migration and savevm/loadvm from 9.2 and 10.0.
Also tested loadvm of a savevm image that contains a mix of cpus both
halted and not halted.
Reported-by: Fabian Vogt <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3079
Fixes: fb802acdc8b ("ppc/spapr: Fix RTAS stopped state")
Acked-by: Chinmay Rath <[email protected]>
Reviewed-by: Harsh Prateek Bora <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Harsh Prateek Bora <[email protected]>
(cherry picked from commit 628bda1ab7596a7cceb1c5356d23a92001c7a8c5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 920634e4117864f712bdcf7ca0877a6b1fdc5064
https://github.com/qemu/qemu/commit/920634e4117864f712bdcf7ca0877a6b1fdc5064
Author: Paolo Bonzini <[email protected]>
Date: 2026-01-13 (Tue, 13 Jan 2026)
Changed paths:
M configs/meson/windows.txt
Log Message:
-----------
configs: use default prefix for Windows compilation
The update to Python 3.13 causes meson configuration to fail, see e.g.:
https://gitlab.com/qemu-project/qemu/-/jobs/12672816538#L397
meson.build:1:0: ERROR: prefix value '/qemu' must be an absolute path
This is https://github.com/mesonbuild/meson/issues/14303. Remove the
prefix='/qemu' line in configs/meson/windows.txt, since commit d17f305a264
("configure: use a platform-neutral prefix", 2020-09-30) says that the
NSIS installer doesn't care.
Cc: [email protected]
Cc: Thomas Huth <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 894c8bd56ff1d25127efa4ba9ee8cf4dd0670b1a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 359076c8a0120714aa41213267a7a42894676392
https://github.com/qemu/qemu/commit/359076c8a0120714aa41213267a7a42894676392
Author: Laurent Vivier <[email protected]>
Date: 2026-01-16 (Fri, 16 Jan 2026)
Changed paths:
M target/m68k/op_helper.c
Log Message:
-----------
m68k: fix CAS2 writeback when Dc1==Dc2
According to Programmer's Reference Manual, if Dc1 and Dc2 specify the
same data register and the comparison fails, memory operand 1 is stored
in the data register.
The current helpers wrote Dc1 then Dc2, leaving operand 2 in the shared
register.
Swap the writeback order for cas2w/cas2l so memory operand 1 wins.
Signed-off-by: Laurent Vivier <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 11dac41f2e830bcd7ba74969dc50f5740e3ce7e7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 51bc24d4273b5b68ae3e254588f108df8afd1cd1
https://github.com/qemu/qemu/commit/51bc24d4273b5b68ae3e254588f108df8afd1cd1
Author: Paolo Bonzini <[email protected]>
Date: 2026-01-16 (Fri, 16 Jan 2026)
Changed paths:
M target/i386/tcg/decode-new.c.inc
M target/i386/tcg/decode-new.h
Log Message:
-----------
target/i386/tcg: do not mark all SSE instructions as unaligned
If the vex_special field was not initialized, it was considered to be
X86_VEX_SSEUnaligned (whose value was zero). Add a new value to
fix that.
Cc: [email protected]
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 73dd6e4a36dd8d85548292f382a4d479e2810371)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6594e50e7e8518eb247bbcf96dc7a6557f28dd35
https://github.com/qemu/qemu/commit/6594e50e7e8518eb247bbcf96dc7a6557f28dd35
Author: Paolo Bonzini <[email protected]>
Date: 2026-01-16 (Fri, 16 Jan 2026)
Changed paths:
M target/i386/ops_sse.h
M target/i386/tcg/emit.c.inc
M target/i386/tcg/ops_sse_header.h.inc
Log Message:
-----------
target/i386/tcg: mask addresses for VSIB
VSIB can have either 32-bit or 64-bit addresses, pass a constant mask to
the helper and apply it before the load.
Cc: [email protected]
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 5e3572ef2e94608568b1a73eab9d382b250936eb)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 11e286fb93049db0d92d8c411ce046ee3f67ff18
https://github.com/qemu/qemu/commit/11e286fb93049db0d92d8c411ce046ee3f67ff18
Author: Paolo Bonzini <[email protected]>
Date: 2026-01-16 (Fri, 16 Jan 2026)
Changed paths:
M target/i386/tcg/decode-new.c.inc
Log Message:
-----------
target/i386/tcg: allow VEX in 16-bit protected mode
VEX is only forbidden in real and vm86 mode; 16-bit protected mode supports
it for some unfathomable reason.
Cc: [email protected]
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit ed88bdcfbdcf9d411607cd690f93f915feff6a5b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 058e1774d678031ec207441a51efcf8ae94cc6af
https://github.com/qemu/qemu/commit/058e1774d678031ec207441a51efcf8ae94cc6af
Author: Vulnerability Report <[email protected]>
Date: 2026-01-16 (Fri, 16 Jan 2026)
Changed paths:
M hw/i386/kvm/xen_evtchn.c
Log Message:
-----------
hw/i386/kvm: fix PIRQ bounds check in xen_physdev_map_pirq()
Reject pirq == s->nr_pirqs in xen_physdev_map_pirq().
Fixes: aa98ee38a5 ("hw/xen: Implement emulated PIRQ hypercall support")
Fixes: CVE-2026-0665
Reported-by: DARKNAVY (@DarkNavyOrg) <[email protected]>
Reviewed-by: David Woodhouse <[email protected]>
Signed-off-by: Vulnerability Report <[email protected]>
Link:
https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit c7504ba2a560fd884557f6e5142f03b491aad0c7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e12259821c2872d7b7c64043328d70c81158007d
https://github.com/qemu/qemu/commit/e12259821c2872d7b7c64043328d70c81158007d
Author: Xianglai Li <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M hw/loongarch/virt-fdt-build.c
Log Message:
-----------
hw/loongarch/virt: Modify the interrupt trigger type in fdt table
In the loongarch virt fdt file, the interrupt trigger type directly
uses magic numbers. Now, refer to the definitions in the linux kernel and
use macro definitions.
Signed-off-by: Xianglai Li <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
(cherry picked from commit 47de28a0b7fb96531271aaeaa3e7f2cad2b91221)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 21af0baf9aab2e1362bb1d03a94a6911b980866f
https://github.com/qemu/qemu/commit/21af0baf9aab2e1362bb1d03a94a6911b980866f
Author: Xianglai Li <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M hw/loongarch/virt-fdt-build.c
Log Message:
-----------
hw/loongarch/virt: Fix irq allocation failure with pci device from fdt
When we use the -kernel parameter to start an elf format kernel relying on
fdt, we get the following error:
pcieport 0000:00:01.0: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.0: enabling device (0000 -> 0003)
pcieport 0000:00:01.0: PME: Signaling with IRQ 19
pcieport 0000:00:01.0: AER: enabled with IRQ 19
pcieport 0000:00:01.1: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.1: enabling device (0000 -> 0003)
pcieport 0000:00:01.1: PME: Signaling with IRQ 20
pcieport 0000:00:01.1: AER: enabled with IRQ 20
pcieport 0000:00:01.2: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.2: enabling device (0000 -> 0003)
pcieport 0000:00:01.2: PME: Signaling with IRQ 21
pcieport 0000:00:01.2: AER: enabled with IRQ 21
pcieport 0000:00:01.3: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.3: enabling device (0000 -> 0003)
pcieport 0000:00:01.3: PME: Signaling with IRQ 22
pcieport 0000:00:01.3: AER: enabled with IRQ 22
pcieport 0000:00:01.4: of_irq_parse_pci: failed with rc=-22
This is because the description of interrupt-cell is missing in the pcie
irq map. And there is a lack of a description of the interrupt trigger
type. Now it is corrected and the correct interrupt-cell is added in the
pcie irq map.
Refer to the implementation in arm and add some comments.
Signed-off-by: Xianglai Li <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
(cherry picked from commit ff54394eed148c642f83b45753c7898acdbd5ddb)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b8456254d0100ac6fb5251e53970e076aa0e04ff
https://github.com/qemu/qemu/commit/b8456254d0100ac6fb5251e53970e076aa0e04ff
Author: Song Gao <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M target/loongarch/tcg/tcg_cpu.c
Log Message:
-----------
target/loongach: Fix some exceptions failure in updating CSR_BADV
According to Volume 1 Manual 7.4.8 ,exception,SYS,BRK,INE,IPE,PPD
FPE,SXD,ASXD are need't update CSR_BADV, this patch correct it.
Signed-off-by: Song Gao <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
(cherry picked from commit 70cf9b7bf7aff47f8d85ccce35b688dd91335cf0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7d662d328df35adad1ec5362d1bfba59518402d1
https://github.com/qemu/qemu/commit/7d662d328df35adad1ec5362d1bfba59518402d1
Author: Song Gao <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M target/loongarch/tcg/tcg_cpu.c
Log Message:
-----------
target/loongarch: Fix exception BCE missing to update CSR_BADV
Exception BCE need update CSR_BADV, and the value is env->pc.
Signed-off-by: Song Gao <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
(cherry picked from commit e4f0ef58d53eb20056f9f3ca9f21dbbbf25f2530)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0b92a8a1301f157718d374237defb71bc64dbda4
https://github.com/qemu/qemu/commit/0b92a8a1301f157718d374237defb71bc64dbda4
Author: Song Gao <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M target/loongarch/tcg/tcg_cpu.c
Log Message:
-----------
target/loongarch: Fix exception ADEF/ADEM missing to update CSR_BADV
Exception ADEM/ADEF need update CSR_BADV, the value from the virtual
address.
Signed-off-by: Song Gao <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
(cherry picked from commit a7be2e0a3f7d0f35bcc3b17e2b558084efc5d9fe)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1a1ebc90cdf2c28f6f6e8def713b9f2483ab5357
https://github.com/qemu/qemu/commit/1a1ebc90cdf2c28f6f6e8def713b9f2483ab5357
Author: Yao Zi <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M hw/loongarch/virt.c
Log Message:
-----------
hw/loongarch/virt: Don't abort on access to unimplemented IOCSR
Since commit f2e61edb2946 ("hw/loongarch/virt: Use MemTxAttrs interface
for misc ops") which adds a call to g_assert_not_reached() in the path
of handling unimplemented IOCSRs, QEMU would abort when the guest
accesses unimplemented IOCSRs.
This is too serious since there's nothing fatal happening in QEMU
itself, and the guest could probably continue running if we give zero as
result for these reads, which also matches the behavior observed on
3A5000M real machine.
Replace the assertion with qemu_log_mask(LOG_UNIMP, ...), it's still
possible to examine unimplemented IOCSR access through "-d unimp"
command line arguments.
Fixes: f2e61edb2946 ("hw/loongarch/virt: Use MemTxAttrs interface for misc ops")
Signed-off-by: Yao Zi <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
(cherry picked from commit 49ee001a5b8378e9a9b3db8cbf61e7eda970ecd2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d9dd5dad3116bd5335bbd0be70aff70399d2ade4
https://github.com/qemu/qemu/commit/d9dd5dad3116bd5335bbd0be70aff70399d2ade4
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M hw/arm/max78000fthr.c
Log Message:
-----------
hw/arm: Re-enable the MAX78000FTHR machine in qemu-system-arm/aarch64
Unfortunately while rebasing the series registering the
ARM/Aarch64 machine interfaces and getting it merged as
commit 38c5ab40031 ("hw/arm: Filter machine types for
qemu-system-arm/aarch64 binaries") we missed the recent
addition of the MAX78000FTHR machine in commit 51eb283dd0e.
Correct that.
The effect is that the machine was accidentally disabled.
Cc: [email protected]
Reported-by: Thomas Huth <[email protected]>
Tested-by: Thomas Huth <[email protected]>
Tested-by: Markus Armbruster <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3248
Fixes: 38c5ab40031 ("hw/arm: Filter machine types for single binary")
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit c5712ad83fa4bf2f2a4e8fc9431ad9548bac2b06)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 35abae4511dc68a3b3ab390fbb13bff7b924936a
https://github.com/qemu/qemu/commit/35abae4511dc68a3b3ab390fbb13bff7b924936a
Author: Alex Bennée <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M tests/functional/arm/test_aspeed_rainier.py
Log Message:
-----------
tests/functional: migrate aspeed_rainier image
Cedric has a host for the file which allows us to keep the name.
Cc: [email protected]
Signed-off-by: Alex Bennée <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Message-id: [email protected]
Cc: Cédric Le Goater <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 7cf096d609e67fd06abf6a59e592cb6de427825c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: bcc7fc8f81da20b1880126e253a52626a45aa4f3
https://github.com/qemu/qemu/commit/bcc7fc8f81da20b1880126e253a52626a45aa4f3
Author: Peter Maydell <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Don't specify ID_PFR1 accessfn twice
In the definition of ID_PFR1 we have an ifdef block; we specify the
accessfn once in the common part of the ifdef and once in the
not-user-only part, which is redundant but harmless.
The accessfn will always return success in user-only mode (because
we won't trap to EL2), so specify it only in the not-user-only
half of the ifdef, as was probably the intention.
This is only cc'd to stable to avoid a textual conflict with
the following patch, which is a bug fix.
Cc: [email protected]
Fixes: 0f150c8499e970bd ("target/arm: Constify ID_PFR1 on user emulation")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 8da52b8401afa34ea8caa58e1bfb321ae142899b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5ead00ce111e1e1d96e413b76f00e39ab29209ba
https://github.com/qemu/qemu/commit/5ead00ce111e1e1d96e413b76f00e39ab29209ba
Author: Peter Maydell <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Correctly honour HCR.TID3 for v7A cores
The HCR.TID3 bit defines that we should trap to the hypervisor for
reads to a collection of ID registers. Different architecture versions
have defined this differently:
* v7A has a set of ID regs that definitely must trap:
- ID_PFR{0,1}, ID_DFR0, ID_AFR0, ID_MMFR{0,1,2,3},
ID_ISAR{0,1,2,3,4,5}, MVFR{0,1}
and somewhat vaguely says that "there is no requirement"
to trap for registers that are reserved in the ID reg space
(i.e. which RAZ and might be used for new ID regs in future)
* v8A adds to this list:
- ID_PFR2 and MVFR2 must trap
- ID_MMFR4, ID_MMFR5, ID_ISAR6, ID_DFR1 and reserved registers
in the ID reg space must trap if FEAT_FGT is implemented,
and it is IMPDEF if they trap if FEAT_FGT is not implemented
In QEMU we seem to have attempted to implement this distinction
(taking the "we do trap" IMPDEF choice if no FEAT_FGT), with
access_aa64_tid3() always trapping on TID3 and access_aa32_tid3()
trapping only if ARM_FEATURE_V8 is set. However, we didn't apply
these to the right set of registers: we use access_aa32_tid3() on all
the 32-bit ID registers *except* ID_PFR2, ID_DFR1, ID_MMFR5 and the
RES0 space, which means that for a v7 CPU we don't trap on a lot of
registers that we should trap on, and we do trap on various things
that the v7A Arm ARM says there is "no requirement" to trap on.
Straighten this out by naming the access functions more clearly for
their purpose, and documenting this: access_v7_tid3() is only for the
fixed set of ID registers that v7A traps on HCR.TID3, and
access_tid3() is for any others, including the reserved encoding
spaces and any new registers we add in future.
AArch32 MVFR2 access is handled differently, in check_hcr_el2_trap;
there we already do not trap on TID3 on v7A cores (where MVFR2
doesn't exist), because we in the code-generation function we UNDEF
if ARM_FEATURE_V8 is not set, without generating code to call
check_hcr_el2_trap.
This bug was causing a problem for Xen which (after a recent change
to Xen) expects to be able to trap ID_PFR0 on a Cortex-A15.
The result of these changes is that our v8A behaviour remains
the same, and on v7A we now trap the registers the Arm ARM definitely
requires us to trap, and don't trap the reserved space that "there is
no requirement" to trap.
Cc: [email protected]
Fixes: 6a4ef4e5d1084c ("target/arm: Honor HCR_EL2.TID3 trapping requirements")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 205ca535abaceda375c54797b1129a54a5ebbe96)
(Mjt: trivial context fix around AA64MMFR4_EL1 definition)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6bcd958030d6644d5d6e5da9d7a5e6f51b016e76
https://github.com/qemu/qemu/commit/6bcd958030d6644d5d6e5da9d7a5e6f51b016e76
Author: Peter Maydell <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Correctly trap HCR.TID1 registers in v7A
In v7A HCR.TID1 is defined to trap for TCMTR, TLBTR, REVIDR and AIDR.
We incorrectly use an accessfn for REVIDR and AIDR that only traps on
v8A cores. Fix this by collapsing access_aa64_tid1() and
access_aa32_tid1() together and never doing a check for v8 vs v7.
The accessfn is also used for SMIDR_EL1, which is fine as this
register is AArch64 only.
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit b67a35622f9a816544ec094132d8af0debfac7f2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4131a1d83c69f63dcaec93342fe340fb3ba64a6f
https://github.com/qemu/qemu/commit/4131a1d83c69f63dcaec93342fe340fb3ba64a6f
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M target/i386/nvmm/nvmm-all.c
Log Message:
-----------
accel/nvmm: Fix 'cpu' typo in nvmm_init_vcpu()
Fix typo to avoid the following build failure:
target/i386/nvmm/nvmm-all.c: In function 'nvmm_init_vcpu':
target/i386/nvmm/nvmm-all.c:988:9: error: 'AccelCPUState' has no member named
'vcpu_dirty'
988 | qcpu->vcpu_dirty = true;
| ^~
Cc: [email protected]
Reported-by: Thomas Huth <[email protected]>
Fixes: 2098164a6be ("accel/nvmm: Replace @dirty field by generic
CPUState::vcpu_dirty field")
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Tested-by: Thomas Huth <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Tested-by: Pierrick Bouvier <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 7be4256281f430f726366c92ffdea0b72651de8a)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/698104725efa...4131a1d83c69
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
