Branch: refs/heads/stable-10.0
Home: https://github.com/qemu/qemu
Commit: 07421d312cf5c5393a6ab74c74c3c4c11b9328ef
https://github.com/qemu/qemu/commit/07421d312cf5c5393a6ab74c74c3c4c11b9328ef
Author: Paolo Bonzini <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: cb1be41c9da849389e86c9ad577e66206fbc3cb8
https://github.com/qemu/qemu/commit/cb1be41c9da849389e86c9ad577e66206fbc3cb8
Author: Michael Tokarev <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: 85df3071b6f0b256d64536b3bedd81a5d59c58ce
https://github.com/qemu/qemu/commit/85df3071b6f0b256d64536b3bedd81a5d59c58ce
Author: Alex Bennée <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: 3aefdb1970d2520bfb79b5fff343d9b53c1e0145
https://github.com/qemu/qemu/commit/3aefdb1970d2520bfb79b5fff343d9b53c1e0145
Author: Alex Bennée <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
Changed paths:
M tests/docker/dockerfiles/debian-all-test-cross.docker
Log Message:
-----------
tests/docker: add --arch-only to qemu deps for all-test-cross
If we want to build this container on non-x86 systems we might not
have all the cross-compilers needed for the ROM blobs we don't
actually build. Use --arch-only to avoid stalling on these missing
bits.
Reviewed-by: Manos Pitsidianakis <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 408c8629105f32aa1d02d3004998ea453f69809b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9107a75a83f3a234b4f0d08750a464d073033b4a
https://github.com/qemu/qemu/commit/9107a75a83f3a234b4f0d08750a464d073033b4a
Author: Alex Bennée <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
Changed paths:
M tests/docker/dockerfiles/debian-all-test-cross.docker
Log Message:
-----------
tests/docker: handle host-arch selection for all-test-cross
When building on non-x86 we get a bunch but not all of the compilers.
Handle this in the Dockerfile by probing the arch and expanding the
list available.
Reviewed-by: Manos Pitsidianakis <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 6da616bb17004f9332b2798353ebef88cac61cc2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4162e46522b0140c00a929ca86157c622810ade0
https://github.com/qemu/qemu/commit/4162e46522b0140c00a929ca86157c622810ade0
Author: Alex Bennée <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
Changed paths:
M tests/docker/dockerfiles/debian-all-test-cross.docker
Log Message:
-----------
tests/docker: fix debian-all-test-cross
It turns out you can't easily expand an ENV var across multiple steps
in a dockerfile. This meant we silently dropped the architectures we
should have even on amd64 hosts. As the updated AVAILABLE_COMPILERS is
only needed for the following apt install line just merge them.
Fixes: 6da616bb170 (tests/docker: handle host-arch selection for all-test-cross)
Reviewed-by: Manos Pitsidianakis <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 61432e805e5028df0a3df5a76915cdc3007ecd41)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b9bef0a51b91f7e975d422875dad1525ff343fe3
https://github.com/qemu/qemu/commit/b9bef0a51b91f7e975d422875dad1525ff343fe3
Author: Richard Henderson <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: f121f524fa483e80f26fe9c65e6a00451c6a228e
https://github.com/qemu/qemu/commit/f121f524fa483e80f26fe9c65e6a00451c6a228e
Author: Alex Bennée <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: b2997c5a18b743cf9f2d7b07a7a3552a02d97952
https://github.com/qemu/qemu/commit/b2997c5a18b743cf9f2d7b07a7a3552a02d97952
Author: Hanna Czenczek <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: 97055b3f87dbf3f576cb745f6955c620e96dbe11
https://github.com/qemu/qemu/commit/97055b3f87dbf3f576cb745f6955c620e96dbe11
Author: Stefan Weil <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: 71bfe50b6a8831c4a6491246c139297f3d52afbd
https://github.com/qemu/qemu/commit/71bfe50b6a8831c4a6491246c139297f3d52afbd
Author: Kevin Wolf <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: 466c6a1d6a6ee7a55302ea810147c7a079275771
https://github.com/qemu/qemu/commit/466c6a1d6a6ee7a55302ea810147c7a079275771
Author: Hanna Czenczek <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: 3b0b68549f855993f62374d4e4d546bda7633615
https://github.com/qemu/qemu/commit/3b0b68549f855993f62374d4e4d546bda7633615
Author: Hanna Czenczek <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: 4e529c2abe4b76f6180f6a9102fe7f5d2d3099c2
https://github.com/qemu/qemu/commit/4e529c2abe4b76f6180f6a9102fe7f5d2d3099c2
Author: Thomas Huth <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: ae2224c4d70abb08fb6961aa492fca997d287940
https://github.com/qemu/qemu/commit/ae2224c4d70abb08fb6961aa492fca997d287940
Author: Cédric Le Goater <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: 47d030d1a0f8632e3986214ac3e2b55f42738951
https://github.com/qemu/qemu/commit/47d030d1a0f8632e3986214ac3e2b55f42738951
Author: Cédric Le Goater <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: f417f1d0b3bebba0180c5cbb5922da190e6f6795
https://github.com/qemu/qemu/commit/f417f1d0b3bebba0180c5cbb5922da190e6f6795
Author: Cédric Le Goater <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: 5be91f937cfbd64cac76736d6a7badfd2109e6f8
https://github.com/qemu/qemu/commit/5be91f937cfbd64cac76736d6a7badfd2109e6f8
Author: Cédric Le Goater <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: 0a879fb4668bcfc0f960a08292f780be6e919130
https://github.com/qemu/qemu/commit/0a879fb4668bcfc0f960a08292f780be6e919130
Author: Cédric Le Goater <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: 05636333e941d6f6b48064a46afb6d474a5ca288
https://github.com/qemu/qemu/commit/05636333e941d6f6b48064a46afb6d474a5ca288
Author: Zesen Liu <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: 95f5470012594cf93bcf5e4cfeded2b157d1737f
https://github.com/qemu/qemu/commit/95f5470012594cf93bcf5e4cfeded2b157d1737f
Author: Andrew Cooper <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: fb6b39358fd098aee648f6781e936e0f42d34a8a
https://github.com/qemu/qemu/commit/fb6b39358fd098aee648f6781e936e0f42d34a8a
Author: Paolo Bonzini <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: 943c7365169cb66617523518452ba6eca575a513
https://github.com/qemu/qemu/commit/943c7365169cb66617523518452ba6eca575a513
Author: Alano Song <[email protected]>
Date: 2026-01-07 (Wed, 07 Jan 2026)
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: 446e4e1a66320dc3db3cbc19132241c4f76a8bb1
https://github.com/qemu/qemu/commit/446e4e1a66320dc3db3cbc19132241c4f76a8bb1
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: 8c3c8daaadcab875d40028f88c4d31e80fc47718
https://github.com/qemu/qemu/commit/8c3c8daaadcab875d40028f88c4d31e80fc47718
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: 087712da6349fce7f68adaff4b8ff49579c733a6
https://github.com/qemu/qemu/commit/087712da6349fce7f68adaff4b8ff49579c733a6
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: d3ba2bcf5d5c6d1c3c195e30433521c2856098df
https://github.com/qemu/qemu/commit/d3ba2bcf5d5c6d1c3c195e30433521c2856098df
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: cab823a4544097a9f695cff2a96382beef7fdafc
https://github.com/qemu/qemu/commit/cab823a4544097a9f695cff2a96382beef7fdafc
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: 92bf9c32c9d6c7a7a3e0ee6cd94997b0b03c7084
https://github.com/qemu/qemu/commit/92bf9c32c9d6c7a7a3e0ee6cd94997b0b03c7084
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: 6a19810d9635fd4c8d572e1664eaeeb3cb31e50f
https://github.com/qemu/qemu/commit/6a19810d9635fd4c8d572e1664eaeeb3cb31e50f
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: 71615b13f689b2f7c4cbd76b39ccb4f78b6960a5
https://github.com/qemu/qemu/commit/71615b13f689b2f7c4cbd76b39ccb4f78b6960a5
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: 275a88c25014d889e382be332fd20aa8fb471a53
https://github.com/qemu/qemu/commit/275a88c25014d889e382be332fd20aa8fb471a53
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: dbd9c5112cd3a43cb698c3b07c01df3e3f545242
https://github.com/qemu/qemu/commit/dbd9c5112cd3a43cb698c3b07c01df3e3f545242
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: 43ea49779034da9c7f3899dc20941258b98b2d0e
https://github.com/qemu/qemu/commit/43ea49779034da9c7f3899dc20941258b98b2d0e
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: 4f0a748c9372ea84294c7925d92a94210617a618
https://github.com/qemu/qemu/commit/4f0a748c9372ea84294c7925d92a94210617a618
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: 4ba877461e6b1a8637b15ff1a8c77ba97639c927
https://github.com/qemu/qemu/commit/4ba877461e6b1a8637b15ff1a8c77ba97639c927
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: cf6d62c5c98c26eb24622d7528b4f73f791f0d9b
https://github.com/qemu/qemu/commit/cf6d62c5c98c26eb24622d7528b4f73f791f0d9b
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: 297b8ea0f574c6cd4fd2005e04dc584d6f157d23
https://github.com/qemu/qemu/commit/297b8ea0f574c6cd4fd2005e04dc584d6f157d23
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: 6fdac75e78af136d07ceeae1a4218f54a0db72ed
https://github.com/qemu/qemu/commit/6fdac75e78af136d07ceeae1a4218f54a0db72ed
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.0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 788dcf5c0a970ddb08cc90b521e0722894fdf6ed
https://github.com/qemu/qemu/commit/788dcf5c0a970ddb08cc90b521e0722894fdf6ed
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.0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ed709c0e1df82b349578af10f1921950867f73d0
https://github.com/qemu/qemu/commit/ed709c0e1df82b349578af10f1921950867f73d0
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.0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8491f9426876423cc0fce55a553e6ef256b1b745
https://github.com/qemu/qemu/commit/8491f9426876423cc0fce55a553e6ef256b1b745
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.0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 21264e6c98b7af9083045b7ca9a507239102e509
https://github.com/qemu/qemu/commit/21264e6c98b7af9083045b7ca9a507239102e509
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: bf1070909b17315d2d9c7b4b7beb0e2093fe6a41
https://github.com/qemu/qemu/commit/bf1070909b17315d2d9c7b4b7beb0e2093fe6a41
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: 4d402fcd1cba7ff5ab9b797963cd94d419d74775
https://github.com/qemu/qemu/commit/4d402fcd1cba7ff5ab9b797963cd94d419d74775
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: back-port to 10.0.x)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 012d0a1753a7c2833858a208542d4329d6789370
https://github.com/qemu/qemu/commit/012d0a1753a7c2833858a208542d4329d6789370
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: dadefc1b2aada91112c7e2822f9152b9c619c8b3
https://github.com/qemu/qemu/commit/dadefc1b2aada91112c7e2822f9152b9c619c8b3
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2026-01-21 (Wed, 21 Jan 2026)
Changed paths:
M tests/functional/test_mips64el_replay.py
M tests/functional/test_mips_replay.py
Log Message:
-----------
tests/functional: Mark the MIPS replay tests as flaky
MIPS test_replay.py often times out (likely hang) under GitLab CI:
2/21 qemu:func-thorough+func-mips64el-thorough+thorough /
func-mips64el-replay TIMEOUT 180.12s killed by signal 15 SIGTERM
The console.log file is empty, and recording.logs only shows:
qemu-system-mips64el: terminating on signal 15 from pid 344
Since this is a long term issue affecting our CI, disable the tests.
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 1c11aa180714e8fb1df87923b6ddd0b17aa26204)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 373ee7d1fb2d43b464460a2328a5966cc6f665d6
https://github.com/qemu/qemu/commit/373ee7d1fb2d43b464460a2328a5966cc6f665d6
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2026-01-21 (Wed, 21 Jan 2026)
Changed paths:
M tests/functional/test_mips64el_replay.py
Log Message:
-----------
tests/functional: Mark another MIPS replay test as flaky
When disabling MIPS tests on commit 1c11aa18071
("tests/functional: Mark the MIPS replay tests as flaky")
we missed the 5KEc test.
Reported-by: Richard Henderson <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 290e4e7de7a579be7457bfbc338b697b8eea638f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 21846ec4347cabd9e73300258ed8c4790c59f4f6
https://github.com/qemu/qemu/commit/21846ec4347cabd9e73300258ed8c4790c59f4f6
Author: Pierrick Bouvier <[email protected]>
Date: 2026-01-21 (Wed, 21 Jan 2026)
Changed paths:
M linux-user/aarch64/target_fcntl.h
Log Message:
-----------
linux-user/aarch64/target_fcntl.h: add missing TARGET_O_LARGEFILE definition
This caused a failure with program using openat2, where O_LARGEFILE was
replaced by O_NOFOLLOW.
This issue is only visible when QEMU is compiled with musl libc, where
O_LARGEFILE is different from 0 (vs glibc).
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3262
Cc: [email protected]
Signed-off-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 83017c4aaa9e3ef80161443019764196dffdb654)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5a84115173d18cd4840854d58bdcd7f64d117e9b
https://github.com/qemu/qemu/commit/5a84115173d18cd4840854d58bdcd7f64d117e9b
Author: Bernhard Beschow <[email protected]>
Date: 2026-01-21 (Wed, 21 Jan 2026)
Changed paths:
M hw/sd/sdhci.c
Log Message:
-----------
hw/sd/sdhci: Fix TYPE_IMX_USDHC to implement sd-spec-version 3 by default
Fixes TYPE_FSL_IMX6UL, TYPE_FSL_IMX7, and TYPE_FSL_IMX8MP to implement
version 3 of the SD specification.
Note that TYPE_FSL_IMX6 already had "sd-spec-version" set accordingly and
that TYPE_FSL_IMX25 correctly sets the same property to version 2 since the
real hardware is an eSDHC which is the uSDHC's predecessor.
Fixes: fd1e5c817964 ("sdhci: Add i.MX specific subtype of SDHCI")
cc: qemu-stable
Signed-off-by: Bernhard Beschow <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Tested-by: BALATON Zoltan <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 214f79fdfb43e92f6c06efb76c3ad8e932b035f8)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 83b0cf4c0eea21c8d3812539d73a5a4448bd4574
https://github.com/qemu/qemu/commit/83b0cf4c0eea21c8d3812539d73a5a4448bd4574
Author: Richard Henderson <[email protected]>
Date: 2026-01-21 (Wed, 21 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]>
Commit: e990f9a83d1a7330a55b01ca46077b12d54d46c4
https://github.com/qemu/qemu/commit/e990f9a83d1a7330a55b01ca46077b12d54d46c4
Author: Pierrick Bouvier <[email protected]>
Date: 2026-01-21 (Wed, 21 Jan 2026)
Changed paths:
M bsd-user/syscall_defs.h
Log Message:
-----------
bsd-user/syscall_defs.h: define STAT_TIME_T_EXT only for 32 bits
Commit 369c1ba2b changed the wrong conditional "#if defined(__i386__)" to
"#if defined(TARGET_I386)".
However, TARGET_I386 is defined for target x86_64 also.
This commit fixes it by identifying correctly 32 bits target.
Found with:
$ ./build/qemu-x86_64 \
-plugin ./build/contrib/plugins/libstoptrigger,icount=1000000 \
-plugin ./build/tests/tcg/plugins/libinsn \
-d plugin \
./build/qemu-system-x86_64 --version
ld-elf.so.1: /lib/libz.so.6: invalid file format
cpu 0 insns: 59746
total insns: 59746
Fixes: 369c1ba2b ("Fix __i386__ test for TARGET_HAS_STAT_TIME_T_EXT")
Fixes: 83b0cf4c0 ("Fix __i386__ test for TARGET_HAS_STAT_TIME_T_EXT" in 10.0.x)
Signed-off-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Warner Losh <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit f0de58ccf6566ad5cf04948788f9b0cfb8b960b4)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: eb5a0a6eeb25854b117503e0577c974d5f439ce4
https://github.com/qemu/qemu/commit/eb5a0a6eeb25854b117503e0577c974d5f439ce4
Author: Alex Bennée <[email protected]>
Date: 2026-01-24 (Sat, 24 Jan 2026)
Changed paths:
M hw/intc/arm_gicv3_its_common.c
M hw/intc/arm_gicv3_its_kvm.c
Log Message:
-----------
hw/intc: avoid byte swap fiddling in gicv3 its path
This allows us to keep the MSI data in plain host order all the way
from the MemoryRegionOps write method to the final KVM_SIGNAL_MSI
ioctl. This fixes a theoretical bug on big-endian hosts because we
were using different size byte swaps which would have truncated the data.
Signed-off-by: Alex Bennée <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Message-id: [email protected]
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit cf10273aff8198ab1c7e2a00e7e5fe51c80b04e7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ac4ed4bd6b59dc5ba9607280a9a7e5eeaa540880
https://github.com/qemu/qemu/commit/ac4ed4bd6b59dc5ba9607280a9a7e5eeaa540880
Author: Luca Bonissi <[email protected]>
Date: 2026-01-24 (Sat, 24 Jan 2026)
Changed paths:
M linux-user/ioctls.h
M linux-user/strace.c
M linux-user/syscall.c
M linux-user/syscall_types.h
M linux-user/user-internals.h
Log Message:
-----------
linux-user: Add termios2 support
Signed-off-by: Luca Bonissi <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Reviewed-by: Helge Deller <[email protected]>
Tested-by: Heinrich Schuchardt <[email protected]>
(cherry picked from commit e9a8a10e84c1bf6e2e8be000e4dd5c83ba0d8470)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9a78e261c3e84e049013e3bc6be3a908fa1e0c87
https://github.com/qemu/qemu/commit/9a78e261c3e84e049013e3bc6be3a908fa1e0c87
Author: Luca Bonissi <[email protected]>
Date: 2026-01-24 (Sat, 24 Jan 2026)
Changed paths:
M linux-user/alpha/termbits.h
Log Message:
-----------
linux-user: Add termios2 support to alpha target
Signed-off-by: Luca Bonissi <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Reviewed-by: Helge Deller <[email protected]>
(cherry picked from commit 8d8c6aeee8599a099e49ec4411f3d1e087ae40ad)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f1f8f23a144728c150084bf08c04366e601a74ee
https://github.com/qemu/qemu/commit/f1f8f23a144728c150084bf08c04366e601a74ee
Author: Luca Bonissi <[email protected]>
Date: 2026-01-24 (Sat, 24 Jan 2026)
Changed paths:
M linux-user/hppa/termbits.h
Log Message:
-----------
linux-user: Add termios2 support to hppa target
Signed-off-by: Luca Bonissi <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Reviewed-by: Helge Deller <[email protected]>
(cherry picked from commit edc741710acedd61011f937967b960d154794258)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ebf963f559efda989b8c5989855ca82448bbd8b5
https://github.com/qemu/qemu/commit/ebf963f559efda989b8c5989855ca82448bbd8b5
Author: Luca Bonissi <[email protected]>
Date: 2026-01-24 (Sat, 24 Jan 2026)
Changed paths:
M linux-user/mips/termbits.h
Log Message:
-----------
linux-user: Add termios2 support to mips target
Signed-off-by: Luca Bonissi <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Reviewed-by: Helge Deller <[email protected]>
(cherry picked from commit edf9184f4feb691b0f70dc544443db2380891598)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: be468e6f9f9c2482d94c01d3abb8298e4798c5ed
https://github.com/qemu/qemu/commit/be468e6f9f9c2482d94c01d3abb8298e4798c5ed
Author: Luca Bonissi <[email protected]>
Date: 2026-01-24 (Sat, 24 Jan 2026)
Changed paths:
M linux-user/sh4/termbits.h
Log Message:
-----------
linux-user: Add termios2 support to sh4 target
Signed-off-by: Luca Bonissi <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Reviewed-by: Helge Deller <[email protected]>
(cherry picked from commit afbe0ff81c29d674b9c18a588bcaab34ddcb8a7b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7c0402f0dc1bf6c1db743fbb9caeda3f994cbb32
https://github.com/qemu/qemu/commit/7c0402f0dc1bf6c1db743fbb9caeda3f994cbb32
Author: Luca Bonissi <[email protected]>
Date: 2026-01-24 (Sat, 24 Jan 2026)
Changed paths:
M linux-user/sparc/termbits.h
Log Message:
-----------
linux-user: Add termios2 support to sparc target
Signed-off-by: Luca Bonissi <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Reviewed-by: Helge Deller <[email protected]>
(cherry picked from commit 947b971cad90375040f399899909a3f1f32b483f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0ed119360f8d14f3af90e709f5fb833373bfe6c5
https://github.com/qemu/qemu/commit/0ed119360f8d14f3af90e709f5fb833373bfe6c5
Author: Vivian Wang <[email protected]>
Date: 2026-01-24 (Sat, 24 Jan 2026)
Changed paths:
M linux-user/alpha/termbits.h
M linux-user/generic/termbits.h
M linux-user/hppa/termbits.h
M linux-user/mips/termbits.h
M linux-user/ppc/termbits.h
M linux-user/sh4/termbits.h
M linux-user/sparc/termbits.h
M linux-user/syscall.c
Log Message:
-----------
linux-user: Add missing termios baud rates
Add several missing baud rates and inputs baud rates in cflag_tbl.
Add these missing definitions in termbits.h:
- TARGET_BOTHER for alpha, hppa, ppc, sh4, sparc
- TARGET_IBSHIFT for hppa, mips, ppc, sh4, sparc
- Missing standard baud rates for hppa
These are required for the glibc test tst-termios-linux.
Link:
https://lore.kernel.org/qemu-devel/20251203-linux-user-higher-baud-rates-v2-1-e45b35224...@iscas.ac.cn
Signed-off-by: Vivian Wang <[email protected]>
Reviewed-by: Helge Deller <[email protected]>
(cherry picked from commit 4f22fcb5c67f40a36e6654f6cfaee23f9f9e93d1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 207df2f80c0ffb9509ac419c56842195dfc71b08
https://github.com/qemu/qemu/commit/207df2f80c0ffb9509ac419c56842195dfc71b08
Author: Icenowy Zheng <[email protected]>
Date: 2026-01-24 (Sat, 24 Jan 2026)
Changed paths:
M linux-user/syscall.c
Log Message:
-----------
linux-user: fixup termios2 related things on PowerPC
The termios things on PowerPC equal to termios2 things otherwhere.
Use some simple #define's to allow both termios and termios2 to map to
termios on PowerPC.
Signed-off-by: Icenowy Zheng <[email protected]>
Link:
https://github.com/AOSC-Dev/aosc-os-abbs/blob/8d77eeaa76e9b159c3f35adaf73c875751aa7d17/app-virtualization/qemu/01-shared/patches/0005-AOSCOS-linux-user-fixup-termios2-related-things-on-P.patch
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Reviewed-by: Helge Deller <[email protected]>
(cherry picked from commit d68f0e2e906939bef076d0cd52f902d433c8c3da)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fe84cb0037353b71a521e6324208609c9ca857ba
https://github.com/qemu/qemu/commit/fe84cb0037353b71a521e6324208609c9ca857ba
Author: Paolo Bonzini <[email protected]>
Date: 2026-01-28 (Wed, 28 Jan 2026)
Changed paths:
M target/i386/tcg/decode-new.c.inc
Log Message:
-----------
target/i386/tcg: fix a few instructions that do not support VEX.L=1
Match the contents of table 2-17 ("#UD Exception and VEX.L Field Encoding")
in the SDM, for instruction in exception class 5. They were incorrectly
accepting 256-bit versions that do not exist.
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 2eb8d9734355ed86e162dce2a3f265ffee4005ed)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 07e8cd9556d155d3aa0f9fa07e6935db61ae9291
https://github.com/qemu/qemu/commit/07e8cd9556d155d3aa0f9fa07e6935db61ae9291
Author: Thomas Huth <[email protected]>
Date: 2026-01-28 (Wed, 28 Jan 2026)
Changed paths:
M pc-bios/optionrom/Makefile
Log Message:
-----------
pc-bios/optionrom: Use 32-bit linker emulation for the optionroms
Without this linker flag, the linking fails on NetBSD v10.1 with:
ld: i386 architecture of input file `multiboot.o' is incompatible with
i386:x86-64 output
ld: i386 architecture of input file `multiboot_dma.o' is incompatible with
i386:x86-64 output
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit e4f1a9b1dacb4d02500629056551b1db2985429c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4f4ccd438be92d24ad7c9c4952ae2358c192df34
https://github.com/qemu/qemu/commit/4f4ccd438be92d24ad7c9c4952ae2358c192df34
Author: Alex Bennée <[email protected]>
Date: 2026-02-02 (Mon, 02 Feb 2026)
Changed paths:
M tests/functional/test_aarch64_sbsaref.py
Log Message:
-----------
tests/functional: migrate sbsa_ref test images
As the builds in codelinaro.org are going away migrate the binaries to
share.linaro.org. As the hotlinks don't encode the filename we need to
explicitly tell uncompress how to handle the files.
Tested-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
(cherry picked from commit d9ca273f8f31acb22d3f5aca5f063b94fb962e19)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fa886ca4955d29d0c219fadec2ecf6a34d846216
https://github.com/qemu/qemu/commit/fa886ca4955d29d0c219fadec2ecf6a34d846216
Author: Jeuk Kim <[email protected]>
Date: 2026-02-02 (Mon, 02 Feb 2026)
Changed paths:
M hw/ufs/ufs.c
Log Message:
-----------
hw/ufs: Ensure DBC of PRDT uses only lower 18 bits
The UFS spec defines the PRDT data byte count as an 18-bit field. This
commit masks the value to the lower 18 bits to prevent incorrect
transfer lengths and ensure compliance.
Signed-off-by: Jeuk Kim <[email protected]>
(cherry picked from commit 289e6a3edf5041a9f96c3fb792845b94b5b3c666)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 318779a5f24b90f9ff52ec0ea86ff03802562dce
https://github.com/qemu/qemu/commit/318779a5f24b90f9ff52ec0ea86ff03802562dce
Author: Jeuk Kim <[email protected]>
Date: 2026-02-02 (Mon, 02 Feb 2026)
Changed paths:
M hw/ufs/lu.c
M hw/ufs/ufs.c
M include/block/ufs.h
Log Message:
-----------
hw/ufs: fix CQE endianness and UPIU length
Round-trip UTRD fields through cpu_to_le/ le_to_cpu when building MCQ CQEs to
keep BE hosts correct. Also avoid double BE conversion of response
data_segment_length and document the LE round-trip.
Signed-off-by: Jeuk Kim <[email protected]>
(cherry picked from commit ed621cc8e2a6dab2663ffb02e875f896f521bee2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 851536a83609a6f41e8459468e42e2f501b4cd7a
https://github.com/qemu/qemu/commit/851536a83609a6f41e8459468e42e2f501b4cd7a
Author: Ilia Levi <[email protected]>
Date: 2026-02-02 (Mon, 02 Feb 2026)
Changed paths:
M hw/ufs/ufs.c
M hw/ufs/ufs.h
Log Message:
-----------
hw/ufs: Fix mcq completion queue wraparound
Currently, ufs_mcq_process_cq() writes to the CQ without checking whether
there is available space. This can cause CQ entries to be discarded and
overwritten. The solution is to stop writing when CQ is full and exert
backpressure on the affected SQs. This is similar to how NVMe CQs operate.
Signed-off-by: Ilia Levi <[email protected]>
Reviewed-by: Jeuk Kim <[email protected]>
Signed-off-by: Jeuk Kim <[email protected]>
(cherry picked from commit f78762a3cc81ca9842907a5fc1b2280083ac51ba)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 51f314c12c9b080635052831a14a6d5dfb553f06
https://github.com/qemu/qemu/commit/51f314c12c9b080635052831a14a6d5dfb553f06
Author: Ilia Levi <[email protected]>
Date: 2026-02-02 (Mon, 02 Feb 2026)
Changed paths:
M tests/qtest/ufs-test.c
Log Message:
-----------
tests/qtest/ufs-test: Add test for mcq completion queue wraparound
Added a test that sends 32 NOP Out commands asynchronously. Since the CQ
has 31 entries by default, this tests the scenario where CQ processing
needs to wait for space to become available.
Additionally, added two minor fixes to existing tests:
* advance CQ head after reading from CQ
* initialize command descriptor slots bitmap in ufs_init()
Signed-off-by: Ilia Levi <[email protected]>
Acked-by: Fabiano Rosas <[email protected]>
Reviewed-by: Jeuk Kim <[email protected]>
Signed-off-by: Jeuk Kim <[email protected]>
(cherry picked from commit 94e72135d4d657d672561b1ae02a5854421616a7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 66b489b368beed122ea1e3703a123450afaf9ddd
https://github.com/qemu/qemu/commit/66b489b368beed122ea1e3703a123450afaf9ddd
Author: John Snow <[email protected]>
Date: 2026-02-02 (Mon, 02 Feb 2026)
Changed paths:
M python/scripts/mkvenv.py
Log Message:
-----------
python: fix msys64 wheel directory specification
In python3.14, fixes were made to the file URI parsing [1] such that
file URIs that used to work but were technically out of spec are now
broken.
As a result, our msys2 GitLab CI tests began failing.
Stop using "file://" URI links in favor of simple paths (Thanks pbo) to
fix parsing errors under Python 3.14 and fix the msys2 GitLab CI tests.
[1] https://docs.python.org/3/whatsnew/3.14.html#urllib
Reported-by: Pierrick Bouvier <[email protected]>
Suggested-by: Pierrick Bouvier <[email protected]>
Signed-off-by: John Snow <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Tested-by: Pierrick Bouvier <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 587f4a1805c83a4e1d59dd43cb14e0a834843d1d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b2137aabc6ede5d626e74c2ca47197794c98841f
https://github.com/qemu/qemu/commit/b2137aabc6ede5d626e74c2ca47197794c98841f
Author: Akihiko Odaki <[email protected]>
Date: 2026-02-03 (Tue, 03 Feb 2026)
Changed paths:
M hw/nvme/ns.c
M hw/nvme/nvme.h
Log Message:
-----------
hw/nvme: Fix bootindex suffix use-after-free
The bootindex suffix can be used as long as the property is alive.
Signed-off-by: Akihiko Odaki <[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 eda9baa17a2854494709a8094419ba6a6901721d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f81dd3987ad356e61631601e1809e00b09b2d354
https://github.com/qemu/qemu/commit/f81dd3987ad356e61631601e1809e00b09b2d354
Author: Gerd Hoffmann <[email protected]>
Date: 2026-02-04 (Wed, 04 Feb 2026)
Changed paths:
M hw/uefi/var-service-vars.c
Log Message:
-----------
hw/uefi: fix size negotiation
Payload size is the variable request size, not the total buffer size.
Take that into account and subtract header sizes.
Fixes: db1ecfb473ac ("hw/uefi: add var-service-vars.c")
Signed-off-by: Gerd Hoffmann <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 46dee71a945d50639586ca3365be29aa9f368bfd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 793da59173808b87e2eabec4f205f83c0b7b9b94
https://github.com/qemu/qemu/commit/793da59173808b87e2eabec4f205f83c0b7b9b94
Author: Cédric Le Goater <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/adc/aspeed_adc.c
Log Message:
-----------
hw/adc: Fix out-of-bounds write in Aspeed ADC model
The 'regs' array has ASPEED_ADC_NR_REGS (52) elements, while the
memory region covers offsets 0x00-0xFC. The aspeed_adc_engine_write()
function has an out-of-bounds write vulnerability when accessing
unimplemented registers.
Fix this by using 'return' instead of 'break' in the default case,
which prevents execution from reaching the s->regs[reg] assignment for
unimplemented registers.
Reported-by: Elhrj Saad <[email protected]>
Fixes: 5857974d5d11 ("hw/adc: Add basic Aspeed ADC model")
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 4c6521296d2b6820ab1f8c59d3a80cd0c138b2d8)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4c12f312d09ac99445282e1d77df0ab7e865df6d
https://github.com/qemu/qemu/commit/4c12f312d09ac99445282e1d77df0ab7e865df6d
Author: Nabih Estefan <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/i2c/aspeed_i2c.c
Log Message:
-----------
hw/i2c/aspeed_i2c.c: Add a check for dma_read
If aspeed_i2c_dma_read fails in aspeed_i2c_bus_send currently, we get
stuck in an infinite retry loop. Add a check for the return value of
aspeed_i2c_dma_read that will break us out of said loop.
Signed-off-by: Nabih Estefan <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Fixes: 545d6bef7097 ("aspeed/i2c: Add support for DMA transfers")
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit 0a1d4770670297a1da52118f84812e4a5ffc7722)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 623b0bad8e08a55e27fc61c7db193195a3d142dc
https://github.com/qemu/qemu/commit/623b0bad8e08a55e27fc61c7db193195a3d142dc
Author: Jamin Lin <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/i2c/aspeed_i2c.c
Log Message:
-----------
hw/i2c/aspeed: Fix wrong I2CC_DMA_LEN when I2CM_DMA_TX/RX_ADDR set first
In the previous design, the I2C model would update I2CC_DMA_LEN (0x54) based on
the value of I2CM_DMA_LEN (0x1C) when the firmware set either I2CM_DMA_TX_ADDR
(0x30) or I2CM_DMA_RX_ADDR (0x34). However, this only worked correctly if the
firmware set I2CM_DMA_LEN before setting I2CM_DMA_TX_ADDR or I2CM_DMA_RX_ADDR.
If the firmware instead set I2CM_DMA_TX_ADDR or I2CM_DMA_RX_ADDR before setting
I2CM_DMA_LEN, the value written to I2CC_DMA_LEN would be incorrect.
To fix this issue, the model should be updated to set I2CC_DMA_LEN when the
firmware writes to the I2CM_DMA_LEN register, rather than when it writes to the
I2CM_DMA_RX_ADDR and I2CM_DMA_TX_ADDR registers.
Signed-off-by: Jamin Lin <[email protected]>
Fixes: ba2cccd64e90 ("aspeed: i2c: Add new mode support")
Reviewed-by: Cédric Le Goater <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit 9cbd8ee7f67fceee51d3c993a282e5adc397b6b9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 517830b989205ec27c20f9cb9dde63cf24cb3fb6
https://github.com/qemu/qemu/commit/517830b989205ec27c20f9cb9dde63cf24cb3fb6
Author: Jamin Lin <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/i2c/aspeed_i2c.c
Log Message:
-----------
hw/i2c/aspeed_i2c: Fix DMA moving data into incorrect address
In the previous design, the I2C model updated dma_dram_offset only when
firmware programmed the RX/TX DMA buffer address registers. The firmware
used to rewrite these registers before issuing each DMA command.
The firmware driver behavior has changed to program the DMA address
registers only once during I2C initialization. As a result, the I2C model
no longer refreshes dma_dram_offset, causing DMA to move data into an
incorrect DRAM address.
Fix this by introducing helper functions to update dma_dram_offset from
the DMA address registers, and invoke them right before handling TX/RX
DMA operations. This guarantees DMA always uses the correct buffer
address even if the registers are programmed only once.
Signed-off-by: Jamin Lin <[email protected]>
Fixes: c400c38854017eeccda63115814eba4c3ef2b51f ("hw/i2c/aspeed: Introduce a
new dma_dram_offset attribute in AspeedI2Cbus")
Reviewed-by: Cédric Le Goater <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit efea7ddb4689a1ac4bce63a9ddb32887c7f3ac50)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c228a06d9c674a238ab12f7e831cf06ace04adb8
https://github.com/qemu/qemu/commit/c228a06d9c674a238ab12f7e831cf06ace04adb8
Author: Wafer Xie <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/virtio/vhost-vdpa.c
M include/hw/virtio/vhost-vdpa.h
Log Message:
-----------
vdpa: fix vhost-vdpa suspended state not be shared
When stopping a vhost-vdpa device, only the first queue pair is marked as
suspended,
while the remaining queues are not updated to the suspended state.
As a result, when stopping a multi-queue vhost-vdpa device,
the following error message will be printed.
qemu-system-x86_64:vhost VQ 2 ring restore failed: -1: Operation not permitted
(1)
qemu-system-x86_64:vhost VQ 3 ring restore failed: -1: Operation not permitted
(1)
So move v->suspended to v->shared, and then all the vhost_vdpa devices cannot
have different suspended states.
Fixes: 0bb302a9960a ("vdpa: add vhost_vdpa_suspend")
Suggested-by: Eugenio Pérez <[email protected]>
Acked-by: Eugenio Pérez <[email protected]>
Acked-by: Jason Wang <[email protected]>
Signed-off-by: Wafer Xie <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Acked-by: Jason Wang <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit fd3a2c601ab4a1bdb669e4c584b364e00a978702)
(Mjt: context fixup due to missing v10.0.0-1280-g494c50dcc099
"vdpa: move memory listener register to vhost_vdpa_init")
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8b3ac19ae116e92bdaf169a4263645c661364b48
https://github.com/qemu/qemu/commit/8b3ac19ae116e92bdaf169a4263645c661364b48
Author: Dorinda Bassey <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/display/virtio-dmabuf.c
Log Message:
-----------
virtio-dmabuf: Ensure UUID persistence for hash table insertion
In `virtio_add_resource` function, the UUID used as a key for
`g_hash_table_insert` was temporary, which could lead to
invalid lookups when accessed later. This patch ensures that
the UUID remains valid by duplicating it into a newly allocated
memory space. The value is then inserted into the hash table
with this persistent UUID key to ensure that the key stored in
the hash table remains valid as long as the hash table entry
exists.
Fixes: faefdba847 ("hw/display: introduce virtio-dmabuf")
Signed-off-by: Dorinda Bassey <[email protected]>
Reviewed-by: Stefano Garzarella <[email protected]>
Reviewed-by: Albert Esteve <[email protected]>
Reviewed-by: Marc-André Lureau <[email protected]>
Reviewed-by: Jim MacArthur <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit fff77cfb8413190c6362b95203ef0973c83b50d2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 79fd6bf98d87d1347ac85f1473ead5dbc643c6bc
https://github.com/qemu/qemu/commit/79fd6bf98d87d1347ac85f1473ead5dbc643c6bc
Author: Igor Mammedov <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/pci-host/q35.c
M tests/qtest/q35-test.c
Log Message:
-----------
q35: Fix migration of SMRAM state
When migrating, dst QEMU by default has SMRAM unlocked,
and since wmask is not migrated, the migrated value of
MCH_HOST_BRIDGE_F_SMBASE in config space fall to prey of
mch_update_smbase_smram()
...
if (pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] == 0xff) {
*reg = 0x00;
and is getting cleared and leads to unlocked smram
on dst even if on source it's been locked.
As Andrey has pointed out [1], we should derive wmask
from config and not other way around.
Drop offending chunk and resync wmask based on MCH_HOST_BRIDGE_F_SMBASE
register value. That would preserve the register during
migration and set smram regions into corresponding state.
What that changes is:
that it would let guest write junk values in register
(with no apparent effect) until it's stumbles upon
reserved 0x1 [|] 0x2 values, at which point it
would be only possible to lock register and trigger
switch to SMRAM blackhole in CPU AS.
While at it, fix up test by removing junk discard before negotiation hunk.
PS2:
Instead of adding a dedicated post_load handler for it,
reuse mch_update->mch_update_smbase_smram call chain
that is called on write/reset/post_load to be consistent
with how we handle mch registers.
PS3:
for prosterity here is erro message Andrey got due to this bug:
qemu: vfio_container_dma_map(0x..., 0x0, 0xa0000, 0x....) = -22 (Invalid
argument)
qemu: hardware error: vfio: DMA mapping failed, unable to continue
1) https://patchew.org/QEMU/[email protected]/
Fixes: f404220e279c ("q35: implement 128K SMRAM at default SMBASE address")
Reported-by: Andrey Ryabinin <[email protected]>
Signed-off-by: Igor Mammedov <[email protected]>
Reviewed-by: Andrey Ryabinin <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 66cf169e29b06dca104c5a229fba0da4ce33599c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e649201bb96ae7e91a69d57392c8907ec085111e
https://github.com/qemu/qemu/commit/e649201bb96ae7e91a69d57392c8907ec085111e
Author: zhenwei pi <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/virtio/virtio-crypto.c
Log Message:
-----------
hw/virtio/virtio-crypto: verify asym request size
The total lenght of request is limited by cryptodev config, verify it
to avoid unexpected request from guest.
Fixes: CVE-2025-14876
Fixes: 0e660a6f90a ("crypto: Introduce RSA algorithm")
Reported-by: 이재영 <[email protected]>
Signed-off-by: zhenwei pi <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 91c6438caffc880e999a7312825479685d659b44)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3464e88bc98d72acc3a9674054b9ed0c3d4e9b90
https://github.com/qemu/qemu/commit/3464e88bc98d72acc3a9674054b9ed0c3d4e9b90
Author: zhenwei pi <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M backends/cryptodev-builtin.c
Log Message:
-----------
cryptodev-builtin: Limit the maximum size
This backend driver is used for demonstration purposes only, unlimited
size leads QEMU OOM.
Fixes: CVE-2025-14876
Fixes: 1653a5f3fc7 ("cryptodev: introduce a new cryptodev backend")
Reported-by: 이재영 <[email protected]>
Signed-off-by: zhenwei pi <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 7b913094c703641a0442bb1d1165323a019c591c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8d5a8ebaaff20fc99ebde2a0bc8cf73e094d0a33
https://github.com/qemu/qemu/commit/8d5a8ebaaff20fc99ebde2a0bc8cf73e094d0a33
Author: Joelle van Dyne <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/display/virtio-gpu-virgl.c
Log Message:
-----------
virtio-gpu-virgl: correct parent for blob memory region
When `owner` == `mr`, `object_unparent` will crash:
object_unparent(mr) ->
object_property_del_child(mr, mr) ->
object_finalize_child_property(mr, name, mr) ->
object_unref(mr) ->
object_finalize(mr) ->
object_property_del_all(mr) ->
object_finalize_child_property(mr, name, mr) ->
object_unref(mr) ->
fail on g_assert(obj->ref > 0)
However, passing a different `owner` to `memory_region_init` does not
work. `memory_region_ref` has an optimization where it takes a ref
only on the owner. That means when flatviews are created, it does not
take a ref on the region and you can get a UAF from `flatview_destroy`
called from RCU.
The correct fix therefore is to use `NULL` as the name which will set
the `owner` but not the `parent` (which is still NULL). This allows us
to use `memory_region_ref` on itself while not having to rely on unparent
for cleanup.
Signed-off-by: Joelle van Dyne <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit e27194e087aede62dbe3d2805c6f1aa30d3465df)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 90b3d44f6def8ee55291e02201a651f6cc55ccaa
https://github.com/qemu/qemu/commit/90b3d44f6def8ee55291e02201a651f6cc55ccaa
Author: Li Chen <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/virtio/virtio-pmem.c
Log Message:
-----------
virtio-pmem: ignore empty queue notifications
virtio_pmem_flush() treats a NULL return from virtqueue_pop() as a fatal
error and calls virtio_error(), which puts the device into NEEDS_RESET.
However, virtqueue handlers can be invoked when no element is available,
so an empty queue should be handled as a benign no-op.
With a Linux guest this avoids spurious NEEDS_RESET and the resulting
-EIO propagation (e.g. EXT4 journal abort and remount-ro).
Signed-off-by: Li Chen <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit efd581a8cd4405ca183ecd017072b0c878802d69)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 12ce00e31a5d629b6245633c856c38dabb73789b
https://github.com/qemu/qemu/commit/12ce00e31a5d629b6245633c856c38dabb73789b
Author: Honglei Huang <[email protected]>
Date: 2026-02-06 (Fri, 06 Feb 2026)
Changed paths:
M hw/display/virtio-gpu-virgl.c
Log Message:
-----------
virtio-gpu: fix error handling in virgl_cmd_resource_create_blob
Fix inverted error check in virgl_cmd_resource_create_blob() that causes
the function to return error when virtio_gpu_create_mapping_iov() succeeds.
virtio_gpu_create_mapping_iov() returns 0 on success and negative values
on error. The check 'if (!ret)' incorrectly treats success (ret=0) as an
error condition, causing the function to fail when it should succeed.
Change the condition to 'if (ret != 0)' to properly detect errors.
Fixes: 7c092f17ccee ("virtio-gpu: Handle resource blob commands")
Signed-off-by: Honglei Huang <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Dmitry Osipenko <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 3560b51979577afc3ab937fd8b02597515bdfbae)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b6c0a76016d71a8d491685f7bc8be29a9e36aed8
https://github.com/qemu/qemu/commit/b6c0a76016d71a8d491685f7bc8be29a9e36aed8
Author: Aleksandr Sergeev <[email protected]>
Date: 2026-02-10 (Tue, 10 Feb 2026)
Changed paths:
M linux-user/main.c
M linux-user/syscall.c
M linux-user/user-internals.h
Log Message:
-----------
linux-user/syscall.c: Prevent acquiring clone_lock while fork()
By the spec, fork() copies only the thread which executes it.
So it may happen, what while one thread is doing a fork,
another thread is holding `clone_lock` mutex
(e.g. doing a `fork()` or `exit()`).
So the child process is born with the mutex being held,
and there are nobody to release it.
As the thread executing do_syscall() is not considered running,
start_exclusive() does not protect us from the case.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3226
Signed-off-by: Aleksandr Sergeev <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit d22e9aec572396836782e993cb18d598e6012688)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e4fb63f1a84d408706fd3d796c7f5ff3fa99d6ad
https://github.com/qemu/qemu/commit/e4fb63f1a84d408706fd3d796c7f5ff3fa99d6ad
Author: Andrey Drobyshev <[email protected]>
Date: 2026-02-10 (Tue, 10 Feb 2026)
Changed paths:
M scripts/qemugdb/timers.py
Log Message:
-----------
scripts/qemugdb: timers: Fix KeyError in 'qemu timers' command
Currently invoking 'qemu timers' command results into: "gdb.error: There
is no member named last". Let's remove the legacy 'last' field from
QEMUClock, as it was removed in v4.2.0 by the commit 3c2d4c8aa6a
("timer: last, remove last bits of last").
Signed-off-by: Andrey Drobyshev <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Message-id: [email protected]
Signed-off-by: Stefan Hajnoczi <[email protected]>
(cherry picked from commit 80c97930a93c32e2e666f5420af2d5734021a135)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: bb779689554ca5e69e0ac0bb56f90c41c64a80bb
https://github.com/qemu/qemu/commit/bb779689554ca5e69e0ac0bb56f90c41c64a80bb
Author: Michael Tokarev <[email protected]>
Date: 2026-02-12 (Thu, 12 Feb 2026)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 10.0.8 release
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/561f025ae293...bb779689554c
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
