Branch: refs/heads/staging-10.0
Home: https://github.com/qemu/qemu
Commit: 64cd8bf8ec40c5c36cf48e11102b47cd660b8778
https://github.com/qemu/qemu/commit/64cd8bf8ec40c5c36cf48e11102b47cd660b8778
Author: Richard Henderson <[email protected]>
Date: 2025-12-06 (Sat, 06 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)
(Mjt: backport to before v10.0.0-521-gaae2456ac0b4 "tcg: Merge
INDEX_op_{ld,st}_{i32,i64,i128}")
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2113a9c32eea380a4d09e000210199183cdcf901
https://github.com/qemu/qemu/commit/2113a9c32eea380a4d09e000210199183cdcf901
Author: Paolo Bonzini <[email protected]>
Date: 2025-12-06 (Sat, 06 Dec 2025)
Changed paths:
M tests/vm/freebsd
Log Message:
-----------
tests/vm: bump FreeBSD image to 14.3
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit c8958b7eb494d06a209b1befb6c34edfbce68867)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5db5c9316cb51af60e8f7dd3133f5706ab9fb4d7
https://github.com/qemu/qemu/commit/5db5c9316cb51af60e8f7dd3133f5706ab9fb4d7
Author: Michael Tokarev <[email protected]>
Date: 2025-12-06 (Sat, 06 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: 3c1cef389686b743fe29467633e4f1373566c93b
https://github.com/qemu/qemu/commit/3c1cef389686b743fe29467633e4f1373566c93b
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: 62a363e7b109ff87ba461ae6896e758b3a38d72c
https://github.com/qemu/qemu/commit/62a363e7b109ff87ba461ae6896e758b3a38d72c
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: 2b70d064400527b3cce09ea8e3e1290c8d3b1d21
https://github.com/qemu/qemu/commit/2b70d064400527b3cce09ea8e3e1290c8d3b1d21
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: 40ea6f440cd4dde8f01d82cc1c2fda5ce944f1cf
https://github.com/qemu/qemu/commit/40ea6f440cd4dde8f01d82cc1c2fda5ce944f1cf
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: 828b5e21ab7426755508d760e7e5878171ec2c94
https://github.com/qemu/qemu/commit/828b5e21ab7426755508d760e7e5878171ec2c94
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: e75a0c85016f84a2bab5be6d5daeb03bd9492892
https://github.com/qemu/qemu/commit/e75a0c85016f84a2bab5be6d5daeb03bd9492892
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.0.x
so the next change applies cleanly)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0f82082447b6bc427ce0d2ea055a6af7156fd09d
https://github.com/qemu/qemu/commit/0f82082447b6bc427ce0d2ea055a6af7156fd09d
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 361bd4a6c8ca57f48dd5a9e590d2c69a87e7dda1 in 10.0.7)
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: ff929715e6c609035a556047d2355c5d190277c5
https://github.com/qemu/qemu/commit/ff929715e6c609035a556047d2355c5d190277c5
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: 4718359e0efc8d7881e294bd638c9b93325536e6
https://github.com/qemu/qemu/commit/4718359e0efc8d7881e294bd638c9b93325536e6
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: 90c640e79c395c6fefb4043b6d9b159ce54961aa
https://github.com/qemu/qemu/commit/90c640e79c395c6fefb4043b6d9b159ce54961aa
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: bb14bf59c328c07d18ca1c078a6cf72a7cbacab6
https://github.com/qemu/qemu/commit/bb14bf59c328c07d18ca1c078a6cf72a7cbacab6
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: e8ba8734063c8f049fe7650971164bd398055166
https://github.com/qemu/qemu/commit/e8ba8734063c8f049fe7650971164bd398055166
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: 82d2faf861f5039280fbe5ecf38b255a28f7cc21
https://github.com/qemu/qemu/commit/82d2faf861f5039280fbe5ecf38b255a28f7cc21
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: 7211e621e089a953b87414c4aa0d5485c3297450
https://github.com/qemu/qemu/commit/7211e621e089a953b87414c4aa0d5485c3297450
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]>
Compare: https://github.com/qemu/qemu/compare/561f025ae293...7211e621e089
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
