Branch: refs/heads/stable-10.1
  Home:   https://github.com/qemu/qemu
  Commit: 469b4b6fcbfba47f975d3f6ec61eda169fc580ca
      
https://github.com/qemu/qemu/commit/469b4b6fcbfba47f975d3f6ec61eda169fc580ca
  Author: Kevin Wolf <[email protected]>
  Date:   2025-12-07 (Sun, 07 Dec 2025)

  Changed paths:
    M block/file-posix.c

  Log Message:
  -----------
  file-posix: Handle suspended dm-multipath better for SG_IO

When introducing DM_MPATH_PROBE_PATHS, we already anticipated that
dm-multipath devices might be suspended for a short time when the DM
tables are reloaded and that they return -EAGAIN in this case. We then
wait for a millisecond and retry.

However, meanwhile it has also turned out that libmpathpersist (which is
used by qemu-pr-helper) may need to perform more complex recovery
operations to get reservations back to expected state if a path failure
happened in the middle of a PR operation. In this case, the device is
suspended for a longer time compared to the case we originally expected.

This patch changes hdev_co_ioctl() to treat -EAGAIN separately so that
it doesn't result in an immediate failure if the device is suspended for
more than 1ms, and moves to incremental backoff to cover both quick and
slow cases without excessive delays.

Buglink: https://issues.redhat.com/browse/RHEL-121543
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 2c3165a1a61c299b4a3ae30899e1cc738d20e004)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: c27375417d5f60b3df6f35fff10a6b6c0baf2af7
      
https://github.com/qemu/qemu/commit/c27375417d5f60b3df6f35fff10a6b6c0baf2af7
  Author: Richard Henderson <[email protected]>
  Date:   2025-12-07 (Sun, 07 Dec 2025)

  Changed paths:
    M tcg/tcg-op-ldst.c

  Log Message:
  -----------
  tcg: Zero extend 32-bit addresses for TCI

For native code generation, zero-extending 32-bit addresses for
the slow path helpers happens in tcg_out_{ld,st}_helper_args,
but there isn't really a slow path for TCI, so that didn't happen.

Make the extension for TCI explicit in the opcode stream,
much like we already do for plugins and atomic helpers.

Cc: [email protected]
Fixes: 24e46e6c9d9 ("accel/tcg: Widen tcg-ldst.h addresses to uint64_t")
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 41706d3e72d651edb03b4a06b02b490bec8a3ddf)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 7a08ce041983bf578bd848bdb160161c508d60b9
      
https://github.com/qemu/qemu/commit/7a08ce041983bf578bd848bdb160161c508d60b9
  Author: Michael Tokarev <[email protected]>
  Date:   2025-12-07 (Sun, 07 Dec 2025)

  Changed paths:
    M .gitlab-ci.d/cirrus.yml

  Log Message:
  -----------
  gitlab-ci.d/cirrus: Update the FreeBSD job to v14.3

The FreeBSD 14.2 job fails since the image disappeared
from the cloud.  We already bumped FreeBSD image to 14.3
in tests/vm in c8958b7eb4 (part of v10.1.0).

Signed-off-by: Michael Tokarev <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Tested-by: Alex Bennée <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
(cherry picked from commit 7e71b8e7f2f658999fd6d0871cab3acad53150e7)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 1dfa2156a955ad730f7dd87473947cd4bc968f6b
      
https://github.com/qemu/qemu/commit/1dfa2156a955ad730f7dd87473947cd4bc968f6b
  Author: Alex Bennée <[email protected]>
  Date:   2025-12-07 (Sun, 07 Dec 2025)

  Changed paths:
    M .gitlab-ci.d/custom-runners.yml
    R .gitlab-ci.d/custom-runners/ubuntu-22.04-aarch32.yml
    R .gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
    R .gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml
    A .gitlab-ci.d/custom-runners/ubuntu-24.04-aarch32.yml
    A .gitlab-ci.d/custom-runners/ubuntu-24.04-aarch64.yml
    A .gitlab-ci.d/custom-runners/ubuntu-24.04-s390x.yml

  Log Message:
  -----------
  gitlab: move custom runners to Ubuntu 24.04

Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit eafc5f69e621725dcdcedcc1955d820af7abfc82)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 8864d375de43e6438f31ccbd84ee98843c298677
      
https://github.com/qemu/qemu/commit/8864d375de43e6438f31ccbd84ee98843c298677
  Author: Alex Bennée <[email protected]>
  Date:   2025-12-10 (Wed, 10 Dec 2025)

  Changed paths:
    M target/arm/tcg/tlb_helper.c

  Log Message:
  -----------
  target/arm: handle unaligned PC during tlb probe

PC alignment faults have priority over instruction aborts and we have
code to deal with this in the translation front-ends. However during
tb_lookup we can see a potentially faulting probe which doesn't get a
MemOp set. If the page isn't available this results in
EC_INSNABORT (0x20) instead of EC_PCALIGNMENT (0x22).

As there is no easy way to set the appropriate MemOp in the
instruction fetch probe path lets just detect it in
arm_cpu_tlb_fill_align() ahead of the main alignment check. We also
teach arm_deliver_fault to deliver the right syndrome for
MMU_INST_FETCH alignment issues.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3233
Tested-by: Jessica Clarke <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
(cherry picked from commit dd77ef99aa0280c467fe8442b4238122899ae6cf)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 7ceeab2dc4b68b7bb77d90be6854bd6e33e72b1e
      
https://github.com/qemu/qemu/commit/7ceeab2dc4b68b7bb77d90be6854bd6e33e72b1e
  Author: Denis V. Lunev <[email protected]>
  Date:   2025-12-10 (Wed, 10 Dec 2025)

  Changed paths:
    M scripts/modinfo-collect.py

  Log Message:
  -----------
  scripts: fix broken error path in modinfo-collect.py

sys.stderr.print is dropped long ago and should not be used. Official
replacement is sys.stderr.write

The problem has been found debugging building on some fancy platform
derived from Debian.

Signed-off-by: Denis V. Lunev <[email protected]>
CC: John Snow <[email protected]>
CC: Cleber Rosa <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 8062bfd517645e0219fe302839fad7231bebf61d)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: cee3e62d528bd9295216b0ef4a627d8763135f79
      
https://github.com/qemu/qemu/commit/cee3e62d528bd9295216b0ef4a627d8763135f79
  Author: Hanna Czenczek <[email protected]>
  Date:   2025-12-10 (Wed, 10 Dec 2025)

  Changed paths:
    M hw/virtio/vhost.c

  Log Message:
  -----------
  vhost: Always initialize cached vring data

vhost_virtqueue_start() can exit early if the descriptor ring address is
0, assuming the virtqueue isn’t ready to start.

In this case, all cached vring information (size, physical address,
pointer) is left as-is.  This is OK at first startup, when that info is
still initialized to 0, but after a reset, it will retain old (outdated)
information.

vhost_virtqueue_start() must make sure these values are (re-)set
properly before exiting.

(When using an IOMMU, these outdated values can stall the device:
vhost_dev_start() deliberately produces an IOMMU miss event for each
used vring.  If used_phys contains an outdated value, the resulting
lookup may fail, forcing the device to be stopped.)

Cc: [email protected]
Signed-off-by: Hanna Czenczek <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 46228925edd53bb0569519538b94e10b85f9c001)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 59bb74c5d62e1a0d3f0f061025e2487613cd132c
      
https://github.com/qemu/qemu/commit/59bb74c5d62e1a0d3f0f061025e2487613cd132c
  Author: Stefan Weil <[email protected]>
  Date:   2025-12-10 (Wed, 10 Dec 2025)

  Changed paths:
    M scripts/nsis.py

  Log Message:
  -----------
  scripts/nsis.py: Tell makensis that WoA is 64 bit

This fixes some settings like the default installation path
for the QEMU installation on Windows on ARM (WoA).

Signed-off-by: Stefan Weil <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit e742b7bdc244499761a21bc1965580c6261a74bf)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 6758c408c36f2c8997bc04630e6d8483046be707
      
https://github.com/qemu/qemu/commit/6758c408c36f2c8997bc04630e6d8483046be707
  Author: Kevin Wolf <[email protected]>
  Date:   2025-12-16 (Tue, 16 Dec 2025)

  Changed paths:
    M blockdev.c

  Log Message:
  -----------
  block: Fix BDS use after free during shutdown

During shutdown, blockdev_close_all_bdrv_states() drops any block node
references that are still owned by the monitor (i.e. the user). However,
in doing so, it forgot to also remove the node from monitor_bdrv_states
(which qmp_blockdev_del() correctly does), which means that later calls
of bdrv_first()/bdrv_next() will still return the (now stale) pointer to
the node.

Usually there is no such call after this point, but in some cases it can
happen. In the reported case, there was an ongoing migration, and the
migration thread wasn't shut down yet: migration_shutdown() called by
qemu_cleanup() doesn't actually wait for the migration to be shut down,
but may just move it to MIGRATION_STATUS_CANCELLING. The next time
migration_iteration_finish() runs, it sees the status and tries to
re-activate all block devices that migration may have previously
inactivated. This is where bdrv_first()/bdrv_next() get called and the
access to the already freed node happens.

It is debatable if migration_shutdown() should really return before
migration has settled, but leaving a dangling pointer in the list of
monitor-owned block nodes is clearly a bug either way and fixing it
solves the immediate problem, so fix it.

Cc: [email protected]
Reported-by: Thomas Huth <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Tested-by: Thomas Huth <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 307bc43095b8ab1765fd66c26003d5da06681c05)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: d763d9b7491940e906aeab0eecee8759c51e8d82
      
https://github.com/qemu/qemu/commit/d763d9b7491940e906aeab0eecee8759c51e8d82
  Author: Hanna Czenczek <[email protected]>
  Date:   2025-12-20 (Sat, 20 Dec 2025)

  Changed paths:
    M block/nvme.c

  Log Message:
  -----------
  nvme: Note in which AioContext some functions run

Sprinkle comments throughout block/nvme.c noting for some functions
(where it may not be obvious) that they require a certain AioContext, or
in which AioContext they do happen to run (for callbacks, BHs, event
notifiers).

Suggested-by: Kevin Wolf <[email protected]>
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit ac3520f599fedee05945ce06bb0f71820a7b2ffc)
(Mjt: pick this comments-only, no-code-changes commit to 10.1.x
 so the next change applies cleanly)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: e20d07862dff86b38168983f16f2b7a1ae42a442
      
https://github.com/qemu/qemu/commit/e20d07862dff86b38168983f16f2b7a1ae42a442
  Author: Hanna Czenczek <[email protected]>
  Date:   2025-12-20 (Sat, 20 Dec 2025)

  Changed paths:
    M block/nvme.c

  Log Message:
  -----------
  Revert "nvme: Fix coroutine waking"

This reverts commit 0f142cbd919fcb6cea7aa176f7e4939925806dd9.
(this is commit 619c2350fae574af67d371f68f701692d9b8487a in 10.1.3)

Said commit changed the replay_bh_schedule_oneshot_event() in
nvme_rw_cb() to aio_co_wake(), allowing the request coroutine to be
entered directly (instead of only being scheduled for later execution).
This can cause the device to become stalled like so:

It is possible that after completion the request coroutine goes on to
submit another request without yielding, e.g. a flush after a write to
emulate FUA.  This will likely cause a nested nvme_process_completion()
call because nvme_rw_cb() itself is called from there.

(After submitting a request, we invoke nvme_process_completion() through
defer_call(); but the fact that nvme_process_completion() ran in the
first place indicates that we are not in a call-deferring section, so
defer_call() will call nvme_process_completion() immediately.)

If this inner nvme_process_completion() loop then processes any
completions, it will write the final completion queue (CQ) head index to
the CQ head doorbell, and subsequently execution will return to the
outer nvme_process_completion() loop.  Even if this loop now finds no
further completions, it still processed at least one completion before,
or it would not have called the nvme_rw_cb() which led to nesting.
Therefore, it will now write the exact same CQ head index value to the
doorbell, which effectively is an unrecoverable error[1].

Therefore, nesting of nvme_process_completion() does not work at this
point.  Reverting said commit removes the nesting (by scheduling the
request coroutine instead of entering it immediately), and so fixes the
stall.

On the downside, reverting said commit breaks multiqueue for nvme, but
better to have single-queue working than neither.  For 11.0, we will
have a solution that makes both work.

A side note: There is a comment in nvme_process_completion() above
qemu_bh_schedule() that claims nesting works, as long as it is done
through the completion_bh.  I am quite sure that is not true, for two
reasons:
- The problem described above, which is even worse when going through
  nvme_process_completion_bh() because that function unconditionally
  writes to the CQ head doorbell,
- nvme_process_completion_bh() never takes q->lock, so
  nvme_process_completion() unlocking it will likely abort.

Given the lack of reports of such aborts, I believe that completion_bh
simply is unused in practice.

[1] See the NVMe Base Specification revision 2.3, page 180, figure 152:
    “Invalid Doorbell Write Value: A host attempted to write an invalid
    doorbell value. Some possible causes of this error are: [...] the
    value written is the same as the previously written doorbell value.”

    To even be notified of this error, we would need to send an
    Asynchronous Event Request to the admin queue (p. 178ff), which we
    don’t do, and then to handle it, we would need to delete and
    recreate the queue (p. 88, section 3.3.1.2 Queue Usage).

Cc: [email protected]
Reported-by: Lukáš Doktor <[email protected]>
Tested-by: Lukáš Doktor <[email protected]>
Signed-off-by: Hanna Czenczek <[email protected]>
Message-id: [email protected]
Signed-off-by: Stefan Hajnoczi <[email protected]>
(cherry picked from commit b002acacc1d72521351501fa0af81d146106c9ed)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 28db12b336325c7f757637c7c1cc32c6ef425952
      
https://github.com/qemu/qemu/commit/28db12b336325c7f757637c7c1cc32c6ef425952
  Author: Thomas Huth <[email protected]>
  Date:   2025-12-20 (Sat, 20 Dec 2025)

  Changed paths:
    M tests/qemu-iotests/common.rc

  Log Message:
  -----------
  tests/qemu-iotests: Fix check for existing file in _require_disk_usage()

Looks like the "$" has been forgotten here to get the contents of
the FILENAME variable.

Fixes: c49dda7254d ("iotests: Filter out ZFS in several tests")
Signed-off-by: Thomas Huth <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit ab0065e36adf8becd9c1ffceec37ee809ce683af)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 831cf1c18bc71e68bf5adc8e66b25d00b8486e1a
      
https://github.com/qemu/qemu/commit/831cf1c18bc71e68bf5adc8e66b25d00b8486e1a
  Author: Thomas Huth <[email protected]>
  Date:   2025-12-20 (Sat, 20 Dec 2025)

  Changed paths:
    M qga/commands-linux.c

  Log Message:
  -----------
  qga: Fix ubsan warning

When compiling QEMU with --enable-ubsan there is a undefined behavior
warning when running "make check":

 .../qga/commands-linux.c:452:15: runtime error: applying non-zero offset 5 to 
null pointer
 #0 0x55ea7b89450c in build_guest_fsinfo_for_pci_dev 
..../qga/commands-linux.c:452:15

Fix it by avoiding the additional pointer variable here and use an
"offset" integer variable instead.

Signed-off-by: Thomas Huth <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Kostiantyn Kostiuk <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Kostiantyn Kostiuk <[email protected]>
(cherry picked from commit 83f6dceb8f5c0a1efe806a9a4905cbc743a8a378)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 46ff6a1ca220506e94532dbc1d91725430b355bf
      
https://github.com/qemu/qemu/commit/46ff6a1ca220506e94532dbc1d91725430b355bf
  Author: Cédric Le Goater <[email protected]>
  Date:   2025-12-20 (Sat, 20 Dec 2025)

  Changed paths:
    M backends/tpm/tpm_passthrough.c
    M block/vmdk.c
    M block/vvfat.c
    M gdbstub/gdbstub.c
    M qga/commands-linux.c
    M ui/ui-hmp-cmds.c
    M util/log.c

  Log Message:
  -----------
  Fix const qualifier build errors with recent glibc

A recent change in glibc 2.42.9000 [1] changes the return type of
strstr() and other string functions to be 'const char *' when the
input is a 'const char *'.

This breaks the build in various files with errors such as :

  error: initialization discards 'const' qualifier from pointer target type 
[-Werror=discarded-qualifiers]
    208 |         char *pidstr = strstr(filename, "%");
        |                        ^~~~~~

Fix this by changing the type of the variables that store the result
of these functions to 'const char *'.

[1] 
https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690

Signed-off-by: Cédric Le Goater <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 326e620fc0145686124f754194cdc6d0d9b3400d)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: e436f7bb3679e4f1b73ee18b74134521ad09c635
      
https://github.com/qemu/qemu/commit/e436f7bb3679e4f1b73ee18b74134521ad09c635
  Author: Cédric Le Goater <[email protected]>
  Date:   2025-12-20 (Sat, 20 Dec 2025)

  Changed paths:
    M hw/i386/x86-common.c

  Log Message:
  -----------
  i386: Fix const qualifier build errors with recent glibc

A recent change in glibc 2.42.9000 [1] changes the return type of
strstr() and other string functions to be 'const char *' when the
input is a 'const char *'. This breaks the build in :

  ../hw/i386/x86-common.c:827:11: error: assignment discards ‘const’ qualifier 
from pointer target type [-Werror=discarded-qualifiers]
  827 |     vmode = strstr(kernel_cmdline, "vga=");
      |           ^

Fix this by changing the type of the variables that store the result
of these functions to 'const char *'.

[1] 
https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690

Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit 2f5c96d53409160b11f031b22f2d947f75ab06ab)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 9b13c950b9faa99454d23229506a04cb5889b711
      
https://github.com/qemu/qemu/commit/9b13c950b9faa99454d23229506a04cb5889b711
  Author: Cédric Le Goater <[email protected]>
  Date:   2025-12-20 (Sat, 20 Dec 2025)

  Changed paths:
    M tests/vhost-user-bridge.c

  Log Message:
  -----------
  tests/vhost-user-bridge.c: Fix const qualifier build errors with recent glibc

A recent change in glibc 2.42.9000 [1] changes the return type of
strstr() and other string functions to be 'const char *' when the
input is a 'const char *'. This breaks the build in :

../tests/vhost-user-bridge.c: In function ‘vubr_parse_host_port’:
../tests/vhost-user-bridge.c:749:15: error: initialization discards ‘const’ 
qualifier from pointer target type [-Werror=discarded-qualifiers]
  749 |     char *p = strchr(buf, ':');
      |               ^~~~~~

Fix this by using the glib g_strsplit() routine instead of strdup().

[1] 
https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690

Suggested-by: Peter Maydell <[email protected]>
Acked-by: Yodel Eldar <[email protected]>
Tested-by: Yodel Eldar <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit e37a0d514a17a660434ea20c0dd84bc6c20ca517)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: d15bb0b3e406d737be10dd15a2e232730e35f77f
      
https://github.com/qemu/qemu/commit/d15bb0b3e406d737be10dd15a2e232730e35f77f
  Author: Cédric Le Goater <[email protected]>
  Date:   2025-12-20 (Sat, 20 Dec 2025)

  Changed paths:
    M monitor/hmp.c

  Log Message:
  -----------
  monitor: Fix const qualifier build errors with recent glibc

A recent change in glibc 2.42.9000 [1] changes the return type of
strchr() and other string functions to be 'const char *' when the
input is a 'const char *'. This breaks the build in :

../monitor/hmp.c:589:7: error: assignment discards ‘const’ qualifier from 
pointer target type [-Werror=discarded-qualifiers]
  589 |     p = strchr(type, ':');
      |       ^

Fix this by changing the type of the variables that store the result
of these functions to 'const char *'.

[1] 
https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690

Reviewed-by: Thomas Huth <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit dfe87815ba450228811f3abc633d7dc02757922e)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 05836f5f817ee73fa88687af9fbdcfb2efd9d690
      
https://github.com/qemu/qemu/commit/05836f5f817ee73fa88687af9fbdcfb2efd9d690
  Author: Cédric Le Goater <[email protected]>
  Date:   2025-12-20 (Sat, 20 Dec 2025)

  Changed paths:
    M gdbstub/user.c

  Log Message:
  -----------
  gdbstub: Fix const qualifier build errors with recent glibc

A recent change in glibc 2.42.9000 [1] changes the return type of
strstr() and other string functions to be 'const char *' when the
input is a 'const char *'. This breaks the build in :

../gdbstub/user.c:322:21: error: assignment discards ‘const’ qualifier from 
pointer target type [-Werror=discarded-qualifiers]
  322 |     pid_placeholder = strstr(path, "%d");
      |                     ^
Fix this by changing the type of the variables that store the result
of these functions to 'const char *'.

[1] 
https://sourceware.org/git/?p=glibc.git;a=commit;h=cd748a63ab1a7ae846175c532a3daab341c62690

Reviewed-by: Thomas Huth <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit d7e1df769910da9d832dda86b01fe1363e4f4a3c)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: ede2f1e49c5e543643daf74f3c12323a3e475315
      
https://github.com/qemu/qemu/commit/ede2f1e49c5e543643daf74f3c12323a3e475315
  Author: Zesen Liu <[email protected]>
  Date:   2025-12-20 (Sat, 20 Dec 2025)

  Changed paths:
    M hw/core/qdev-properties.c

  Log Message:
  -----------
  qdev: fix error handling in set_uint64_checkmask

When specifying lbr_fmt=VALUE in cpu options with an invalid VALUE, 
error_setg() gets triggered twice, causing an assertion failure in error_setv() 
which requires *errp to be NULL, preventing meaningful error messages from 
being displayed.

Fix this by checking visit_type_uint64()'s return value and returning early on 
failure, consistent with other property setters like set_string().

Fixes: 18c22d7112a7 (qdev-properties: Add a new macro with bitmask check for 
uint64_t property)
Cc: [email protected]
Signed-off-by: Zesen Liu <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
[Add Fixes: and Cc:]
Signed-off-by: Markus Armbruster <[email protected]>
(cherry picked from commit 00829ae3845fd11e56239390924e3e74c3a4c144)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 82a3e0c6f9b4397b19aff475cc2f7e896d6a9b9b
      
https://github.com/qemu/qemu/commit/82a3e0c6f9b4397b19aff475cc2f7e896d6a9b9b
  Author: Andrew Cooper <[email protected]>
  Date:   2025-12-29 (Mon, 29 Dec 2025)

  Changed paths:
    M target/i386/tcg/user/seg_helper.c

  Log Message:
  -----------
  target/i386: Fix #GP error code for INT instructions

While the (intno << shift) expression is correct for indexing the IDT based on
whether Long Mode is active, the error code itself was unchanged with AMD64,
and is still the index with 3 bits of metadata in the bottom.

Found when running a Xen unit test, all under QEMU.  The unit test objected to
being told there was an error with IDT index 256 when INT $0x80 (128) was the
problem instruction:

  ...
  Error: Unexpected fault 0x800d0802, #GP[IDT[256]]
  ...

Fixes: d2fd1af76777 ("x86_64 linux user emulation")
Signed-off-by: Andrew Cooper <[email protected]>
Link: 
https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3160
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 60efba3c1bff0d78632d45c2dc927c5bc7a17ba8)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 4029ff773e590a2758493cd5a00417bc26409262
      
https://github.com/qemu/qemu/commit/4029ff773e590a2758493cd5a00417bc26409262
  Author: Paolo Bonzini <[email protected]>
  Date:   2025-12-29 (Mon, 29 Dec 2025)

  Changed paths:
    M target/i386/tcg/decode-new.c.inc

  Log Message:
  -----------
  target/i386/tcg: ignore V3 in 32-bit mode

>From the manual: "In 64-bit mode all 4 bits may be used. [...]
In 32-bit and 16-bit modes bit 6 must be 1 (if bit 6 is not 1, the
2-byte VEX version will generate LDS instruction and the 3-byte VEX
version will ignore this bit)."

Cc: [email protected]
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 0db1b556e4bcd7a51f222cda9e14850f88fe3f88)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 832f421978084b5e1dc9fa8f3df54b39371b3c37
      
https://github.com/qemu/qemu/commit/832f421978084b5e1dc9fa8f3df54b39371b3c37
  Author: Alano Song <[email protected]>
  Date:   2025-12-31 (Wed, 31 Dec 2025)

  Changed paths:
    M hw/i2c/imx_i2c.c

  Log Message:
  -----------
  hw/i2c/imx: Fix trace func name error

Signed-off-by: Alano Song <[email protected]>
Fixes: e589c0ea9c9 ("hw/i2c/imx_i2c: Convert DPRINTF() to trace events")
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 3fbadbb3927a92db1932baee0c1188b05c0ac6b1)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 32a8e10684253b6403aafb70866619db7ec9ad39
      
https://github.com/qemu/qemu/commit/32a8e10684253b6403aafb70866619db7ec9ad39
  Author: Cédric Le Goater <[email protected]>
  Date:   2026-01-06 (Tue, 06 Jan 2026)

  Changed paths:
    M tests/functional/test_arm_aspeed_gb200nvl_bmc.py

  Log Message:
  -----------
  tests/functional: Fix URL of gb200nvl-bmc image

Commit [1] moved the FW image of the gb200nvl-bmc machine and broke
the associated functional test. Fix that.

[1] 
https://github.com/legoater/qemu-aspeed-boot/commit/52451b2472eeb40aa97e131aeea327e9d4a8a78a

Cc: Ed Tanous <[email protected]>
Cc: Patrick Williams <[email protected]>
Tested-by: Philippe Mathieu-Daudé <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit 75bcfb98a13d14beb2ea95fb3c51da01c7102325)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 020288b0929148fde928a65c9db30aed741ff059
      
https://github.com/qemu/qemu/commit/020288b0929148fde928a65c9db30aed741ff059
  Author: Jie Song <[email protected]>
  Date:   2026-01-08 (Thu, 08 Jan 2026)

  Changed paths:
    M chardev/char-io.c
    M chardev/char-socket.c
    M include/chardev/char-io.h
    M include/chardev/char.h
    M monitor/qmp.c

  Log Message:
  -----------
  monitor/qmp: cleanup SocketChardev listener sources early to avoid fd 
handling race

When starting a dummy QEMU process with virsh version, monitor_init_qmp()
enables IOThread monitoring of the QMP fd by default. However, a race
condition exists during the initialization phase: the IOThread only removes
the main thread's fd watch when it reaches 
qio_net_listener_set_client_func_full(),
which may be delayed under high system load.

This creates a window between monitor_qmp_setup_handlers_bh() and
qio_net_listener_set_client_func_full() where both the main thread and
IOThread are simultaneously monitoring the same fd and processing events.
This race can cause either the main thread or the IOThread to hang and
become unresponsive.

Fix this by proactively cleaning up the listener's IO sources in
monitor_init_qmp() before the IOThread initializes QMP monitoring,
ensuring exclusive fd ownership and eliminating the race condition.

Signed-off-by: Jie Song <[email protected]>
Reviewed-by: Marc-André Lureau <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit e714f1a3d4d1e66b9a3ff4be1ff999c32bbef29e)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: f71aca857a1ee6b703007ee7270e1933623e68ed
      
https://github.com/qemu/qemu/commit/f71aca857a1ee6b703007ee7270e1933623e68ed
  Author: Richard Henderson <[email protected]>
  Date:   2026-01-13 (Tue, 13 Jan 2026)

  Changed paths:
    M tcg/optimize.c

  Log Message:
  -----------
  tcg/optimize: Save o_mask in fold_masks_zosa_int

When adding o_mask to this function, we used it in a
couple of places but failed to save it for future use.
Also, update a related comment.

Cc: [email protected]
Fixes: 56f15f67ea1 ("tcg/optimize: Add one's mask to TempOptInfo")
Reported-by: Manos Pitsidianakis <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 7d2d577de0c72f3cf2eb43f1534e908070d3bc47)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: ccb199fc95bee6e851fb01e703a53adcbcf43241
      
https://github.com/qemu/qemu/commit/ccb199fc95bee6e851fb01e703a53adcbcf43241
  Author: Richard Henderson <[email protected]>
  Date:   2026-01-13 (Tue, 13 Jan 2026)

  Changed paths:
    M tcg/optimize.c

  Log Message:
  -----------
  tcg/optimize: Fix a_mask computation for orc

In computing a_mask, for or, we remove the bits from t1->o_mask
which are known to be zero.  For orc, the bits known to be zero
are the inverse of those known to be one.

Cc: [email protected]
Fixes: cc4033ee47c ("tcg/optimize: Build and use zero, one and affected bits in 
fold_orc")
Reviewed-by: Pierrick Bouvier <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 08b12bfb8f532dbc62e35c31d081ede1aa12098b)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: e0842a3275dcc832f04af436290b546775529d0a
      
https://github.com/qemu/qemu/commit/e0842a3275dcc832f04af436290b546775529d0a
  Author: Paolo Bonzini <[email protected]>
  Date:   2026-01-13 (Tue, 13 Jan 2026)

  Changed paths:
    M tcg/optimize.c

  Log Message:
  -----------
  tcg/optimize: Do use affected bits

We inadvertently disabled affected bits optimizations on operations
that use fold_masks_zosa.  These happen relatively often in x86 code
for extract/sextract; for example given the following:

   mov %esi, %ebp
   xor $0x1, %ebp

the optimizer is able to simplify the "extract_i64 rbp,tmp0,$0x0,$0x20"
produced by the second instruction to a move.

Cc: [email protected]
Fixes: 932522a9ddc ("tcg/optimize: Fold and to extract during optimize")
Signed-off-by: Paolo Bonzini <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 23b53ec3a8a279cb5acd5e022b464a4272fe9f8c)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 944741cfa53dfc2496d89ea7fd60f5e3102ae7c3
      
https://github.com/qemu/qemu/commit/944741cfa53dfc2496d89ea7fd60f5e3102ae7c3
  Author: Richard Henderson <[email protected]>
  Date:   2026-01-13 (Tue, 13 Jan 2026)

  Changed paths:
    M tcg/riscv/tcg-target.c.inc

  Log Message:
  -----------
  tcg/riscv: Fix TCG_REG_TMP0 clobber in tcg_gen_dup{m,i}

TCG_REG_TMP0 may be used by set_vtype* to load the vtype
parameter, so delay any other use of TCG_REG_TMP0 until
the correct vtype has been installed.

Cc: [email protected]
Fixes: d4be6ee1111 ("tcg/riscv: Implement vector mov/dup{m/i}")
Reported-by: Zhijin Zeng <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit af6db3b71310ea63a018d517ba7d79e4e014db62)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 48437a384aaa38e882a8646c4202dd9929426d9e
      
https://github.com/qemu/qemu/commit/48437a384aaa38e882a8646c4202dd9929426d9e
  Author: Jean-Christian CÎRSTEA <[email protected]>
  Date:   2026-01-13 (Tue, 13 Jan 2026)

  Changed paths:
    M linux-user/syscall.c

  Log Message:
  -----------
  linux-user: allow null `pathname` for statx()/fstatat()

Since Linux 6.11, the path argument may be NULL.

Before this patch, qemu-*-linux-user failed with EFAULT when `pathname` was
specified as NULL, even for Linux kernel hosts > 6.10. This patch fixes this
issue by checking whether `arg2` is 0. If so, don't return EFAULT, but instead
perform the appropiate syscall and let the host's kernel handle null `pathname`.

Cc: [email protected]
Signed-off-by: Jean-Christian CÎRSTEA <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 82ae60c8b5cb98d610056a1e2d0ba72e9ef7907c)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 1b5caf073f49c37ccbc91baad08fc28b0320fb06
      
https://github.com/qemu/qemu/commit/1b5caf073f49c37ccbc91baad08fc28b0320fb06
  Author: Matthew Lugg <[email protected]>
  Date:   2026-01-13 (Tue, 13 Jan 2026)

  Changed paths:
    M linux-user/mmap.c

  Log Message:
  -----------
  linux-user: fix mremap unmapping adjacent region

This typo meant that calls to `mremap` which shrink a mapping by some N
bytes would, when the virtual address space was pre-reserved (e.g.
32-bit guest on 64-bit host), unmap the N bytes following the *original*
mapping.

Signed-off-by: Matthew Lugg <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit aaed9ca1797d70a507371aea688c5cd60b074e2d)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 1f65eb3d5d6a301ac6d64f721e82813a1c294f76
      
https://github.com/qemu/qemu/commit/1f65eb3d5d6a301ac6d64f721e82813a1c294f76
  Author: Matthew Lugg <[email protected]>
  Date:   2026-01-13 (Tue, 13 Jan 2026)

  Changed paths:
    M linux-user/mmap.c

  Log Message:
  -----------
  linux-user: fix mremap errors for invalid ranges

If an address range given to `mremap` is invalid (exceeds addressing
bounds on the guest), we were previously returning `ENOMEM`, which is
not correct. The manpage and the Linux kernel implementation both agree
that if `old_addr`/`old_size` refer to an invalid address, `EFAULT` is
returned, and if `new_addr`/`new_size` refer to an invalid address,
`EINVAL` is returned.

Signed-off-by: Matthew Lugg <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 2422884ec5a12037d2378f45ca1411d3f37c7081)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 3ef571a4da12abfa65d47395177c24dafd31ee10
      
https://github.com/qemu/qemu/commit/3ef571a4da12abfa65d47395177c24dafd31ee10
  Author: Matthew Lugg <[email protected]>
  Date:   2026-01-13 (Tue, 13 Jan 2026)

  Changed paths:
    M linux-user/mmap.c

  Log Message:
  -----------
  linux-user: fix reserved_va page leak in do_munmap

The old logic had an off-by-one bug. For instance, assuming 4k pages on
host and guest, if 'len' is '4097' (indicating to unmap 2 pages), then
'last = start + 4096', so 'real_last = start + 4095', so ultimately
'real_len = 4096'. I do not believe this could cause any observable bugs
in guests, because `target_munmap` page-aligns the length it passes in.
However, calls to this function in `target_mremap` do not page-align the
length, so those calls could "drop" pages, leading to a part of the
reserved region becoming unmapped. At worst, a host allocation could get
mapped into that hole, then clobbered by a new guest mapping.

Signed-off-by: Matthew Lugg <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 81ceab30492ed251addae8539f7b69a069b0f984)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 4ec12db86e597d69e371809ea56c8aaecc39418c
      
https://github.com/qemu/qemu/commit/4ec12db86e597d69e371809ea56c8aaecc39418c
  Author: Matthew Lugg <[email protected]>
  Date:   2026-01-13 (Tue, 13 Jan 2026)

  Changed paths:
    M tests/tcg/multiarch/test-mmap.c

  Log Message:
  -----------
  tests: add tcg coverage for fixed mremap bugs

These tests cover the first two fixes in this patch series. The final
patch is not covered because the bug it fixes is not easily observable
by the guest.

Signed-off-by: Matthew Lugg <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 9290c10ae9d0c3ff433efbb7ecb0e781966c5404)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: c51a95908199977677838cf870f7af0e63d08d25
      
https://github.com/qemu/qemu/commit/c51a95908199977677838cf870f7af0e63d08d25
  Author: Fabiano Rosas <[email protected]>
  Date:   2026-01-13 (Tue, 13 Jan 2026)

  Changed paths:
    M hw/ppc/spapr.c
    M target/ppc/cpu.h
    M target/ppc/cpu_init.c
    M target/ppc/machine.c

  Log Message:
  -----------
  target/ppc: Fix env->quiesced migration

The commit referenced (from QEMU 10.0) has changed the way the pseries
machine marks a cpu as quiesced. Previously, the cpu->halted value
from QEMU common cpu code was (incorrectly) used. With the fix, the
env->quiesced variable starts being used, which improves on the
original situation, but also causes a side effect after migration:

The env->quiesced is set at reset and never migrated, which causes the
destination QEMU to stop delivering interrupts and hang the machine.

To fix the issue from this point on, start migrating the env->quiesced
value.

For QEMU versions < 10.0, sending the new element on the stream would
cause migration to be aborted, so add the appropriate compatibility
property to omit the new subsection.

Independently of this patch, all migrations from QEMU versions < 10.0
would result in a hang since the older QEMU never migrates
env->quiesced. This is bad because it leaves machines already running
on the old QEMU without a migration path into newer versions.

As a workaround, use a few heuristics to infer the new value of
env->quiesced based on cpu->halted, LPCR and PSSCR bits that are
usually set/cleared along with quiesced.

Note that this was tested with -cpu power9 and -machine ic-mode=xive
due to another bug affecting migration of XICS guests. Tested both
forward and backward migration and savevm/loadvm from 9.2 and 10.0.

Also tested loadvm of a savevm image that contains a mix of cpus both
halted and not halted.

Reported-by: Fabian Vogt <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3079
Fixes: fb802acdc8b ("ppc/spapr: Fix RTAS stopped state")
Acked-by: Chinmay Rath <[email protected]>
Reviewed-by: Harsh Prateek Bora <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Harsh Prateek Bora <[email protected]>
(cherry picked from commit 628bda1ab7596a7cceb1c5356d23a92001c7a8c5)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 827c5bfe331c86bf28cc2d8e79b04c877ffc82e8
      
https://github.com/qemu/qemu/commit/827c5bfe331c86bf28cc2d8e79b04c877ffc82e8
  Author: Paolo Bonzini <[email protected]>
  Date:   2026-01-13 (Tue, 13 Jan 2026)

  Changed paths:
    M configs/meson/windows.txt

  Log Message:
  -----------
  configs: use default prefix for Windows compilation

The update to Python 3.13 causes meson configuration to fail, see e.g.:

   https://gitlab.com/qemu-project/qemu/-/jobs/12672816538#L397

   meson.build:1:0: ERROR: prefix value '/qemu' must be an absolute path

This is https://github.com/mesonbuild/meson/issues/14303.  Remove the
prefix='/qemu' line in configs/meson/windows.txt, since commit d17f305a264
("configure: use a platform-neutral prefix", 2020-09-30) says that the
NSIS installer doesn't care.

Cc: [email protected]
Cc: Thomas Huth <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 894c8bd56ff1d25127efa4ba9ee8cf4dd0670b1a)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 768ad6c12c97310c29b24e112b674ad6335e2005
      
https://github.com/qemu/qemu/commit/768ad6c12c97310c29b24e112b674ad6335e2005
  Author: Laurent Vivier <[email protected]>
  Date:   2026-01-16 (Fri, 16 Jan 2026)

  Changed paths:
    M target/m68k/op_helper.c

  Log Message:
  -----------
  m68k: fix CAS2 writeback when Dc1==Dc2

According to Programmer's Reference Manual, if Dc1 and Dc2 specify the
same data register and the comparison fails, memory operand 1 is stored
in the data register.

The current helpers wrote Dc1 then Dc2, leaving operand 2 in the shared
register.

Swap the writeback order for cas2w/cas2l so memory operand 1 wins.

Signed-off-by: Laurent Vivier <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 11dac41f2e830bcd7ba74969dc50f5740e3ce7e7)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: bd792679ca8e6b2332e829cfba15421f501db8e8
      
https://github.com/qemu/qemu/commit/bd792679ca8e6b2332e829cfba15421f501db8e8
  Author: Paolo Bonzini <[email protected]>
  Date:   2026-01-16 (Fri, 16 Jan 2026)

  Changed paths:
    M target/i386/tcg/decode-new.c.inc
    M target/i386/tcg/decode-new.h

  Log Message:
  -----------
  target/i386/tcg: do not mark all SSE instructions as unaligned

If the vex_special field was not initialized, it was considered to be
X86_VEX_SSEUnaligned (whose value was zero).  Add a new value to
fix that.

Cc: [email protected]
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 73dd6e4a36dd8d85548292f382a4d479e2810371)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 766c34ccf51118b767b43c25201f899a3e10762a
      
https://github.com/qemu/qemu/commit/766c34ccf51118b767b43c25201f899a3e10762a
  Author: Paolo Bonzini <[email protected]>
  Date:   2026-01-16 (Fri, 16 Jan 2026)

  Changed paths:
    M target/i386/ops_sse.h
    M target/i386/tcg/emit.c.inc
    M target/i386/tcg/ops_sse_header.h.inc

  Log Message:
  -----------
  target/i386/tcg: mask addresses for VSIB

VSIB can have either 32-bit or 64-bit addresses, pass a constant mask to
the helper and apply it before the load.

Cc: [email protected]
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 5e3572ef2e94608568b1a73eab9d382b250936eb)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 2a5702068926db6f6e95108b60fc9805f9757e8c
      
https://github.com/qemu/qemu/commit/2a5702068926db6f6e95108b60fc9805f9757e8c
  Author: Paolo Bonzini <[email protected]>
  Date:   2026-01-16 (Fri, 16 Jan 2026)

  Changed paths:
    M target/i386/tcg/decode-new.c.inc

  Log Message:
  -----------
  target/i386/tcg: allow VEX in 16-bit protected mode

VEX is only forbidden in real and vm86 mode; 16-bit protected mode supports
it for some unfathomable reason.

Cc: [email protected]
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit ed88bdcfbdcf9d411607cd690f93f915feff6a5b)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 43fd7e29babdaf8b4b450095b64d5ddb461531bc
      
https://github.com/qemu/qemu/commit/43fd7e29babdaf8b4b450095b64d5ddb461531bc
  Author: Vulnerability Report <[email protected]>
  Date:   2026-01-16 (Fri, 16 Jan 2026)

  Changed paths:
    M hw/i386/kvm/xen_evtchn.c

  Log Message:
  -----------
  hw/i386/kvm: fix PIRQ bounds check in xen_physdev_map_pirq()

Reject pirq == s->nr_pirqs in xen_physdev_map_pirq().

Fixes: aa98ee38a5 ("hw/xen: Implement emulated PIRQ hypercall support")
Fixes: CVE-2026-0665
Reported-by: DARKNAVY (@DarkNavyOrg) <[email protected]>
Reviewed-by: David Woodhouse <[email protected]>
Signed-off-by: Vulnerability Report <[email protected]>
Link: 
https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit c7504ba2a560fd884557f6e5142f03b491aad0c7)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: eb6ec3d5a83b52b7a03264261327b6d7205ade8a
      
https://github.com/qemu/qemu/commit/eb6ec3d5a83b52b7a03264261327b6d7205ade8a
  Author: Xianglai Li <[email protected]>
  Date:   2026-01-18 (Sun, 18 Jan 2026)

  Changed paths:
    M hw/loongarch/virt-fdt-build.c

  Log Message:
  -----------
  hw/loongarch/virt: Modify the interrupt trigger type in fdt table

In the loongarch virt fdt file, the interrupt trigger type directly
uses magic numbers. Now, refer to the definitions in the linux kernel and
use macro definitions.

Signed-off-by: Xianglai Li <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
(cherry picked from commit 47de28a0b7fb96531271aaeaa3e7f2cad2b91221)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 4f702110f4044694111eda4b02fcbd16e9b557ef
      
https://github.com/qemu/qemu/commit/4f702110f4044694111eda4b02fcbd16e9b557ef
  Author: Xianglai Li <[email protected]>
  Date:   2026-01-18 (Sun, 18 Jan 2026)

  Changed paths:
    M hw/loongarch/virt-fdt-build.c

  Log Message:
  -----------
  hw/loongarch/virt: Fix irq allocation failure with pci device from fdt

When we use the -kernel parameter to start an elf format kernel relying on
fdt, we get the following error:

pcieport 0000:00:01.0: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.0: enabling device (0000 -> 0003)
pcieport 0000:00:01.0: PME: Signaling with IRQ 19
pcieport 0000:00:01.0: AER: enabled with IRQ 19
pcieport 0000:00:01.1: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.1: enabling device (0000 -> 0003)
pcieport 0000:00:01.1: PME: Signaling with IRQ 20
pcieport 0000:00:01.1: AER: enabled with IRQ 20
pcieport 0000:00:01.2: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.2: enabling device (0000 -> 0003)
pcieport 0000:00:01.2: PME: Signaling with IRQ 21
pcieport 0000:00:01.2: AER: enabled with IRQ 21
pcieport 0000:00:01.3: of_irq_parse_pci: failed with rc=-22
pcieport 0000:00:01.3: enabling device (0000 -> 0003)
pcieport 0000:00:01.3: PME: Signaling with IRQ 22
pcieport 0000:00:01.3: AER: enabled with IRQ 22
pcieport 0000:00:01.4: of_irq_parse_pci: failed with rc=-22

This is because  the description of interrupt-cell is missing in the pcie
irq map.  And there is a lack of a description of the interrupt trigger
type.  Now it is corrected and the correct interrupt-cell is added in the
pcie irq map.

Refer to the implementation in arm and add some comments.

Signed-off-by: Xianglai Li <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
(cherry picked from commit ff54394eed148c642f83b45753c7898acdbd5ddb)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: e39caabd233fe782ee4832a65e273bc396e07435
      
https://github.com/qemu/qemu/commit/e39caabd233fe782ee4832a65e273bc396e07435
  Author: Song Gao <[email protected]>
  Date:   2026-01-18 (Sun, 18 Jan 2026)

  Changed paths:
    M target/loongarch/cpu.c

  Log Message:
  -----------
  target/loongach: Fix some exceptions failure in updating CSR_BADV

According to Volume 1 Manual 7.4.8 ,exception,SYS,BRK,INE,IPE,PPD
FPE,SXD,ASXD are need't update CSR_BADV, this patch correct it.

Signed-off-by: Song Gao <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
(cherry picked from commit 70cf9b7bf7aff47f8d85ccce35b688dd91335cf0)
(Mjt: the changes are in target/loongarch/cpu.h in 10.1)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 47f5eb44e3cb8671b1a6a4a378ee1e275425fc2f
      
https://github.com/qemu/qemu/commit/47f5eb44e3cb8671b1a6a4a378ee1e275425fc2f
  Author: Song Gao <[email protected]>
  Date:   2026-01-18 (Sun, 18 Jan 2026)

  Changed paths:
    M target/loongarch/cpu.c

  Log Message:
  -----------
  target/loongarch: Fix exception BCE missing to update CSR_BADV

Exception BCE need update CSR_BADV, and the value is env->pc.

Signed-off-by: Song Gao <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
(cherry picked from commit e4f0ef58d53eb20056f9f3ca9f21dbbbf25f2530)
(Mjt: the changes are in target/loongarch/cpu.c in 10.1)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 469308eeb8f1677aa61a424eb9681c3504eeb9d2
      
https://github.com/qemu/qemu/commit/469308eeb8f1677aa61a424eb9681c3504eeb9d2
  Author: Song Gao <[email protected]>
  Date:   2026-01-18 (Sun, 18 Jan 2026)

  Changed paths:
    M target/loongarch/cpu.c

  Log Message:
  -----------
  target/loongarch: Fix exception ADEF/ADEM missing to update CSR_BADV

Exception ADEM/ADEF need update CSR_BADV, the value from the virtual
address.

Signed-off-by: Song Gao <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
(cherry picked from commit a7be2e0a3f7d0f35bcc3b17e2b558084efc5d9fe)
(Mjt: the changes are in target/loongarch/cpu.c in 10.1)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 86b3d3969935cb056425d6b6f23943ed3b19a5ed
      
https://github.com/qemu/qemu/commit/86b3d3969935cb056425d6b6f23943ed3b19a5ed
  Author: Yao Zi <[email protected]>
  Date:   2026-01-18 (Sun, 18 Jan 2026)

  Changed paths:
    M hw/loongarch/virt.c

  Log Message:
  -----------
  hw/loongarch/virt: Don't abort on access to unimplemented IOCSR

Since commit f2e61edb2946 ("hw/loongarch/virt: Use MemTxAttrs interface
for misc ops") which adds a call to g_assert_not_reached() in the path
of handling unimplemented IOCSRs, QEMU would abort when the guest
accesses unimplemented IOCSRs.

This is too serious since there's nothing fatal happening in QEMU
itself, and the guest could probably continue running if we give zero as
result for these reads, which also matches the behavior observed on
3A5000M real machine.

Replace the assertion with qemu_log_mask(LOG_UNIMP, ...), it's still
possible to examine unimplemented IOCSR access through "-d unimp"
command line arguments.

Fixes: f2e61edb2946 ("hw/loongarch/virt: Use MemTxAttrs interface for misc ops")
Signed-off-by: Yao Zi <[email protected]>
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
(cherry picked from commit 49ee001a5b8378e9a9b3db8cbf61e7eda970ecd2)
(Mjt: trivial context fix for 10.1)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: a246fac13b0691cfd2abc9ad27e0b152e05ec84c
      
https://github.com/qemu/qemu/commit/a246fac13b0691cfd2abc9ad27e0b152e05ec84c
  Author: Alex Bennée <[email protected]>
  Date:   2026-01-18 (Sun, 18 Jan 2026)

  Changed paths:
    M tests/functional/test_arm_aspeed_rainier.py

  Log Message:
  -----------
  tests/functional: migrate aspeed_rainier image

Cedric has a host for the file which allows us to keep the name.

Cc: [email protected]
Signed-off-by: Alex Bennée <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Message-id: [email protected]
Cc: Cédric Le Goater <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 7cf096d609e67fd06abf6a59e592cb6de427825c)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: c9ac53e1d432140e76693f04c342d5aca8e2c1d2
      
https://github.com/qemu/qemu/commit/c9ac53e1d432140e76693f04c342d5aca8e2c1d2
  Author: Peter Maydell <[email protected]>
  Date:   2026-01-18 (Sun, 18 Jan 2026)

  Changed paths:
    M target/arm/helper.c

  Log Message:
  -----------
  target/arm: Don't specify ID_PFR1 accessfn twice

In the definition of ID_PFR1 we have an ifdef block; we specify the
accessfn once in the common part of the ifdef and once in the
not-user-only part, which is redundant but harmless.

The accessfn will always return success in user-only mode (because
we won't trap to EL2), so specify it only in the not-user-only
half of the ifdef, as was probably the intention.

This is only cc'd to stable to avoid a textual conflict with
the following patch, which is a bug fix.

Cc: [email protected]
Fixes: 0f150c8499e970bd ("target/arm: Constify ID_PFR1 on user emulation")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 8da52b8401afa34ea8caa58e1bfb321ae142899b)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: d32a6bdf2e683a2c0b3a4d03aabcd67184b293c7
      
https://github.com/qemu/qemu/commit/d32a6bdf2e683a2c0b3a4d03aabcd67184b293c7
  Author: Peter Maydell <[email protected]>
  Date:   2026-01-18 (Sun, 18 Jan 2026)

  Changed paths:
    M target/arm/helper.c

  Log Message:
  -----------
  target/arm: Correctly honour HCR.TID3 for v7A cores

The HCR.TID3 bit defines that we should trap to the hypervisor for
reads to a collection of ID registers. Different architecture versions
have defined this differently:

 * v7A has a set of ID regs that definitely must trap:
    - ID_PFR{0,1}, ID_DFR0, ID_AFR0, ID_MMFR{0,1,2,3},
      ID_ISAR{0,1,2,3,4,5}, MVFR{0,1}
   and somewhat vaguely says that "there is no requirement"
   to trap for registers that are reserved in the ID reg space
   (i.e. which RAZ and might be used for new ID regs in future)
 * v8A adds to this list:
    - ID_PFR2 and MVFR2 must trap
    - ID_MMFR4, ID_MMFR5, ID_ISAR6, ID_DFR1 and reserved registers
      in the ID reg space must trap if FEAT_FGT is implemented,
      and it is IMPDEF if they trap if FEAT_FGT is not implemented

In QEMU we seem to have attempted to implement this distinction
(taking the "we do trap" IMPDEF choice if no FEAT_FGT), with
access_aa64_tid3() always trapping on TID3 and access_aa32_tid3()
trapping only if ARM_FEATURE_V8 is set.  However, we didn't apply
these to the right set of registers: we use access_aa32_tid3() on all
the 32-bit ID registers *except* ID_PFR2, ID_DFR1, ID_MMFR5 and the
RES0 space, which means that for a v7 CPU we don't trap on a lot of
registers that we should trap on, and we do trap on various things
that the v7A Arm ARM says there is "no requirement" to trap on.

Straighten this out by naming the access functions more clearly for
their purpose, and documenting this: access_v7_tid3() is only for the
fixed set of ID registers that v7A traps on HCR.TID3, and
access_tid3() is for any others, including the reserved encoding
spaces and any new registers we add in future.

AArch32 MVFR2 access is handled differently, in check_hcr_el2_trap;
there we already do not trap on TID3 on v7A cores (where MVFR2
doesn't exist), because we in the code-generation function we UNDEF
if ARM_FEATURE_V8 is not set, without generating code to call
check_hcr_el2_trap.

This bug was causing a problem for Xen which (after a recent change
to Xen) expects to be able to trap ID_PFR0 on a Cortex-A15.

The result of these changes is that our v8A behaviour remains
the same, and on v7A we now trap the registers the Arm ARM definitely
requires us to trap, and don't trap the reserved space that "there is
no requirement" to trap.

Cc: [email protected]
Fixes: 6a4ef4e5d1084c ("target/arm: Honor HCR_EL2.TID3 trapping requirements")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 205ca535abaceda375c54797b1129a54a5ebbe96)
(Mjt: trivial context fix around AA64MMFR4_EL1 and AA64PFR2_EL1 definitions)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: ac167f2f9d59ee85465ab643298aa99e88a5d13c
      
https://github.com/qemu/qemu/commit/ac167f2f9d59ee85465ab643298aa99e88a5d13c
  Author: Peter Maydell <[email protected]>
  Date:   2026-01-18 (Sun, 18 Jan 2026)

  Changed paths:
    M target/arm/helper.c

  Log Message:
  -----------
  target/arm: Correctly trap HCR.TID1 registers in v7A

In v7A HCR.TID1 is defined to trap for TCMTR, TLBTR, REVIDR and AIDR.
We incorrectly use an accessfn for REVIDR and AIDR that only traps on
v8A cores.  Fix this by collapsing access_aa64_tid1() and
access_aa32_tid1() together and never doing a check for v8 vs v7.

The accessfn is also used for SMIDR_EL1, which is fine as this
register is AArch64 only.

Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit b67a35622f9a816544ec094132d8af0debfac7f2)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 56943614f21b2a82827ebf8df0152f5b65f29f1a
      
https://github.com/qemu/qemu/commit/56943614f21b2a82827ebf8df0152f5b65f29f1a
  Author: Philippe Mathieu-Daudé <[email protected]>
  Date:   2026-01-18 (Sun, 18 Jan 2026)

  Changed paths:
    M target/i386/nvmm/nvmm-all.c

  Log Message:
  -----------
  accel/nvmm: Fix 'cpu' typo in nvmm_init_vcpu()

Fix typo to avoid the following build failure:

  target/i386/nvmm/nvmm-all.c: In function 'nvmm_init_vcpu':
  target/i386/nvmm/nvmm-all.c:988:9: error: 'AccelCPUState' has no member named 
'vcpu_dirty'
    988 |     qcpu->vcpu_dirty = true;
        |         ^~

Cc: [email protected]
Reported-by: Thomas Huth <[email protected]>
Fixes: 2098164a6be ("accel/nvmm: Replace @dirty field by generic 
CPUState::vcpu_dirty field")
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Tested-by: Thomas Huth <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Tested-by: Pierrick Bouvier <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 7be4256281f430f726366c92ffdea0b72651de8a)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 2b873575d3be41a4fd6a90335cdb55e1b5f21aea
      
https://github.com/qemu/qemu/commit/2b873575d3be41a4fd6a90335cdb55e1b5f21aea
  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: 9945f966c61109e5f41883e7bfc891a82e97cfd2
      
https://github.com/qemu/qemu/commit/9945f966c61109e5f41883e7bfc891a82e97cfd2
  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: 48c61c2efbdcfd4ee0cf4fa51c13a3169ded37e0
      
https://github.com/qemu/qemu/commit/48c61c2efbdcfd4ee0cf4fa51c13a3169ded37e0
  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: aef41c4cd136a0efa317a5c9d2c4b3585949767c
      
https://github.com/qemu/qemu/commit/aef41c4cd136a0efa317a5c9d2c4b3585949767c
  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: 374bf44eccbe776e13fdf47b91f0868a8ef7d5df
      
https://github.com/qemu/qemu/commit/374bf44eccbe776e13fdf47b91f0868a8ef7d5df
  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: 3b0b8f01932c1517cd57906df3dc3ce3c056a6a3
      
https://github.com/qemu/qemu/commit/3b0b8f01932c1517cd57906df3dc3ce3c056a6a3
  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: 374bf44ec ("Fix __i386__ test for TARGET_HAS_STAT_TIME_T_EXT" in 10.1.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: 000dc91c0ef12567bd336491d565825e6da0d7d8
      
https://github.com/qemu/qemu/commit/000dc91c0ef12567bd336491d565825e6da0d7d8
  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: b4fdd670216fe2ea0c32195532d1625973ff2bd8
      
https://github.com/qemu/qemu/commit/b4fdd670216fe2ea0c32195532d1625973ff2bd8
  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: d56a4717016671af2c7137811d05764f8520c645
      
https://github.com/qemu/qemu/commit/d56a4717016671af2c7137811d05764f8520c645
  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: 64c435a41264dd7499c4b6b95b3f936c6dd26d51
      
https://github.com/qemu/qemu/commit/64c435a41264dd7499c4b6b95b3f936c6dd26d51
  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: ed70cb9917a1d8c00594406976c4c601e5f3b994
      
https://github.com/qemu/qemu/commit/ed70cb9917a1d8c00594406976c4c601e5f3b994
  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: b2ae0dfc9f82e05d379fea50452d9f564bc60141
      
https://github.com/qemu/qemu/commit/b2ae0dfc9f82e05d379fea50452d9f564bc60141
  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: 790d4660c72d71241f07db5bcd02b7b05589b75f
      
https://github.com/qemu/qemu/commit/790d4660c72d71241f07db5bcd02b7b05589b75f
  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: ad62f095c3c23732a08d4738904885cfe9c01424
      
https://github.com/qemu/qemu/commit/ad62f095c3c23732a08d4738904885cfe9c01424
  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: c35df6aa24b7e59fb3efee9dac4737788d6512c2
      
https://github.com/qemu/qemu/commit/c35df6aa24b7e59fb3efee9dac4737788d6512c2
  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: 356f4bf499d8a72baa21ec93b10bb10d363fcd36
      
https://github.com/qemu/qemu/commit/356f4bf499d8a72baa21ec93b10bb10d363fcd36
  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: 6e4728570703214ca4b98f78502d89a09d90bd81
      
https://github.com/qemu/qemu/commit/6e4728570703214ca4b98f78502d89a09d90bd81
  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: 5594fe141540ad1288a448206bfc67abb74d63da
      
https://github.com/qemu/qemu/commit/5594fe141540ad1288a448206bfc67abb74d63da
  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: 43539aeaf67c3eb45c221148861a4ed3659d44bc
      
https://github.com/qemu/qemu/commit/43539aeaf67c3eb45c221148861a4ed3659d44bc
  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: e4ccceaa34feed19ebeebc3c5b1487832815f6b3
      
https://github.com/qemu/qemu/commit/e4ccceaa34feed19ebeebc3c5b1487832815f6b3
  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: 4093551fdbd40cb767319f8371b355d3a6717557
      
https://github.com/qemu/qemu/commit/4093551fdbd40cb767319f8371b355d3a6717557
  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: 4a08de6d46fc34f13bbee7aa2f836f53eca596fa
      
https://github.com/qemu/qemu/commit/4a08de6d46fc34f13bbee7aa2f836f53eca596fa
  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: de302beabe7221ed8687948cfd3759f29101067b
      
https://github.com/qemu/qemu/commit/de302beabe7221ed8687948cfd3759f29101067b
  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: 46853d7d3ac6cde4f3e3857205d3ebc277221c76
      
https://github.com/qemu/qemu/commit/46853d7d3ac6cde4f3e3857205d3ebc277221c76
  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: d7500e12593a618612f365ad0f66440edab760cd
      
https://github.com/qemu/qemu/commit/d7500e12593a618612f365ad0f66440edab760cd
  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: 4bad6c7c9e63d17f41c3c173498e7f1a0f94c02f
      
https://github.com/qemu/qemu/commit/4bad6c7c9e63d17f41c3c173498e7f1a0f94c02f
  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: 2cf4cbc0118c84fa87a562edb6af7df9baef6198
      
https://github.com/qemu/qemu/commit/2cf4cbc0118c84fa87a562edb6af7df9baef6198
  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: 1b107b64b8372a0385c686cb7132676a9d899cbc
      
https://github.com/qemu/qemu/commit/1b107b64b8372a0385c686cb7132676a9d899cbc
  Author: Jamin Lin <[email protected]>
  Date:   2026-02-06 (Fri, 06 Feb 2026)

  Changed paths:
    M hw/arm/aspeed_ast27x0.c

  Log Message:
  -----------
  hw/arm/aspeed_ast27x0: Fix EHCI3/4 IRQ routing to GIC

EHCI3 and EHCI4 were missing entries in aspeed_soc_ast2700a1_irqmap,
so their source IRQs were never routed through the INTC OR-gates.

As a result, EHCI3/4 interrupts were not propagated to the GIC,
causing incorrect interrupt behavior for these controllers.

Add EHCI3 and EHCI4 to the IRQ map and route them to the same INTC
group as other shared peripherals, ensuring their interrupts are
properly connected to the GIC.

Signed-off-by: Jamin Lin <[email protected]>
Fixes: ba27ba302a264117c8b8427f944ced1bed17c438 ("hw/arm: ast27x0: Wire up EHCI 
controllers")
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 7d64f04863ed23f6a142fb8f47c5a470c0e081f9)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 6af4aff2053ec98bfd54ace5973ff70f02c21a3e
      
https://github.com/qemu/qemu/commit/6af4aff2053ec98bfd54ace5973ff70f02c21a3e
  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: ea4be299f0184cfab7dee146fd1aa3c6a49947ae
      
https://github.com/qemu/qemu/commit/ea4be299f0184cfab7dee146fd1aa3c6a49947ae
  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: 5e40faac9c83766b9833a9e8f2c437b0963f9882
      
https://github.com/qemu/qemu/commit/5e40faac9c83766b9833a9e8f2c437b0963f9882
  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)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 88d40c05782e0d7959048568f908b946418b407e
      
https://github.com/qemu/qemu/commit/88d40c05782e0d7959048568f908b946418b407e
  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: dbb6465a08b665577ab849c462b553f98284da51
      
https://github.com/qemu/qemu/commit/dbb6465a08b665577ab849c462b553f98284da51
  Author: Kevin Wolf <[email protected]>
  Date:   2026-02-06 (Fri, 06 Feb 2026)

  Changed paths:
    M hw/virtio/virtio-pci.c

  Log Message:
  -----------
  virtio: Fix crash when sriov-pf is set for non-PCI-Express device

Setting the sriov-pf property on devices that aren't PCI Express causes
an assertion failure:

    $ qemu-system-x86_64 \
        -blockdev null-co,node-name=null \
        -blockdev null-co,node-name=null2 \
        -device virtio-blk,drive=null,id=pf \
        -device virtio-blk,sriov-pf=pf,drive=null2
    qemu-system-x86_64: ../hw/pci/pcie.c:1062: void 
pcie_add_capability(PCIDevice *, uint16_t, uint8_t, uint16_t, uint16_t): 
Assertion `offset >= PCI_CONFIG_SPACE_SIZE' failed.

This is because proxy->last_pcie_cap_offset is only initialised to a
non-zero value in virtio_pci_realize() if it's a PCI Express device, and
then virtio_pci_device_plugged() still tries to use it.

To fix this, just skip the SR-IOV code for !pci_is_express(). Then the
next thing pci_qdev_realize() does is call pcie_sriov_register_device(),
which returns the appropriate error.

Cc: [email protected]
Fixes: d0c280d3fac6 ('pcie_sriov: Make a PCI device with user-created VF 
ARI-capable')
Signed-off-by: Kevin Wolf <[email protected]>
Reviewed-by: Stefan Hajnoczi <[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 623db856476806124e9ae45fbc39e75012261570)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 0901e4379fb5a2a39688386c7983d98f94d01c27
      
https://github.com/qemu/qemu/commit/0901e4379fb5a2a39688386c7983d98f94d01c27
  Author: Kevin Wolf <[email protected]>
  Date:   2026-02-06 (Fri, 06 Feb 2026)

  Changed paths:
    M hw/pci/pcie_sriov.c

  Log Message:
  -----------
  pcie_sriov: Fix PCI_SRIOV_* accesses in pcie_sriov_pf_exit()

PCI_SRIOV_* are offsets into the SR-IOV capability, not into the PCI
config space. pcie_sriov_pf_exit() erroneously takes them as the latter,
which makes it read PCI_HEADER_TYPE and PCI_BIST when it tries to read
PCI_SRIOV_TOTAL_VF.

In many cases we're lucky enough that the PCI config space will be 0
there, so we just skip the whole for loop, but this isn't guaranteed.
For example, setting the multifunction bit on the PF and then doing a
'device_del' on it will get a larger number and cause a segfault.

Fix this and access the real PCI_SRIOV_* fields in the capability.

Cc: [email protected]
Fixes: 19e55471d4e8 ('pcie_sriov: Allow user to create SR-IOV device')
Signed-off-by: Kevin Wolf <[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 f73e5ed9bc4cfacf041323a6b40a85e6b6459b75)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 259da6b08f7e4baf580e9d363fb72dfe2292784d
      
https://github.com/qemu/qemu/commit/259da6b08f7e4baf580e9d363fb72dfe2292784d
  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: 1ea1baa5c89ec3158b198769e96128f9670bf981
      
https://github.com/qemu/qemu/commit/1ea1baa5c89ec3158b198769e96128f9670bf981
  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: 95aac3231317b7d22af9eae803cd8b3977de8f6c
      
https://github.com/qemu/qemu/commit/95aac3231317b7d22af9eae803cd8b3977de8f6c
  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: da9b1cd37f66bf929bf65ec7a0982c5c6086ff71
      
https://github.com/qemu/qemu/commit/da9b1cd37f66bf929bf65ec7a0982c5c6086ff71
  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: 21500ffad22101eab4e99058c371cddc55219d61
      
https://github.com/qemu/qemu/commit/21500ffad22101eab4e99058c371cddc55219d61
  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: fc186fdb6a87f4f6e6394948c6af14452c866af4
      
https://github.com/qemu/qemu/commit/fc186fdb6a87f4f6e6394948c6af14452c866af4
  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: 36c85f19e16238ec82c9034460c6cc714e9d1a8c
      
https://github.com/qemu/qemu/commit/36c85f19e16238ec82c9034460c6cc714e9d1a8c
  Author: Jonathan Cameron <[email protected]>
  Date:   2026-02-06 (Fri, 06 Feb 2026)

  Changed paths:
    M hw/cxl/cxl-mailbox-utils.c

  Log Message:
  -----------
  hw/cxl: Check for overflow on santize media as both base and offset 64bit.

The both the size and base of a media sanitize operation are both provided
by the VM, an overflow is possible which may result in checks on valid
range passing when they should not.  Close that by checking for overflow
on the addition.

Fixes: 40ab4ed10775 ("hw/cxl/cxl-mailbox-utils: Media operations Sanitize and 
Write Zeros commands CXL r3.2(8.2.10.9.5.3)")
Closes: 
https://lore.kernel.org/qemu-devel/cafeaca8rqop+ju0fuxn+0t57nbg+bep80z45f6py0ci2fz_...@mail.gmail.com/
Reported-by: Peter Maydell <[email protected]>
Signed-off-by: Jonathan Cameron <[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 87f8e5a71d061964c9bfa4d6e02db47f54dd61f7)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 25d3fa63679a2a4dd53adf98e83e3551826545d6
      
https://github.com/qemu/qemu/commit/25d3fa63679a2a4dd53adf98e83e3551826545d6
  Author: Jonathan Cameron <[email protected]>
  Date:   2026-02-06 (Fri, 06 Feb 2026)

  Changed paths:
    M hw/cxl/cxl-mailbox-utils.c

  Log Message:
  -----------
  hw/cxl: Take into account how many media operations are requested for param 
check

Whilst the spec doesn't speak to it directly my assumption is that
a request for more operations than exist should result in an invalid
input error return.

Fixes: 77a8e9fe0ecb ("hw/cxl/cxl-mailbox-utils: Add support for Media 
operations discovery commands cxl r3.2 (8.2.10.9.5.3)")
Closes: 
https://lore.kernel.org/qemu-devel/cafeaca-p5wzknxk7wnvq_3pazee-muod1def-0o-fspck4d...@mail.gmail.com/
Reported-by: Peter Maydell <[email protected]>
Signed-off-by: Jonathan Cameron <[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 25465c0e1fd74d2118dfec03912f2595eeb497d7)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 2a4209ee9451809b3a679da9fc317248b2c932b9
      
https://github.com/qemu/qemu/commit/2a4209ee9451809b3a679da9fc317248b2c932b9
  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: 5323c1b9e6f3ea45d4ca42fbcd8d03669225c95a
      
https://github.com/qemu/qemu/commit/5323c1b9e6f3ea45d4ca42fbcd8d03669225c95a
  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: 384ba786abb18469038f1b7adfe37da6949494c3
      
https://github.com/qemu/qemu/commit/384ba786abb18469038f1b7adfe37da6949494c3
  Author: Michael Tokarev <[email protected]>
  Date:   2026-02-12 (Thu, 12 Feb 2026)

  Changed paths:
    M VERSION

  Log Message:
  -----------
  Update version for 10.1.4 release

Signed-off-by: Michael Tokarev <[email protected]>


Compare: https://github.com/qemu/qemu/compare/93be9e6bd43e...384ba786abb1

To unsubscribe from these emails, change your notification settings at 
https://github.com/qemu/qemu/settings/notifications

Reply via email to