Branch: refs/heads/staging-10.1
Home: https://github.com/qemu/qemu
Commit: 469b4b6fcbfba47f975d3f6ec61eda169fc580ca
https://github.com/qemu/qemu/commit/469b4b6fcbfba47f975d3f6ec61eda169fc580ca
Author: Kevin Wolf <[email protected]>
Date: 2025-12-07 (Sun, 07 Dec 2025)
Changed paths:
M block/file-posix.c
Log Message:
-----------
file-posix: Handle suspended dm-multipath better for SG_IO
When introducing DM_MPATH_PROBE_PATHS, we already anticipated that
dm-multipath devices might be suspended for a short time when the DM
tables are reloaded and that they return -EAGAIN in this case. We then
wait for a millisecond and retry.
However, meanwhile it has also turned out that libmpathpersist (which is
used by qemu-pr-helper) may need to perform more complex recovery
operations to get reservations back to expected state if a path failure
happened in the middle of a PR operation. In this case, the device is
suspended for a longer time compared to the case we originally expected.
This patch changes hdev_co_ioctl() to treat -EAGAIN separately so that
it doesn't result in an immediate failure if the device is suspended for
more than 1ms, and moves to incremental backoff to cover both quick and
slow cases without excessive delays.
Buglink: https://issues.redhat.com/browse/RHEL-121543
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 2c3165a1a61c299b4a3ae30899e1cc738d20e004)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c27375417d5f60b3df6f35fff10a6b6c0baf2af7
https://github.com/qemu/qemu/commit/c27375417d5f60b3df6f35fff10a6b6c0baf2af7
Author: Richard Henderson <[email protected]>
Date: 2025-12-07 (Sun, 07 Dec 2025)
Changed paths:
M tcg/tcg-op-ldst.c
Log Message:
-----------
tcg: Zero extend 32-bit addresses for TCI
For native code generation, zero-extending 32-bit addresses for
the slow path helpers happens in tcg_out_{ld,st}_helper_args,
but there isn't really a slow path for TCI, so that didn't happen.
Make the extension for TCI explicit in the opcode stream,
much like we already do for plugins and atomic helpers.
Cc: [email protected]
Fixes: 24e46e6c9d9 ("accel/tcg: Widen tcg-ldst.h addresses to uint64_t")
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 41706d3e72d651edb03b4a06b02b490bec8a3ddf)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7a08ce041983bf578bd848bdb160161c508d60b9
https://github.com/qemu/qemu/commit/7a08ce041983bf578bd848bdb160161c508d60b9
Author: Michael Tokarev <[email protected]>
Date: 2025-12-07 (Sun, 07 Dec 2025)
Changed paths:
M .gitlab-ci.d/cirrus.yml
Log Message:
-----------
gitlab-ci.d/cirrus: Update the FreeBSD job to v14.3
The FreeBSD 14.2 job fails since the image disappeared
from the cloud. We already bumped FreeBSD image to 14.3
in tests/vm in c8958b7eb4 (part of v10.1.0).
Signed-off-by: Michael Tokarev <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Tested-by: Alex Bennée <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
(cherry picked from commit 7e71b8e7f2f658999fd6d0871cab3acad53150e7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1dfa2156a955ad730f7dd87473947cd4bc968f6b
https://github.com/qemu/qemu/commit/1dfa2156a955ad730f7dd87473947cd4bc968f6b
Author: Alex Bennée <[email protected]>
Date: 2025-12-07 (Sun, 07 Dec 2025)
Changed paths:
M .gitlab-ci.d/custom-runners.yml
R .gitlab-ci.d/custom-runners/ubuntu-22.04-aarch32.yml
R .gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
R .gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml
A .gitlab-ci.d/custom-runners/ubuntu-24.04-aarch32.yml
A .gitlab-ci.d/custom-runners/ubuntu-24.04-aarch64.yml
A .gitlab-ci.d/custom-runners/ubuntu-24.04-s390x.yml
Log Message:
-----------
gitlab: move custom runners to Ubuntu 24.04
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit eafc5f69e621725dcdcedcc1955d820af7abfc82)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8864d375de43e6438f31ccbd84ee98843c298677
https://github.com/qemu/qemu/commit/8864d375de43e6438f31ccbd84ee98843c298677
Author: Alex Bennée <[email protected]>
Date: 2025-12-10 (Wed, 10 Dec 2025)
Changed paths:
M target/arm/tcg/tlb_helper.c
Log Message:
-----------
target/arm: handle unaligned PC during tlb probe
PC alignment faults have priority over instruction aborts and we have
code to deal with this in the translation front-ends. However during
tb_lookup we can see a potentially faulting probe which doesn't get a
MemOp set. If the page isn't available this results in
EC_INSNABORT (0x20) instead of EC_PCALIGNMENT (0x22).
As there is no easy way to set the appropriate MemOp in the
instruction fetch probe path lets just detect it in
arm_cpu_tlb_fill_align() ahead of the main alignment check. We also
teach arm_deliver_fault to deliver the right syndrome for
MMU_INST_FETCH alignment issues.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3233
Tested-by: Jessica Clarke <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
(cherry picked from commit dd77ef99aa0280c467fe8442b4238122899ae6cf)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7ceeab2dc4b68b7bb77d90be6854bd6e33e72b1e
https://github.com/qemu/qemu/commit/7ceeab2dc4b68b7bb77d90be6854bd6e33e72b1e
Author: Denis V. Lunev <[email protected]>
Date: 2025-12-10 (Wed, 10 Dec 2025)
Changed paths:
M scripts/modinfo-collect.py
Log Message:
-----------
scripts: fix broken error path in modinfo-collect.py
sys.stderr.print is dropped long ago and should not be used. Official
replacement is sys.stderr.write
The problem has been found debugging building on some fancy platform
derived from Debian.
Signed-off-by: Denis V. Lunev <[email protected]>
CC: John Snow <[email protected]>
CC: Cleber Rosa <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 8062bfd517645e0219fe302839fad7231bebf61d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: cee3e62d528bd9295216b0ef4a627d8763135f79
https://github.com/qemu/qemu/commit/cee3e62d528bd9295216b0ef4a627d8763135f79
Author: Hanna Czenczek <[email protected]>
Date: 2025-12-10 (Wed, 10 Dec 2025)
Changed paths:
M hw/virtio/vhost.c
Log Message:
-----------
vhost: Always initialize cached vring data
vhost_virtqueue_start() can exit early if the descriptor ring address is
0, assuming the virtqueue isn’t ready to start.
In this case, all cached vring information (size, physical address,
pointer) is left as-is. This is OK at first startup, when that info is
still initialized to 0, but after a reset, it will retain old (outdated)
information.
vhost_virtqueue_start() must make sure these values are (re-)set
properly before exiting.
(When using an IOMMU, these outdated values can stall the device:
vhost_dev_start() deliberately produces an IOMMU miss event for each
used vring. If used_phys contains an outdated value, the resulting
lookup may fail, forcing the device to be stopped.)
Cc: [email protected]
Signed-off-by: Hanna Czenczek <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 46228925edd53bb0569519538b94e10b85f9c001)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 59bb74c5d62e1a0d3f0f061025e2487613cd132c
https://github.com/qemu/qemu/commit/59bb74c5d62e1a0d3f0f061025e2487613cd132c
Author: Stefan Weil <[email protected]>
Date: 2025-12-10 (Wed, 10 Dec 2025)
Changed paths:
M scripts/nsis.py
Log Message:
-----------
scripts/nsis.py: Tell makensis that WoA is 64 bit
This fixes some settings like the default installation path
for the QEMU installation on Windows on ARM (WoA).
Signed-off-by: Stefan Weil <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit e742b7bdc244499761a21bc1965580c6261a74bf)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6758c408c36f2c8997bc04630e6d8483046be707
https://github.com/qemu/qemu/commit/6758c408c36f2c8997bc04630e6d8483046be707
Author: Kevin Wolf <[email protected]>
Date: 2025-12-16 (Tue, 16 Dec 2025)
Changed paths:
M blockdev.c
Log Message:
-----------
block: Fix BDS use after free during shutdown
During shutdown, blockdev_close_all_bdrv_states() drops any block node
references that are still owned by the monitor (i.e. the user). However,
in doing so, it forgot to also remove the node from monitor_bdrv_states
(which qmp_blockdev_del() correctly does), which means that later calls
of bdrv_first()/bdrv_next() will still return the (now stale) pointer to
the node.
Usually there is no such call after this point, but in some cases it can
happen. In the reported case, there was an ongoing migration, and the
migration thread wasn't shut down yet: migration_shutdown() called by
qemu_cleanup() doesn't actually wait for the migration to be shut down,
but may just move it to MIGRATION_STATUS_CANCELLING. The next time
migration_iteration_finish() runs, it sees the status and tries to
re-activate all block devices that migration may have previously
inactivated. This is where bdrv_first()/bdrv_next() get called and the
access to the already freed node happens.
It is debatable if migration_shutdown() should really return before
migration has settled, but leaving a dangling pointer in the list of
monitor-owned block nodes is clearly a bug either way and fixing it
solves the immediate problem, so fix it.
Cc: [email protected]
Reported-by: Thomas Huth <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Tested-by: Thomas Huth <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 307bc43095b8ab1765fd66c26003d5da06681c05)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d763d9b7491940e906aeab0eecee8759c51e8d82
https://github.com/qemu/qemu/commit/d763d9b7491940e906aeab0eecee8759c51e8d82
Author: Hanna Czenczek <[email protected]>
Date: 2025-12-20 (Sat, 20 Dec 2025)
Changed paths:
M block/nvme.c
Log Message:
-----------
nvme: Note in which AioContext some functions run
Sprinkle comments throughout block/nvme.c noting for some functions
(where it may not be obvious) that they require a certain AioContext, or
in which AioContext they do happen to run (for callbacks, BHs, event
notifiers).
Suggested-by: Kevin Wolf <[email protected]>
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit ac3520f599fedee05945ce06bb0f71820a7b2ffc)
(Mjt: pick this comments-only, no-code-changes commit to 10.1.x
so the next change applies cleanly)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e20d07862dff86b38168983f16f2b7a1ae42a442
https://github.com/qemu/qemu/commit/e20d07862dff86b38168983f16f2b7a1ae42a442
Author: Hanna Czenczek <[email protected]>
Date: 2025-12-20 (Sat, 20 Dec 2025)
Changed paths:
M block/nvme.c
Log Message:
-----------
Revert "nvme: Fix coroutine waking"
This reverts commit 0f142cbd919fcb6cea7aa176f7e4939925806dd9.
(this is commit 619c2350fae574af67d371f68f701692d9b8487a in 10.1.3)
Said commit changed the replay_bh_schedule_oneshot_event() in
nvme_rw_cb() to aio_co_wake(), allowing the request coroutine to be
entered directly (instead of only being scheduled for later execution).
This can cause the device to become stalled like so:
It is possible that after completion the request coroutine goes on to
submit another request without yielding, e.g. a flush after a write to
emulate FUA. This will likely cause a nested nvme_process_completion()
call because nvme_rw_cb() itself is called from there.
(After submitting a request, we invoke nvme_process_completion() through
defer_call(); but the fact that nvme_process_completion() ran in the
first place indicates that we are not in a call-deferring section, so
defer_call() will call nvme_process_completion() immediately.)
If this inner nvme_process_completion() loop then processes any
completions, it will write the final completion queue (CQ) head index to
the CQ head doorbell, and subsequently execution will return to the
outer nvme_process_completion() loop. Even if this loop now finds no
further completions, it still processed at least one completion before,
or it would not have called the nvme_rw_cb() which led to nesting.
Therefore, it will now write the exact same CQ head index value to the
doorbell, which effectively is an unrecoverable error[1].
Therefore, nesting of nvme_process_completion() does not work at this
point. Reverting said commit removes the nesting (by scheduling the
request coroutine instead of entering it immediately), and so fixes the
stall.
On the downside, reverting said commit breaks multiqueue for nvme, but
better to have single-queue working than neither. For 11.0, we will
have a solution that makes both work.
A side note: There is a comment in nvme_process_completion() above
qemu_bh_schedule() that claims nesting works, as long as it is done
through the completion_bh. I am quite sure that is not true, for two
reasons:
- The problem described above, which is even worse when going through
nvme_process_completion_bh() because that function unconditionally
writes to the CQ head doorbell,
- nvme_process_completion_bh() never takes q->lock, so
nvme_process_completion() unlocking it will likely abort.
Given the lack of reports of such aborts, I believe that completion_bh
simply is unused in practice.
[1] See the NVMe Base Specification revision 2.3, page 180, figure 152:
“Invalid Doorbell Write Value: A host attempted to write an invalid
doorbell value. Some possible causes of this error are: [...] the
value written is the same as the previously written doorbell value.”
To even be notified of this error, we would need to send an
Asynchronous Event Request to the admin queue (p. 178ff), which we
don’t do, and then to handle it, we would need to delete and
recreate the queue (p. 88, section 3.3.1.2 Queue Usage).
Cc: [email protected]
Reported-by: Lukáš Doktor <[email protected]>
Tested-by: Lukáš Doktor <[email protected]>
Signed-off-by: Hanna Czenczek <[email protected]>
Message-id: [email protected]
Signed-off-by: Stefan Hajnoczi <[email protected]>
(cherry picked from commit b002acacc1d72521351501fa0af81d146106c9ed)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 28db12b336325c7f757637c7c1cc32c6ef425952
https://github.com/qemu/qemu/commit/28db12b336325c7f757637c7c1cc32c6ef425952
Author: Thomas Huth <[email protected]>
Date: 2025-12-20 (Sat, 20 Dec 2025)
Changed paths:
M tests/qemu-iotests/common.rc
Log Message:
-----------
tests/qemu-iotests: Fix check for existing file in _require_disk_usage()
Looks like the "$" has been forgotten here to get the contents of
the FILENAME variable.
Fixes: c49dda7254d ("iotests: Filter out ZFS in several tests")
Signed-off-by: Thomas Huth <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit ab0065e36adf8becd9c1ffceec37ee809ce683af)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 831cf1c18bc71e68bf5adc8e66b25d00b8486e1a
https://github.com/qemu/qemu/commit/831cf1c18bc71e68bf5adc8e66b25d00b8486e1a
Author: Thomas Huth <[email protected]>
Date: 2025-12-20 (Sat, 20 Dec 2025)
Changed paths:
M qga/commands-linux.c
Log Message:
-----------
qga: Fix ubsan warning
When compiling QEMU with --enable-ubsan there is a undefined behavior
warning when running "make check":
.../qga/commands-linux.c:452:15: runtime error: applying non-zero offset 5 to
null pointer
#0 0x55ea7b89450c in build_guest_fsinfo_for_pci_dev
..../qga/commands-linux.c:452:15
Fix it by avoiding the additional pointer variable here and use an
"offset" integer variable instead.
Signed-off-by: Thomas Huth <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Kostiantyn Kostiuk <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Kostiantyn Kostiuk <[email protected]>
(cherry picked from commit 83f6dceb8f5c0a1efe806a9a4905cbc743a8a378)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 46ff6a1ca220506e94532dbc1d91725430b355bf
https://github.com/qemu/qemu/commit/46ff6a1ca220506e94532dbc1d91725430b355bf
Author: Cédric Le Goater <[email protected]>
Date: 2025-12-20 (Sat, 20 Dec 2025)
Changed paths:
M backends/tpm/tpm_passthrough.c
M block/vmdk.c
M block/vvfat.c
M gdbstub/gdbstub.c
M qga/commands-linux.c
M ui/ui-hmp-cmds.c
M util/log.c
Log Message:
-----------
Fix const qualifier build errors with recent glibc
A recent change in glibc 2.42.9000 [1] changes the return type of
strstr() and other string functions to be 'const char *' when the
input is a 'const char *'.
This breaks the build in various files with errors such as :
error: initialization discards 'const' qualifier from pointer target type
[-Werror=discarded-qualifiers]
208 | char *pidstr = strstr(filename, "%");
| ^~~~~~
Fix this by changing the type of the variables that store the result
of these functions to 'const char *'.
[1]
https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690
Signed-off-by: Cédric Le Goater <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 326e620fc0145686124f754194cdc6d0d9b3400d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e436f7bb3679e4f1b73ee18b74134521ad09c635
https://github.com/qemu/qemu/commit/e436f7bb3679e4f1b73ee18b74134521ad09c635
Author: Cédric Le Goater <[email protected]>
Date: 2025-12-20 (Sat, 20 Dec 2025)
Changed paths:
M hw/i386/x86-common.c
Log Message:
-----------
i386: Fix const qualifier build errors with recent glibc
A recent change in glibc 2.42.9000 [1] changes the return type of
strstr() and other string functions to be 'const char *' when the
input is a 'const char *'. This breaks the build in :
../hw/i386/x86-common.c:827:11: error: assignment discards ‘const’ qualifier
from pointer target type [-Werror=discarded-qualifiers]
827 | vmode = strstr(kernel_cmdline, "vga=");
| ^
Fix this by changing the type of the variables that store the result
of these functions to 'const char *'.
[1]
https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit 2f5c96d53409160b11f031b22f2d947f75ab06ab)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9b13c950b9faa99454d23229506a04cb5889b711
https://github.com/qemu/qemu/commit/9b13c950b9faa99454d23229506a04cb5889b711
Author: Cédric Le Goater <[email protected]>
Date: 2025-12-20 (Sat, 20 Dec 2025)
Changed paths:
M tests/vhost-user-bridge.c
Log Message:
-----------
tests/vhost-user-bridge.c: Fix const qualifier build errors with recent glibc
A recent change in glibc 2.42.9000 [1] changes the return type of
strstr() and other string functions to be 'const char *' when the
input is a 'const char *'. This breaks the build in :
../tests/vhost-user-bridge.c: In function ‘vubr_parse_host_port’:
../tests/vhost-user-bridge.c:749:15: error: initialization discards ‘const’
qualifier from pointer target type [-Werror=discarded-qualifiers]
749 | char *p = strchr(buf, ':');
| ^~~~~~
Fix this by using the glib g_strsplit() routine instead of strdup().
[1]
https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690
Suggested-by: Peter Maydell <[email protected]>
Acked-by: Yodel Eldar <[email protected]>
Tested-by: Yodel Eldar <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit e37a0d514a17a660434ea20c0dd84bc6c20ca517)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d15bb0b3e406d737be10dd15a2e232730e35f77f
https://github.com/qemu/qemu/commit/d15bb0b3e406d737be10dd15a2e232730e35f77f
Author: Cédric Le Goater <[email protected]>
Date: 2025-12-20 (Sat, 20 Dec 2025)
Changed paths:
M monitor/hmp.c
Log Message:
-----------
monitor: Fix const qualifier build errors with recent glibc
A recent change in glibc 2.42.9000 [1] changes the return type of
strchr() and other string functions to be 'const char *' when the
input is a 'const char *'. This breaks the build in :
../monitor/hmp.c:589:7: error: assignment discards ‘const’ qualifier from
pointer target type [-Werror=discarded-qualifiers]
589 | p = strchr(type, ':');
| ^
Fix this by changing the type of the variables that store the result
of these functions to 'const char *'.
[1]
https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690
Reviewed-by: Thomas Huth <[email protected]>
Reviewed-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 dfe87815ba450228811f3abc633d7dc02757922e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 05836f5f817ee73fa88687af9fbdcfb2efd9d690
https://github.com/qemu/qemu/commit/05836f5f817ee73fa88687af9fbdcfb2efd9d690
Author: Cédric Le Goater <[email protected]>
Date: 2025-12-20 (Sat, 20 Dec 2025)
Changed paths:
M gdbstub/user.c
Log Message:
-----------
gdbstub: Fix const qualifier build errors with recent glibc
A recent change in glibc 2.42.9000 [1] changes the return type of
strstr() and other string functions to be 'const char *' when the
input is a 'const char *'. This breaks the build in :
../gdbstub/user.c:322:21: error: assignment discards ‘const’ qualifier from
pointer target type [-Werror=discarded-qualifiers]
322 | pid_placeholder = strstr(path, "%d");
| ^
Fix this by changing the type of the variables that store the result
of these functions to 'const char *'.
[1]
https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690
Reviewed-by: Thomas Huth <[email protected]>
Reviewed-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 d7e1df769910da9d832dda86b01fe1363e4f4a3c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ede2f1e49c5e543643daf74f3c12323a3e475315
https://github.com/qemu/qemu/commit/ede2f1e49c5e543643daf74f3c12323a3e475315
Author: Zesen Liu <[email protected]>
Date: 2025-12-20 (Sat, 20 Dec 2025)
Changed paths:
M hw/core/qdev-properties.c
Log Message:
-----------
qdev: fix error handling in set_uint64_checkmask
When specifying lbr_fmt=VALUE in cpu options with an invalid VALUE,
error_setg() gets triggered twice, causing an assertion failure in error_setv()
which requires *errp to be NULL, preventing meaningful error messages from
being displayed.
Fix this by checking visit_type_uint64()'s return value and returning early on
failure, consistent with other property setters like set_string().
Fixes: 18c22d7112a7 (qdev-properties: Add a new macro with bitmask check for
uint64_t property)
Cc: [email protected]
Signed-off-by: Zesen Liu <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
[Add Fixes: and Cc:]
Signed-off-by: Markus Armbruster <[email protected]>
(cherry picked from commit 00829ae3845fd11e56239390924e3e74c3a4c144)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 82a3e0c6f9b4397b19aff475cc2f7e896d6a9b9b
https://github.com/qemu/qemu/commit/82a3e0c6f9b4397b19aff475cc2f7e896d6a9b9b
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: 4029ff773e590a2758493cd5a00417bc26409262
https://github.com/qemu/qemu/commit/4029ff773e590a2758493cd5a00417bc26409262
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: 832f421978084b5e1dc9fa8f3df54b39371b3c37
https://github.com/qemu/qemu/commit/832f421978084b5e1dc9fa8f3df54b39371b3c37
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: 32a8e10684253b6403aafb70866619db7ec9ad39
https://github.com/qemu/qemu/commit/32a8e10684253b6403aafb70866619db7ec9ad39
Author: Cédric Le Goater <[email protected]>
Date: 2026-01-06 (Tue, 06 Jan 2026)
Changed paths:
M tests/functional/test_arm_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: 020288b0929148fde928a65c9db30aed741ff059
https://github.com/qemu/qemu/commit/020288b0929148fde928a65c9db30aed741ff059
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: f71aca857a1ee6b703007ee7270e1933623e68ed
https://github.com/qemu/qemu/commit/f71aca857a1ee6b703007ee7270e1933623e68ed
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: ccb199fc95bee6e851fb01e703a53adcbcf43241
https://github.com/qemu/qemu/commit/ccb199fc95bee6e851fb01e703a53adcbcf43241
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: e0842a3275dcc832f04af436290b546775529d0a
https://github.com/qemu/qemu/commit/e0842a3275dcc832f04af436290b546775529d0a
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: 944741cfa53dfc2496d89ea7fd60f5e3102ae7c3
https://github.com/qemu/qemu/commit/944741cfa53dfc2496d89ea7fd60f5e3102ae7c3
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: 48437a384aaa38e882a8646c4202dd9929426d9e
https://github.com/qemu/qemu/commit/48437a384aaa38e882a8646c4202dd9929426d9e
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: 1b5caf073f49c37ccbc91baad08fc28b0320fb06
https://github.com/qemu/qemu/commit/1b5caf073f49c37ccbc91baad08fc28b0320fb06
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: 1f65eb3d5d6a301ac6d64f721e82813a1c294f76
https://github.com/qemu/qemu/commit/1f65eb3d5d6a301ac6d64f721e82813a1c294f76
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: 3ef571a4da12abfa65d47395177c24dafd31ee10
https://github.com/qemu/qemu/commit/3ef571a4da12abfa65d47395177c24dafd31ee10
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: 4ec12db86e597d69e371809ea56c8aaecc39418c
https://github.com/qemu/qemu/commit/4ec12db86e597d69e371809ea56c8aaecc39418c
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: c51a95908199977677838cf870f7af0e63d08d25
https://github.com/qemu/qemu/commit/c51a95908199977677838cf870f7af0e63d08d25
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: 827c5bfe331c86bf28cc2d8e79b04c877ffc82e8
https://github.com/qemu/qemu/commit/827c5bfe331c86bf28cc2d8e79b04c877ffc82e8
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: 768ad6c12c97310c29b24e112b674ad6335e2005
https://github.com/qemu/qemu/commit/768ad6c12c97310c29b24e112b674ad6335e2005
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: bd792679ca8e6b2332e829cfba15421f501db8e8
https://github.com/qemu/qemu/commit/bd792679ca8e6b2332e829cfba15421f501db8e8
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: 766c34ccf51118b767b43c25201f899a3e10762a
https://github.com/qemu/qemu/commit/766c34ccf51118b767b43c25201f899a3e10762a
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: 2a5702068926db6f6e95108b60fc9805f9757e8c
https://github.com/qemu/qemu/commit/2a5702068926db6f6e95108b60fc9805f9757e8c
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: 43fd7e29babdaf8b4b450095b64d5ddb461531bc
https://github.com/qemu/qemu/commit/43fd7e29babdaf8b4b450095b64d5ddb461531bc
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: eb6ec3d5a83b52b7a03264261327b6d7205ade8a
https://github.com/qemu/qemu/commit/eb6ec3d5a83b52b7a03264261327b6d7205ade8a
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: 4f702110f4044694111eda4b02fcbd16e9b557ef
https://github.com/qemu/qemu/commit/4f702110f4044694111eda4b02fcbd16e9b557ef
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: e39caabd233fe782ee4832a65e273bc396e07435
https://github.com/qemu/qemu/commit/e39caabd233fe782ee4832a65e273bc396e07435
Author: Song Gao <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M target/loongarch/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)
(Mjt: the changes are in target/loongarch/cpu.h in 10.1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 47f5eb44e3cb8671b1a6a4a378ee1e275425fc2f
https://github.com/qemu/qemu/commit/47f5eb44e3cb8671b1a6a4a378ee1e275425fc2f
Author: Song Gao <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M target/loongarch/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)
(Mjt: the changes are in target/loongarch/cpu.c in 10.1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 469308eeb8f1677aa61a424eb9681c3504eeb9d2
https://github.com/qemu/qemu/commit/469308eeb8f1677aa61a424eb9681c3504eeb9d2
Author: Song Gao <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M target/loongarch/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)
(Mjt: the changes are in target/loongarch/cpu.c in 10.1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 86b3d3969935cb056425d6b6f23943ed3b19a5ed
https://github.com/qemu/qemu/commit/86b3d3969935cb056425d6b6f23943ed3b19a5ed
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)
(Mjt: trivial context fix for 10.1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a246fac13b0691cfd2abc9ad27e0b152e05ec84c
https://github.com/qemu/qemu/commit/a246fac13b0691cfd2abc9ad27e0b152e05ec84c
Author: Alex Bennée <[email protected]>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M tests/functional/test_arm_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: c9ac53e1d432140e76693f04c342d5aca8e2c1d2
https://github.com/qemu/qemu/commit/c9ac53e1d432140e76693f04c342d5aca8e2c1d2
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: d32a6bdf2e683a2c0b3a4d03aabcd67184b293c7
https://github.com/qemu/qemu/commit/d32a6bdf2e683a2c0b3a4d03aabcd67184b293c7
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 and AA64PFR2_EL1 definitions)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ac167f2f9d59ee85465ab643298aa99e88a5d13c
https://github.com/qemu/qemu/commit/ac167f2f9d59ee85465ab643298aa99e88a5d13c
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: 56943614f21b2a82827ebf8df0152f5b65f29f1a
https://github.com/qemu/qemu/commit/56943614f21b2a82827ebf8df0152f5b65f29f1a
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]>
Commit: 6cef71135e99dd6a693b047030b994847bc828bc
https://github.com/qemu/qemu/commit/6cef71135e99dd6a693b047030b994847bc828bc
Author: Richard Henderson <[email protected]>
Date: 2026-01-19 (Mon, 19 Jan 2026)
Changed paths:
M bsd-user/syscall_defs.h
Log Message:
-----------
bsd-user: Fix __i386__ test for TARGET_HAS_STAT_TIME_T_EXT
The target test is TARGET_I386, not __i386__.
Cc: Kyle Evans <[email protected]>
Reviewed-by: Warner Losh <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 369c1ba2b7c721341979889841772629b853092b)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/93be9e6bd43e...6cef71135e99
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
