Branch: refs/heads/staging-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: 5cc565266318a166caa804d9893d0de2a30d96c7
https://github.com/qemu/qemu/commit/5cc565266318a166caa804d9893d0de2a30d96c7
Author: Xianglai Li <[email protected]>
Date: 2026-01-16 (Fri, 16 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: 2f9b27a0fa383cae0a40d213df0ecf6a939c15d6
https://github.com/qemu/qemu/commit/2f9b27a0fa383cae0a40d213df0ecf6a939c15d6
Author: Song Gao <[email protected]>
Date: 2026-01-16 (Fri, 16 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: 70062546eb9b4c91e5a47c4160c7a74c85dcd959
https://github.com/qemu/qemu/commit/70062546eb9b4c91e5a47c4160c7a74c85dcd959
Author: Song Gao <[email protected]>
Date: 2026-01-16 (Fri, 16 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: f99881fb41a82a9f7540278bbd5811ae7e35decb
https://github.com/qemu/qemu/commit/f99881fb41a82a9f7540278bbd5811ae7e35decb
Author: Song Gao <[email protected]>
Date: 2026-01-16 (Fri, 16 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: 798c9f1f9779a4b282b4328ed7a202d745ca4439
https://github.com/qemu/qemu/commit/798c9f1f9779a4b282b4328ed7a202d745ca4439
Author: Yao Zi <[email protected]>
Date: 2026-01-16 (Fri, 16 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: 3b54d0178738a8a57e74c3554922600418ed38bd
https://github.com/qemu/qemu/commit/3b54d0178738a8a57e74c3554922600418ed38bd
Author: Alex Bennée <[email protected]>
Date: 2026-01-16 (Fri, 16 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: bac6531bf9555186ab4bb853180ce84963726917
https://github.com/qemu/qemu/commit/bac6531bf9555186ab4bb853180ce84963726917
Author: Peter Maydell <[email protected]>
Date: 2026-01-16 (Fri, 16 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: 7af3bdf6053d4b0205fef7d1c6524ed2aaf83ad5
https://github.com/qemu/qemu/commit/7af3bdf6053d4b0205fef7d1c6524ed2aaf83ad5
Author: Peter Maydell <[email protected]>
Date: 2026-01-16 (Fri, 16 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: acbd0bfd28ab48b3f3f645b17e9087572a39e744
https://github.com/qemu/qemu/commit/acbd0bfd28ab48b3f3f645b17e9087572a39e744
Author: Peter Maydell <[email protected]>
Date: 2026-01-16 (Fri, 16 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]>
Compare: https://github.com/qemu/qemu/compare/944f0a4487b1...acbd0bfd28ab
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
