Branch: refs/heads/staging-10.0
Home: https://github.com/qemu/qemu
Commit: 47e775f0ea96d85b486e39150ffd0cdcfea1b6d3
https://github.com/qemu/qemu/commit/47e775f0ea96d85b486e39150ffd0cdcfea1b6d3
Author: Peter Maydell <[email protected]>
Date: 2025-10-21 (Tue, 21 Oct 2025)
Changed paths:
M tests/tcg/multiarch/linux/linux-test.c
Log Message:
-----------
tests/tcg/multiarch/linux/linux-test: Don't try to test atime update
The linux-test test includes an attempt to check the utime and stat
syscalls by setting the atime and mtime of a file to specific values,
and then calling stat() to check that the values read back correctly.
Unfortunately this is flaky, as it will fail if some other process
(for instance a virus scanner, backup program, etc) gets in and reads
the file between the utime() and stat() call, resulting in a host
syscall sequence like this:
utimensat(AT_FDCWD, "file2",
[{tv_sec=1001, tv_nsec=0} /* 1970-01-01T01:16:41+0100 */,
{tv_sec=1000, tv_nsec=0} /* 1970-01-01T01:16:40+0100 */], 0) = 0
# successfully set atime to 1001 and mtime to 1000
statx(AT_FDCWD, "file2", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT,
STATX_BASIC_STATS,
{stx_mask=STATX_BASIC_STATS|STATX_MNT_ID,
stx_blksize=4096, stx_attributes=0, stx_nlink=1, stx_uid=32808,
stx_gid=32808, stx_mode=S_IFREG|0600, stx_ino=21659016,
stx_size=100, stx_blocks=8,
stx_attributes_mask=STATX_ATTR_COMPRESSED|STATX_ATTR_IMMUTABLE|
STATX_ATTR_APPEND|STATX_ATTR_NODUMP|STATX_ATTR_ENCRYPTED|
STATX_ATTR_AUTOMOUNT|STATX_ATTR_MOUNT_ROOT|STATX_ATTR_VERITY|
STATX_ATTR_DAX,
stx_atime={tv_sec=1760091862, tv_nsec=63509009} /*
2025-10-10T11:24:22.063509009+0100 */,
stx_ctime={tv_sec=1760091862, tv_nsec=63509009} /*
2025-10-10T11:24:22.063509009+0100 */,
stx_mtime={tv_sec=1000, tv_nsec=0} /* 1970-01-01T01:16:40+0100 */,
stx_rdev_major=0, stx_rdev_minor=0, stx_dev_major=252,
stx_dev_minor=0, stx_mnt_id=0x1f}) = 0
# but when we statx the file, we get back an mtime of 1000
# but an atime corresponding to when the other process read it
and which will cause the test program to fail with the error
message "stat time".
In theory we could defend against this by e.g. operating on files in
a dummy loopback mount filesystem which we mounted as 'noatime', but
this isn't worth the hassle. Just drop the check on atime.
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
(cherry picked from commit 77dc9d662f80b9f4eb450df27f60a0a9b3c97785)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7509d79359cc50843b0adccd49ec9f3480097c3f
https://github.com/qemu/qemu/commit/7509d79359cc50843b0adccd49ec9f3480097c3f
Author: Dongwon Kim <[email protected]>
Date: 2025-10-21 (Tue, 21 Oct 2025)
Changed paths:
M ui/gtk-gl-area.c
Log Message:
-----------
ui/gtk-gl-area: Remove extra draw call in refresh
This partially reverts commit 77bf310084dad38b3a2badf01766c659056f1cf2
which causes some guest display corruption when gtk-gl-area
is used for GTK rendering (e.g. Wayland Compositor) possibly due to
simulataneous accesses on the guest frame buffer by host compositor
and the guest.
Fixes: 77bf310084 ("ui/gtk: Draw guest frame at refresh cycle")
Reported-by: Dmitry Osipenko <[email protected]>
Reported-by: Alex Bennée <[email protected]>
Tested-by: Alex Bennée <[email protected]>
Tested-by: Dmitry Osipenko <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Dmitry Osipenko <[email protected]>
Cc: Marc-André Lureau <[email protected]>
Cc: Vivek Kasireddy <[email protected]>
Signed-off-by: Dongwon Kim <[email protected]>
Message-Id: <[email protected]>
Message-ID: <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
(cherry picked from commit 0c6d6d79a5cbd538c6c0798b1068f37bfbbf9693)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d5f47a089ae42957e40ff8197bddaa2770966926
https://github.com/qemu/qemu/commit/d5f47a089ae42957e40ff8197bddaa2770966926
Author: Thomas Huth <[email protected]>
Date: 2025-10-22 (Wed, 22 Oct 2025)
Changed paths:
M hw/ppc/e500.c
Log Message:
-----------
hw/ppc/e500: Check for compatible CPU type instead of aborting ungracefully
When using the ppce500 machine with an embedded CPU type that has
the right MMU model, but is not part of the e500 CPU family, QEMU
currently aborts ungracefully:
$ ./qemu-system-ppc -machine ppce500 -cpu e200z5 -nographic
qemu-system-ppc: ../qemu/hw/core/gpio.c:108: qdev_get_gpio_in_named:
Assertion `n >= 0 && n < gpio_list->num_in' failed.
Aborted (core dumped)
The ppce500 machine expects a CPU with certain GPIO interrupt pins,
so let's replace the coarse check for the MMU_BOOKE206 model with
a more precise check that only allows CPUs from the e500 family.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3162
Signed-off-by: Thomas Huth <[email protected]>
Acked-by: Bernhard Beschow <[email protected]>
Reviewed-by: Harsh Prateek Bora <[email protected]>
Reviewed-by: BALATON Zoltan <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 270b28681e369082dc17f58eae2871b75d3e8e6c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3905b74add73df99883ecc616769ee948ae13e9a
https://github.com/qemu/qemu/commit/3905b74add73df99883ecc616769ee948ae13e9a
Author: Peter Maydell <[email protected]>
Date: 2025-10-24 (Fri, 24 Oct 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Fix reads of CNTFRQ_EL0 in linux-user mode
In commit bd8e9ddf6f6 ("target/arm: Refactor default generic timer
frequency handling") we changed how we initialized the generic timer
frequency as reported in the CNTFRQ_EL0 register. As part of that,
we chanegd the linux-user version of the CNTFRQ_EL0 sysreg from
having a constant value set at compile time through the .resetvalue
field to having a reset value which we compute in a .resetfn.
This accidentally broke the reading of CNTFRQ_EL0 in linux-user mode,
because the cpreg is marked as ARM_CP_CONST, which means we translate
it as a read of the compile-time constant value in the .resetvalue
field. This is now zero, so userspace sees a 0 frequency value.
Fix the bug by dropping the ARM_CP_CONST marking. This will cause us
to translate the read as a load of the value from the CPU state
struct cp15.c14_cntfrq field, which is where the real frequency value
now lives.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3159
Fixes: bd8e9ddf6f6 ("target/arm: Refactor default generic timer frequency
handling")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 3f462d79a080060e54e39d31ce10fdf1a20317ef)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3d106818a704e9bf322c63f8d9c746c6fff1adb9
https://github.com/qemu/qemu/commit/3d106818a704e9bf322c63f8d9c746c6fff1adb9
Author: Zejun Zhao <[email protected]>
Date: 2025-10-24 (Fri, 24 Oct 2025)
Changed paths:
M hw/riscv/sifive_u.c
Log Message:
-----------
hw/riscv: Correct mmu-type property of sifive_u harts in device tree
Correct mmu-type property of sifive_u harts from Sv48 to Sv39 in 64-bit
mode since it's the only supported SATP mode.
Signed-off-by: Zejun Zhao <[email protected]>
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
Cc: [email protected]
(cherry picked from commit e41139eaad1d6ea7c52b8ebb5def2dcb84ff57e1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2d6d739ea60b0143df8724fbd0373d429cb01978
https://github.com/qemu/qemu/commit/2d6d739ea60b0143df8724fbd0373d429cb01978
Author: Jialong Yang <[email protected]>
Date: 2025-10-24 (Fri, 24 Oct 2025)
Changed paths:
M hw/intc/riscv_aplic.c
Log Message:
-----------
aplic: fix mask for smsiaddrcfgh
4.5.4. Supervisor MSI address configuration (smsiaddrcfg and
smsiaddrcfgh)
smsiaddrcfgh:
bits 22:20 LHXS(WARL)
bits 11:0 High Base PPN(WARL)
Signed-off-by: Jialong Yang <[email protected]>
Acked-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
Cc: [email protected]
(cherry picked from commit 5e3e066e4ac894aff3e8dd3a072bca9c1986b2ff)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1a17257fa626651dafc95dfd9f8f67ec0c54d4c4
https://github.com/qemu/qemu/commit/1a17257fa626651dafc95dfd9f8f67ec0c54d4c4
Author: Daniel Henrique Barboza <[email protected]>
Date: 2025-10-24 (Fri, 24 Oct 2025)
Changed paths:
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: add senvcfg CSR
We're missing the senvcfg CSRs which is already present in the
KVM UAPI.
Reported-by: Andrew Jones <[email protected]>
Signed-off-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Acked-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 86b8c3821496898cd3bd8eaa1bac71f5c784a2db)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1513fcb75c28967d406d94630a17ca7aeaeddae1
https://github.com/qemu/qemu/commit/1513fcb75c28967d406d94630a17ca7aeaeddae1
Author: Daniel Henrique Barboza <[email protected]>
Date: 2025-10-26 (Sun, 26 Oct 2025)
Changed paths:
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: read/write KVM regs via env size
We're going to add support for scounteren in the next patch. KVM defines
as a target_ulong CSR, while QEMU defines env->scounteren as a 32 bit
field. This will cause the current code to read/write a 64 bit CSR in a
32 bit field when running in a 64 bit CPU.
To prevent that, change the current logic to honor the size of the QEMU
storage instead of the KVM CSR reg.
Suggested-by: Andrew Jones <[email protected]>
Signed-off-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 775ac57e0a54b9127bd2ad005675772870cd1932)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 30f152de6ec6aa70e367e08c420837eb4d03c44f
https://github.com/qemu/qemu/commit/30f152de6ec6aa70e367e08c420837eb4d03c44f
Author: Daniel Henrique Barboza <[email protected]>
Date: 2025-10-26 (Sun, 26 Oct 2025)
Changed paths:
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: add scounteren CSR
Add support for the scounteren KVM CSR. Note that env->scounteren is a
32 bit and all KVM CSRs are target_ulong, so scounteren will be capped
to 32 bits read/writes.
Reported-by: Andrew Jones <[email protected]>
Signed-off-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 8ab99a05f34bab3f9fae49299ee407ead78f0470)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 44c571898c76ad55142ee9b09faba6a51bd256a0
https://github.com/qemu/qemu/commit/44c571898c76ad55142ee9b09faba6a51bd256a0
Author: Daniel Henrique Barboza <[email protected]>
Date: 2025-10-26 (Sun, 26 Oct 2025)
Changed paths:
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: fix env->priv setting in reset_regs_csr()
This patch was originally made by Gitlab user Bo Gan (@ganboing) 4
months ago in the context of issue [1]. I asked the author to send a
patch to the mailing list ~3 months ago and got no reply. I'm sending
the patch myself because we already missed 10.1 without this fix.
I'll also just post verbatim Bo Gan comment in the commit msg:
"In RISCV Linux with KVM enabled, gdbstub is broken. The
get_physical_address isn't able to page-walk correctly and resolve the
physical page. This is due to that the vcpu is being treated as starting
in M mode even if KVM enabled. However, with KVM, the vcpu is actually
started in S mode. The mmu_idx will give 3 (M), instead of 1 (S),
resulting in Guest PA == VA (wrong)!"
Set env->priv to PRV_S in kvm_riscv_reset_regs_csr() since the VCPU is
always started in S-mode for KVM.
[1] https://gitlab.com/qemu-project/qemu/-/issues/2991
Cc: [email protected]
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2991
Originally-by: Bo Gan (@ganboing in Gitlab)
Signed-off-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 2a21cbee47a124edf43fc9ee156d7093e2f957fd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b1317a238487db5dfbf1523b171ab3abb9f464ca
https://github.com/qemu/qemu/commit/b1317a238487db5dfbf1523b171ab3abb9f464ca
Author: Daniel Henrique Barboza <[email protected]>
Date: 2025-10-26 (Sun, 26 Oct 2025)
Changed paths:
M target/riscv/cpu_helper.c
Log Message:
-----------
target/riscv: fix riscv_cpu_sirq_pending() mask
We're filtering out (MIP_VSSIP | MIP_VSTIP | MIP_VSEIP) from S-mode
pending interrupts without apparent reason. There's no special treatment
for these ints as far as the spec goes, and this filtering is causing
read_stopi() to miss those VS interrupts [1].
We shouldn't return delegated VS interrupts in S-mode though, so change
the current mask with "~env->hideleg". Note that this is the same
handling we're doing in riscv_cpu_mirq_pending() and env->mideleg.
[1] https://gitlab.com/qemu-project/qemu/-/issues/2820
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2820
Signed-off-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
Cc: [email protected]
(cherry picked from commit 06e01941ffca3c246a9770f477e43118793fde59)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a73800ef9b425d58dce47d9c83f95c192d82cf7c
https://github.com/qemu/qemu/commit/a73800ef9b425d58dce47d9c83f95c192d82cf7c
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-10-26 (Sun, 26 Oct 2025)
Changed paths:
M io/channel-tls.c
Log Message:
-----------
io: release active GSource in TLS channel finalizer
While code is supposed to call qio_channel_close() before releasing the
last reference on an QIOChannel, this is not guaranteed. QIOChannelFile
and QIOChannelSocket both cleanup resources in their finalizer if the
close operation was missed.
This ensures the TLS channel will do the same failsafe cleanup.
Reviewed-by: Eric Blake <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
(cherry picked from commit 2c147611cf568eb1cd7dc8bf4479b272bad3b9d6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 997ac8b076cc20f7cbb9a2d504ed486f453a00c4
https://github.com/qemu/qemu/commit/997ac8b076cc20f7cbb9a2d504ed486f453a00c4
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-10-26 (Sun, 26 Oct 2025)
Changed paths:
M io/channel-websock.c
Log Message:
-----------
io: move websock resource release to close method
The QIOChannelWebsock object releases all its resources in the
finalize callback. This is later than desired, as callers expect
to be able to call qio_channel_close() to fully close a channel
and release resources related to I/O.
The logic in the finalize method is at most a failsafe to handle
cases where a consumer forgets to call qio_channel_close.
This adds equivalent logic to the close method to release the
resources, using g_clear_handle_id/g_clear_pointer to be robust
against repeated invocations. The finalize method is tweaked
so that the GSource is removed before releasing the underlying
channel.
Reviewed-by: Eric Blake <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
(cherry picked from commit 322c3c4f3abee616a18b3bfe563ec29dd67eae63)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e21ef56b4b9213f8a86c5601b385b48f39339aba
https://github.com/qemu/qemu/commit/e21ef56b4b9213f8a86c5601b385b48f39339aba
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-10-26 (Sun, 26 Oct 2025)
Changed paths:
M include/io/channel-websock.h
M io/channel-websock.c
Log Message:
-----------
io: fix use after free in websocket handshake code
If the QIOChannelWebsock object is freed while it is waiting to
complete a handshake, a GSource is leaked. This can lead to the
callback firing later on and triggering a use-after-free in the
use of the channel. This was observed in the VNC server with the
following trace from valgrind:
==2523108== Invalid read of size 4
==2523108== at 0x4054A24: vnc_disconnect_start (vnc.c:1296)
==2523108== by 0x4054A24: vnc_client_error (vnc.c:1392)
==2523108== by 0x4068A09: vncws_handshake_done (vnc-ws.c:105)
==2523108== by 0x44863B4: qio_task_complete (task.c:197)
==2523108== by 0x448343D: qio_channel_websock_handshake_io
(channel-websock.c:588)
==2523108== by 0x6EDB862: UnknownInlinedFun (gmain.c:3398)
==2523108== by 0x6EDB862: g_main_context_dispatch_unlocked.lto_priv.0
(gmain.c:4249)
==2523108== by 0x6EDBAE4: g_main_context_dispatch (gmain.c:4237)
==2523108== by 0x45EC79F: glib_pollfds_poll (main-loop.c:287)
==2523108== by 0x45EC79F: os_host_main_loop_wait (main-loop.c:310)
==2523108== by 0x45EC79F: main_loop_wait (main-loop.c:589)
==2523108== by 0x423A56D: qemu_main_loop (runstate.c:835)
==2523108== by 0x454F300: qemu_default_main (main.c:37)
==2523108== by 0x73D6574: (below main) (libc_start_call_main.h:58)
==2523108== Address 0x57a6e0dc is 28 bytes inside a block of size 103,608
free'd
==2523108== at 0x5F2FE43: free (vg_replace_malloc.c:989)
==2523108== by 0x6EDC444: g_free (gmem.c:208)
==2523108== by 0x4053F23: vnc_update_client (vnc.c:1153)
==2523108== by 0x4053F23: vnc_refresh (vnc.c:3225)
==2523108== by 0x4042881: dpy_refresh (console.c:880)
==2523108== by 0x4042881: gui_update (console.c:90)
==2523108== by 0x45EFA1B: timerlist_run_timers.part.0 (qemu-timer.c:562)
==2523108== by 0x45EFC8F: timerlist_run_timers (qemu-timer.c:495)
==2523108== by 0x45EFC8F: qemu_clock_run_timers (qemu-timer.c:576)
==2523108== by 0x45EFC8F: qemu_clock_run_all_timers (qemu-timer.c:663)
==2523108== by 0x45EC765: main_loop_wait (main-loop.c:600)
==2523108== by 0x423A56D: qemu_main_loop (runstate.c:835)
==2523108== by 0x454F300: qemu_default_main (main.c:37)
==2523108== by 0x73D6574: (below main) (libc_start_call_main.h:58)
==2523108== Block was alloc'd at
==2523108== at 0x5F343F3: calloc (vg_replace_malloc.c:1675)
==2523108== by 0x6EE2F81: g_malloc0 (gmem.c:133)
==2523108== by 0x4057DA3: vnc_connect (vnc.c:3245)
==2523108== by 0x448591B: qio_net_listener_channel_func (net-listener.c:54)
==2523108== by 0x6EDB862: UnknownInlinedFun (gmain.c:3398)
==2523108== by 0x6EDB862: g_main_context_dispatch_unlocked.lto_priv.0
(gmain.c:4249)
==2523108== by 0x6EDBAE4: g_main_context_dispatch (gmain.c:4237)
==2523108== by 0x45EC79F: glib_pollfds_poll (main-loop.c:287)
==2523108== by 0x45EC79F: os_host_main_loop_wait (main-loop.c:310)
==2523108== by 0x45EC79F: main_loop_wait (main-loop.c:589)
==2523108== by 0x423A56D: qemu_main_loop (runstate.c:835)
==2523108== by 0x454F300: qemu_default_main (main.c:37)
==2523108== by 0x73D6574: (below main) (libc_start_call_main.h:58)
==2523108==
The above can be reproduced by launching QEMU with
$ qemu-system-x86_64 -vnc localhost:0,websocket=5700
and then repeatedly running:
for i in {1..100}; do
(echo -n "GET / HTTP/1.1" && sleep 0.05) | nc -w 1 localhost 5700 &
done
CVE-2025-11234
Reported-by: Grant Millar | Cylo <[email protected]>
Reviewed-by: Eric Blake <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
(cherry picked from commit b7a1f2ca45c7865b9e98e02ae605a65fc9458ae9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b7fcf2670f3ba97584a47928196b3843d89cd933
https://github.com/qemu/qemu/commit/b7fcf2670f3ba97584a47928196b3843d89cd933
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-10-27 (Mon, 27 Oct 2025)
Changed paths:
M crypto/tlscredsx509.c
M docs/system/tls.rst
M tests/unit/crypto-tls-x509-helpers.h
M tests/unit/test-crypto-tlscredsx509.c
M tests/unit/test-crypto-tlssession.c
M tests/unit/test-io-channel-tls.c
Log Message:
-----------
crypto: stop requiring "key encipherment" usage in x509 certs
This usage flag was deprecated by RFC8813, such that it is
forbidden to be present for certs using ECDSA/ECDH algorithms,
and in TLS 1.3 is conceptually obsolete.
As such many valid certs will no longer have this key usage
flag set, and QEMU should not be rejecting them, as this
prevents use of otherwise valid & desirable algorithms.
Reviewed-by: Eric Blake <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
(cherry picked from commit 3995fc238e0599e0417ba958ffc5c7a609e82a7f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3be85c436ccb62ba49ab9e0ecad0a098fd774e4f
https://github.com/qemu/qemu/commit/3be85c436ccb62ba49ab9e0ecad0a098fd774e4f
Author: Fiona Ebner <[email protected]>
Date: 2025-10-28 (Tue, 28 Oct 2025)
Changed paths:
M hw/scsi/virtio-scsi.c
Log Message:
-----------
hw/scsi: avoid deadlock upon TMF request cancelling with VirtIO
When scsi_req_dequeue() is reached via
scsi_req_cancel_async()
virtio_scsi_tmf_cancel_req()
virtio_scsi_do_tmf_aio_context(),
there is a deadlock when trying to acquire the SCSI device's requests
lock, because it was already acquired in
virtio_scsi_do_tmf_aio_context().
In particular, the issue happens with a FreeBSD guest (13, 14, 15,
maybe more), when it cancels SCSI requests, because of timeout.
This is a regression caused by commit da6eebb33b ("virtio-scsi:
perform TMFs in appropriate AioContexts") and the introduction of the
requests_lock earlier.
To fix the issue, only cancel the requests after releasing the
requests_lock. For this, the SCSI device's requests are iterated while
holding the requests_lock and the requests to be cancelled are
collected in a list. Then, the collected requests are cancelled
one by one while not holding the requests_lock. This is safe, because
only requests from the current AioContext are collected and acted
upon.
Originally reported by Proxmox VE users:
https://bugzilla.proxmox.com/show_bug.cgi?id=6810
https://forum.proxmox.com/threads/173914/
Fixes: da6eebb33b ("virtio-scsi: perform TMFs in appropriate AioContexts")
Suggested-by: Stefan Hajnoczi <[email protected]>
Signed-off-by: Fiona Ebner <[email protected]>
Message-id: [email protected]
[Changed g_list_append() to g_list_prepend() to avoid traversing the
list each time.
--Stefan]
Signed-off-by: Stefan Hajnoczi <[email protected]>
(cherry picked from commit 6910f04aa646f63a0257f77201ad8ea15992b816)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3560df2c1c1da75db0e57860a93546c4abd64885
https://github.com/qemu/qemu/commit/3560df2c1c1da75db0e57860a93546c4abd64885
Author: Peter Maydell <[email protected]>
Date: 2025-10-28 (Tue, 28 Oct 2025)
Changed paths:
M target/hppa/fpu_helper.c
Log Message:
-----------
target/hppa: Set FPCR exception flag bits for non-trapped exceptions
In commit ebd394948de4e8 ("target/hppa: Fix FPE exceptions") when
we added the code for setting up the registers correctly on trapping
FP exceptions, we accidentally broke the handling of the flag bits
for non-trapping exceptions.
In update_fr0_op() we incorrectly zero out the flag bits and the C
bit, so any fp operation would clear previously set flag bits. We
also stopped setting the flag bits when the fp operation raises
an exception and the trap is not enabled.
Adjust the code so that we set the Flag bits for every exception that
happened and where the trap is not enabled. (This is the correct
behaviour for the case where an instruction triggers two exceptions,
one of which traps and one of which does not; that can only happen
for inexact + underflow or inexact + overflow.)
Cc: [email protected]
Fixes: ebd394948de4e8 ("target/hppa: Fix FPE exceptions")
Fixes: 6966e0ba1d4a9e ("target/hppa: Fix FPE exceptions") in 10.0.1
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3158
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Helge Deller <[email protected]>
Tested-by: Helge Deller <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 1a8ffd6172f3d9ad8232189adb879a16ec416f89)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 91870d6764caa45a2e872ec7f924f6f27306f06d
https://github.com/qemu/qemu/commit/91870d6764caa45a2e872ec7f924f6f27306f06d
Author: Akihiko Odaki <[email protected]>
Date: 2025-10-28 (Tue, 28 Oct 2025)
Changed paths:
M hw/nvram/ds1225y.c
Log Message:
-----------
nw/nvram/ds1225y: Fix nvram MemoryRegion owner
s points to the MemoryRegion itself. dev points to DS1225Y, the real
owner.
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 575264e9083bd839ce6ce265fd606c44135799c3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4f8b6a983c02a574f0dac0fd27e583b333919494
https://github.com/qemu/qemu/commit/4f8b6a983c02a574f0dac0fd27e583b333919494
Author: Helge Deller <[email protected]>
Date: 2025-10-28 (Tue, 28 Oct 2025)
Changed paths:
M hw/hppa/machine.c
Log Message:
-----------
hw/hppa: Fix interrupt of LASI parallel port
Fix wrong assignment where the LASI parallel port was using the IRQ line of the
LASI LAN card.
Signed-off-by: Helge Deller <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit fb722e1dc2d84529ab9aa597315b7d5ca6e2a23e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b5d260d8ae835f2e321557e2e7cc8b670febf8d0
https://github.com/qemu/qemu/commit/b5d260d8ae835f2e321557e2e7cc8b670febf8d0
Author: Mark Cave-Ayland <[email protected]>
Date: 2025-10-29 (Wed, 29 Oct 2025)
Changed paths:
M hw/scsi/esp.c
Log Message:
-----------
esp.c: fix esp_cdb_ready() FIFO wraparound limit calculation
The original calculation in commit 3cc70889a3 ("esp.c: prevent cmdfifo overflow
in esp_cdb_ready()") subtracted cmdfifo_cdb_offset from fifo8_num_used() to
calculate the outstanding cmdfifo length, but this is incorrect because
fifo8_num_used() can also include wraparound data.
Instead calculate the maximum offset used by scsi_cdb_length() which is just
the first byte after cmdfifo_cdb_offset, and then peek the entire content
of the cmdfifo. The fifo8_peek_bufptr() result will then return the maximum
length of remaining data up to the end of the internal cmdfifo array, which
can then be used for the overflow check.
Signed-off-by: Mark Cave-Ayland <[email protected]>
Fixes: 3cc70889a3 ("esp.c: prevent cmdfifo overflow in esp_cdb_ready()")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3082
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Link:
https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 36ec1a829a07cd9a926b2f0ddfa5079c8dc9dae5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: dfc0263373d08fe228bf3bf2099631624ef24115
https://github.com/qemu/qemu/commit/dfc0263373d08fe228bf3bf2099631624ef24115
Author: Mark Cave-Ayland <[email protected]>
Date: 2025-10-29 (Wed, 29 Oct 2025)
Changed paths:
M tests/qtest/am53c974-test.c
Log Message:
-----------
qtest/am53c974-test: add additional test for cmdfifo overflow
Based upon the qtest reproducer posted to Gitlab issue #3082 at
https://gitlab.com/qemu-project/qemu/-/issues/3082.
Signed-off-by: Mark Cave-Ayland <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Link:
https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit e9d02b59316fcbc9650d747b06e2755374ab3b70)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 36ac2cafaab113c68e5ac59ab640bdf20d2d4a0f
https://github.com/qemu/qemu/commit/36ac2cafaab113c68e5ac59ab640bdf20d2d4a0f
Author: Bastian Blank <[email protected]>
Date: 2025-10-29 (Wed, 29 Oct 2025)
Changed paths:
M linux-user/ioctls.h
Log Message:
-----------
linux-user: Use correct type for FIBMAP and FIGETBSZ emulation
Both the FIBMAP and FIGETBSZ ioctl get "int *" (pointer to 32bit
integer) as argument, not "long *" as specified in qemu. Using the
correct type makes the emulation work in cross endian context.
Both ioctl does not seem to be documented. However the kernel
implementation has always used "int *".
Signed-off-by: Bastian Blank <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3185
Reviewed-by: Peter Maydell <[email protected]>
Reviewed-by: Helge Deller <[email protected]>
Reviwed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 7c7089321670fb51022a1c4493cbcc69aa288a0f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e183b35fb6412bbb7f01be5b8e745901a0e986b6
https://github.com/qemu/qemu/commit/e183b35fb6412bbb7f01be5b8e745901a0e986b6
Author: Peter Maydell <[email protected]>
Date: 2025-10-31 (Fri, 31 Oct 2025)
Changed paths:
M linux-user/syscall.c
Log Message:
-----------
linux-user: permit sendto() with NULL buf and 0 len
If you pass sendto() a NULL buffer, this is usually an error
(causing an EFAULT return); however if you pass a 0 length then
we should not try to validate the buffer provided. Instead we
skip the copying of the user data and possible processing
through fd_trans_target_to_host_data, and call the host syscall
with NULL, 0.
(unlock_user() permits a NULL buffer pointer for "do nothing"
so we don't need to special case the unlock code.)
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3102
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 0db2de22fcbf90adafab9d9dd1fc8203c66bfa75)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3e701b273fd16bc310eb450a0f623e57f3124993
https://github.com/qemu/qemu/commit/3e701b273fd16bc310eb450a0f623e57f3124993
Author: Paolo Bonzini <[email protected]>
Date: 2025-10-31 (Fri, 31 Oct 2025)
Changed paths:
M target/i386/hvf/x86hvf.c
M target/i386/kvm/kvm.c
M target/i386/nvmm/nvmm-all.c
M target/i386/whpx/whpx-all.c
Log Message:
-----------
target/i386: clear CPU_INTERRUPT_SIPI for all accelerators
Similar to what commit df32e5c5 did for TCG; fixes boot with multiple
processors on WHPX and probably more accelerators
Fixes: df32e5c568c ("i386/cpu: Prevent delivering SIPI during SMM in TCG mode",
2025-10-14)
Fixes: 1e8a7c403a7 ("i386/cpu: Prevent delivering SIPI during SMM in TCG mode",
in 10.0.x)
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3178
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit d5e1d2dea11b803ba9121fc12d3c1662b79ad941)
(Mjt: context fix due to missing v10.1.0-119-g87511341c30d
"add cpu_test_interrupt()/cpu_set_interrupt() helpers and use them tree wide")
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 562995173d5341cf86b9af25f7a31eb412d1e393
https://github.com/qemu/qemu/commit/562995173d5341cf86b9af25f7a31eb412d1e393
Author: peng guo <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
hw/i386/pc: Avoid overlap between CXL window and PCI 64bit BARs in QEMU 10.0.x
This is a backport of the fix from commit 8b1c560937467d0d9 to the QEMU
10.0.x LTS series.
When using a CXL Type 3 device together with a virtio 9p device in QEMU on a
physical server, the 9p device fails to initialize properly. The kernel reports
the following error:
virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1
9pnet_virtio virtio0: probe with driver 9pnet_virtio failed with error -22
Further investigation revealed that the 64-bit BAR space assigned to the 9pnet
device was overlapped by the memory window allocated for the CXL devices. As a
result, the kernel could not correctly access the BAR region, causing the
virtio device to malfunction.
An excerpt from /proc/iomem shows:
480010000-cffffffff : CXL Window 0
480010000-4bfffffff : PCI Bus 0000:00
4c0000000-4c01fffff : PCI Bus 0000:0c
4c0000000-4c01fffff : PCI Bus 0000:0d
4c0200000-cffffffff : PCI Bus 0000:00
4c0200000-4c0203fff : 0000:00:03.0
4c0200000-4c0203fff : virtio-pci-modern
To address this issue, this patch adds the reserved memory end calculation
for cxl devices to reserve sufficient address space and ensure that CXL memory
windows are allocated beyond all PCI 64-bit BARs. This prevents overlap with
64-bit BARs regions such as those used by virtio or other pcie devices,
resolving the conflict.
Tested on intel Granite Rapids(GNR) servers using QEMU 10.0 LTS,
resolving the issue without causing regressions.
QEMU Build Configuration:
./configure --prefix=/home/work/qemu_master/build/ \
--target-list=x86_64-softmmu \
--enable-kvm \
--enable-virtfs
QEMU Boot Command:
sudo /home/work/qemu_master/qemu/build/qemu-system-x86_64 \
-nographic -machine q35,cxl=on -enable-kvm -m 16G -smp 8 \
-hda /home/work/gp_qemu/rootfs.img \
-virtfs
local,path=/home/work/gp_qemu/share,mount_tag=host0,security_model=passthrough,id=host0
\
-kernel /home/work/linux_output/arch/x86/boot/bzImage \
--append "console=ttyS0 crashkernel=256M root=/dev/sda rootfstype=ext4
rw loglevel=8" \
-device pci-testdev,membar=2G \
-object memory-backend-ram,id=vmem0,share=on,size=4096M \
-device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \
-device cxl-rp,port=0,bus=cxl.1,id=root_port13,chassis=0,slot=2 \
-device
cxl-type3,bus=root_port13,volatile-memdev=vmem0,id=cxl-vmem0,sn=0x123456789 \
-M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G
Fixes: 03b39fcf64bc ("hw/cxl: Make the CXL fixed memory window setup a machine
parameter")
Signed-off-by: peng guo <[email protected]>
Tested-by: peng guo <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit d1193481dee63442fc41e47ca6ebc4cd34f1f69c)
(backport for missing-in-10.0.x v10.0.0-1264-g8b1c56093746
"hw/i386/pc: Remove PCMachineClass::broken_reserved_end field"
by peng quo)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b615e521784296f7ae9e4ec0324962637cce5581
https://github.com/qemu/qemu/commit/b615e521784296f7ae9e4ec0324962637cce5581
Author: Xiaoyao Li <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M hw/i386/x86-common.c
M target/i386/kvm/kvm.c
M target/i386/kvm/kvm_i386.h
Log Message:
-----------
i386/kvm/cpu: Init SMM cpu address space for hotplugged CPUs
The SMM cpu address space is initialized in a machine_init_done
notifier. It only runs once when QEMU starts up, which leads to the
issue that for any hotplugged CPU after the machine is ready, SMM
cpu address space doesn't get initialized.
Fix the issue by initializing the SMM cpu address space in x86_cpu_plug()
when the cpu is hotplugged.
Fixes: 591f817d819f ("target/i386: Define enum X86ASIdx for x86's address
spaces")
Reported-by: Peter Maydell <[email protected]>
Closes:
https://lore.kernel.org/qemu-devel/cafeaca_3kkz+a5rtzgmk8w5k6j7qpyd31hkvjbnxwr-fgt2...@mail.gmail.com/
Signed-off-by: Xiaoyao Li <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 639a29422754f62b4bfd26cff936b3c981758010)
(Mjt: the original Fixes: line is wrong:
https://lore.kernel.org/qemu-devel/[email protected]/T/#u
)
Fixes: 0516f4b70264 ("i386/cpu: Enable SMM cpu address space under KVM")
Fixes: 232d5c627589 ("i386/cpu: Enable SMM cpu address space under KVM"), 10.1.5
Signed-off-by: Michael Tokarev <[email protected]>
Commit: cf20f1090a812661c94d11297518ad3960c01e90
https://github.com/qemu/qemu/commit/cf20f1090a812661c94d11297518ad3960c01e90
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M block/crypto.c
Log Message:
-----------
block: remove 'detached-header' option from opts after use
The code for creating LUKS devices references a 'detached-header'
option in the QemuOpts data, but does not consume (remove) the
option.
Thus when the code later tries to convert the remaining unused
QemuOpts into a QCryptoBlockCreateOptions struct, an error is
reported by the QAPI code that 'detached-header' is not a valid
field.
This fixes a regression caused by
commit e818c01ae6e7c54c7019baaf307be59d99ce80b9
Author: Daniel P. Berrangé <[email protected]>
Date: Mon Feb 19 15:12:59 2024 +0000
qapi: drop unused QCryptoBlockCreateOptionsLUKS.detached-header
which identified that the QAPI field was unused, but failed to
realize the QemuOpts -> QCryptoBlockCreateOptions conversion
was seeing the left-over 'detached-header' option which had not
been removed from QemuOpts.
This problem was identified by the 'luks-detached-header' I/O
test, but unfortunately I/O tests are not run regularly for the
LUKS format.
Fixes: e818c01ae6e7c54c7019baaf307be59d99ce80b9
Reported-by: Thomas Huth <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Eric Blake <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 6eda39a87f4fda78befa4085e3644e4440afc1dd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 374eb96bc984c784408d082fc43394a87153dfa9
https://github.com/qemu/qemu/commit/374eb96bc984c784408d082fc43394a87153dfa9
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M block/crypto.c
Log Message:
-----------
block: fix luks 'amend' when run in coroutine
Launch QEMU with
$ qemu-img create \
--object secret,id=sec0,data=123456 \
-f luks -o key-secret=sec0 demo.luks 1g
$ qemu-system-x86_64 \
--object secret,id=sec0,data=123456 \
-blockdev
driver=luks,key-secret=sec0,file.filename=demo.luks,file.driver=file,node-name=luks
Then in QMP shell attempt
x-blockdev-amend job-id=fish node-name=luks
options={'state':'active','new-secret':'sec0','driver':'luks'}
It will result in an assertion
#0 __pthread_kill_implementation (threadid=<optimized out>,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007fad18b73f63 in __pthread_kill_internal (threadid=<optimized out>,
signo=6) at pthread_kill.c:89
#2 0x00007fad18b19f3e in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#3 0x00007fad18b016d0 in __GI_abort () at abort.c:77
#4 0x00007fad18b01639 in __assert_fail_base
(fmt=<optimized out>, assertion=<optimized out>, file=<optimized out>,
line=<optimized out>, function=<optimized out>) at assert.c:118
#5 0x00007fad18b120af in __assert_fail (assertion=<optimized out>,
file=<optimized out>, line=<optimized out>, function=<optimized out>)
at assert.c:127
#6 0x000055ff74fdbd46 in bdrv_graph_rdlock_main_loop () at
../block/graph-lock.c:260
#7 0x000055ff7548521b in graph_lockable_auto_lock_mainloop (x=<optimized
out>)
at /usr/src/debug/qemu-9.2.4-1.fc42.x86_64/include/block/graph-lock.h:266
#8 block_crypto_read_func (block=<optimized out>, offset=4096,
buf=0x55ffb6d66ef0 "", buflen=256000, opaque=0x55ffb5edcc30,
errp=0x55ffb6f00700)
at ../block/crypto.c:71
#9 0x000055ff75439f8b in qcrypto_block_luks_load_key
(block=block@entry=0x55ffb5edbe90, slot_idx=slot_idx@entry=0,
password=password@entry=0x55ffb67dc260 "123456",
masterkey=masterkey@entry=0x55ffb5fb0c40 "",
readfunc=readfunc@entry=0x55ff754851e0 <block_crypto_read_func>,
opaque=opaque@entry=0x55ffb5edcc30, errp=0x55ffb6f00700)
at ../crypto/block-luks.c:927
#10 0x000055ff7543b90f in qcrypto_block_luks_find_key
(block=<optimized out>, password=<optimized out>, masterkey=<optimized
out>, readfunc=<optimized out>, opaque=<optimized out>, errp=<optimized out>)
at ../crypto/block-luks.c:1045
#11 qcrypto_block_luks_amend_add_keyslot
(block=0x55ffb5edbe90, readfunc=0x55ff754851e0 <block_crypto_read_func>,
writefunc=0x55ff75485100 <block_crypto_write_func>, opaque=0x55ffb5edcc3,
opts_luks=0x7fad1715aef8, force=<optimized out>, errp=0x55ffb6f00700) at
../crypto/block-luks.c:1673
#12 qcrypto_block_luks_amend_options
(block=0x55ffb5edbe90, readfunc=0x55ff754851e0 <block_crypto_read_func>,
writefunc=0x55ff75485100 <block_crypto_write_func>, opaque=0x55ffb5edcc30,
options=0x7fad1715aef0, force=<optimized out>, errp=0x55ffb6f00700) at
../crypto/block-luks.c:1865
#13 0x000055ff75485b95 in block_crypto_amend_options_generic_luks
(bs=<optimized out>, amend_options=<optimized out>, force=<optimized
out>, errp=<optimized out>) at ../block/crypto.c:949
#14 0x000055ff75485c28 in block_crypto_co_amend_luks (bs=<optimized out>,
opts=<optimized out>, force=<optimized out>, errp=<optimized out>)
at ../block/crypto.c:1008
#15 0x000055ff754778e5 in blockdev_amend_run (job=0x55ffb6f00640,
errp=0x55ffb6f00700) at ../block/amend.c:52
#16 0x000055ff75468b90 in job_co_entry (opaque=0x55ffb6f00640) at
../job.c:1106
#17 0x000055ff755a0fc2 in coroutine_trampoline (i0=<optimized out>,
i1=<optimized out>) at ../util/coroutine-ucontext.c:175
This changes the read/write callbacks to not assert that they
are run in mainloop context if already in a coroutine.
This is also reproduced by qemu-iotests cases 295 and 296.
Fixes: 1f051dcbdf2e4b6f518db731c84e304b2b9d15ce
Signed-off-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit c86488abaf017ed3f5a636c3247cd640a93d3b08)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 389a2a60b7a9ddaa1d02fccef61e797e2f5a6d8d
https://github.com/qemu/qemu/commit/389a2a60b7a9ddaa1d02fccef61e797e2f5a6d8d
Author: Richard W.M. Jones <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M block/curl.c
Log Message:
-----------
block/curl.c: Fix CURLOPT_VERBOSE parameter type
In commit ed26056d90 ("block/curl.c: Use explicit long constants in
curl_easy_setopt calls") we missed a further call that takes a long
parameter.
Reported-by: Kevin Wolf <[email protected]>
Signed-off-by: Richard W.M. Jones <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit ad97769e9dcf4dbdaae6d859176e5f37fd6a7c66)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e0b76691b71fa1ab146a6e5575016b7533863343
https://github.com/qemu/qemu/commit/e0b76691b71fa1ab146a6e5575016b7533863343
Author: Sean Anderson <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M gdbstub/syscalls.c
Log Message:
-----------
gdbstub: Fix %s formatting
The format string for %s has two format characters. This causes it to
emit strings like "466f5bd8/6x" instead of "466f5bd8/6". GDB detects
this and returns EIO, causing all open File I/O calls to fail.
Fixes: 0820a075af ("gdbstub: Adjust gdb_do_syscall to only use uint32_t and
uint64_t")
Signed-off-by: Sean Anderson <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
(cherry picked from commit 524fc77d2322814f0dfde272559d74ec1599f01e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3eae402cc0c96cddae306f7ff27c7cfc10c9f87f
https://github.com/qemu/qemu/commit/3eae402cc0c96cddae306f7ff27c7cfc10c9f87f
Author: Edgar E. Iglesias <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M target/microblaze/op_helper.c
Log Message:
-----------
target/microblaze: Remove unused arg from check_divz()
Remove unused arg from check_divz(). No functional change.
Signed-off-by: Edgar E. Iglesias <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit a04c5ba543c1bc83a25a557e3b62ee811869b373)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1cfba04ff6d966f020ca23f5b515bbcc802e8566
https://github.com/qemu/qemu/commit/1cfba04ff6d966f020ca23f5b515bbcc802e8566
Author: Edgar E. Iglesias <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M target/microblaze/op_helper.c
M target/microblaze/translate.c
Log Message:
-----------
target/microblaze: div: Break out raise_divzero()
Break out raise_divzero() and take the opportunity to rename
and reorder function args to better match with spec and
pseudo code.
No functional change.
Signed-off-by: Edgar E. Iglesias <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 0e46b4d1f13b26c3c0e30eafa2be8eed76548bd3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b848b1c85b544bc3b836a92a79408e2fe3796cf9
https://github.com/qemu/qemu/commit/b848b1c85b544bc3b836a92a79408e2fe3796cf9
Author: Edgar E. Iglesias <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M target/microblaze/cpu.h
M target/microblaze/op_helper.c
Log Message:
-----------
target/microblaze: Handle signed division overflows
Handle signed division overflows as specified in UG984:
https://docs.amd.com/r/en-US/ug984-vivado-microblaze-ref/idiv
Signed-off-by: Edgar E. Iglesias <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
(cherry picked from commit cfc1d54251d3b4c4cf21c4fa278c8aea2fe25a99)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: de2f4352d3c6ef19a8502563c1bb5a33e822cf36
https://github.com/qemu/qemu/commit/de2f4352d3c6ef19a8502563c1bb5a33e822cf36
Author: Ilya Leoshkevich <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M target/s390x/tcg/misc_helper.c
Log Message:
-----------
target/s390x: Fix missing interrupts for small CKC values
Suppose TOD clock value is 0x1111111111111111 and clock-comparator
value is 0, in which case clock-comparator interruption should occur
immediately.
With the current code, tod2time(env->ckc - td->base.low) ends up being
a very large number, so this interruption never happens.
Fix by firing the timer immediately if env->ckc < td->base.low.
Cc: [email protected]
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: Ilya Leoshkevich <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit df7e9243d540ee130f044f975af8de33c45f5299)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8e51fc3b42bec2f03eee13c8847cf5be3a883a79
https://github.com/qemu/qemu/commit/8e51fc3b42bec2f03eee13c8847cf5be3a883a79
Author: Ilya Leoshkevich <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M target/s390x/tcg/mem_helper.c
Log Message:
-----------
target/s390x: Fix missing clock-comparator interrupts after reset
After reset, CKC value is set to 0, so if clock-comparator interrupts
are enabled, one should occur very shortly thereafter.
Currently the code that loads the respective control register does not
set tod_timer, so this does not happen.
Fix by adding a tcg_s390_tod_updated() call to LCTL and LCTLG.
Cc: [email protected]
Suggested-by: Thomas Huth <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: Ilya Leoshkevich <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit dacfec5157fb9e2249cf393a143bd545e80a6e31)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e46498aa6ed8280a53b633d4aa294743b54665f6
https://github.com/qemu/qemu/commit/e46498aa6ed8280a53b633d4aa294743b54665f6
Author: Ilya Leoshkevich <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M target/s390x/tcg/translate.c
Log Message:
-----------
target/s390x: Use address generation for register branch targets
Indirect branches to addresses taken from registers go through address
generation, e.g., for BRANCH ON CONDITION Principles of Operation says:
In the RR format, the contents of general register R2 are used to
generate the branch address
QEMU uses r2_nz handler for the respective register operands. Currently
it does not zero out extra bits in 24- and 31-bit addressing modes as
required by address generation. The very frequently used
s390x_tr_init_disas_context() function has a workaround for this,
but the code for saving an old PSW during an interrupt does not.
Add the missing masking to r2_nz. Enforce PSW validity by replacing the
workaround with an assertion.
Reported-by: Thomas Weißschuh <[email protected]>
Reported-by: Heiko Carstens <[email protected]>
Link:
https://lore.kernel.org/lkml/[email protected]/
Cc: [email protected]
Signed-off-by: Ilya Leoshkevich <[email protected]>
Tested-by: Thomas Weißschuh <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit fc976a67ded4232cf0b9ae3c11fe051da01e4456)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2b035829cb03094e80cccb8037441121df9b70c2
https://github.com/qemu/qemu/commit/2b035829cb03094e80cccb8037441121df9b70c2
Author: Ilya Leoshkevich <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M tests/tcg/s390x/Makefile.softmmu-target
A tests/tcg/s390x/sckc.S
Log Message:
-----------
tests/tcg/s390x: Test SET CLOCK COMPARATOR
Add a small test to prevent regressions.
Cc: [email protected]
Reviewed-by: Thomas Huth <[email protected]>
Signed-off-by: Ilya Leoshkevich <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 0408c61e27aca56c2d40aeb6ca0e5c5f8b8c3845)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a1cb6b62b5332f246c92dc51576fc3a000cc6aba
https://github.com/qemu/qemu/commit/a1cb6b62b5332f246c92dc51576fc3a000cc6aba
Author: Xiaoyao Li <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M backends/hostmem-shm.c
Log Message:
-----------
hostmem/shm: Allow shm memory backend serve as shared memory for coco-VMs
shm can surely serve as the shared memory for coco-VMs. But currently it
doesn't check the backend->guest_memfd to pass down the RAM_GUEST_MEMFD
flag. It leads to failure when creating coco-VMs (e.g., TDX guest) which
require private mmeory.
Set and pass down RAM_GUEST_MEMFD when backend->guest_memfd is true, to
allow shm memory backend serve as shared memory for coco-VMs.
Cc: Stefano Garzarella <[email protected]>
Cc: qemu-stable <[email protected]>
Signed-off-by: Xiaoyao Li <[email protected]>
Acked-by: David Hildenbrand <[email protected]>
Acked-by: Stefano Garzarella <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Peter Xu <[email protected]>
(cherry picked from commit 75e2cb144191ecdbba87cfea3608cdc0664c8142)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 08176f24dc05e2bc01628ff1aaa0d628f2237ca6
https://github.com/qemu/qemu/commit/08176f24dc05e2bc01628ff1aaa0d628f2237ca6
Author: Peter Maydell <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M target/i386/tcg/decode-new.c.inc
Log Message:
-----------
target/x86: Correctly handle invalid 0x0f 0xc7 0xxx insns
In the decode_group9() function, if we don't recognise the insn as
one that we should handle, we leave the 'entry' pointer unaltered.
Because the X86OpEntry struct has a union for the gen and decode
pointers, this means that the top level code will call decode.e.gen()
which tries to use the decode function pointer (still set to
decode_group9) as a gen function pointer.
This is undefined behaviour, but seems to be mostly harmless in
practice (we call decode_group9() again with bogus arguments and it
does nothing). If you have CFI enabled then it will trip the CFI
check:
../target/i386/tcg/decode-new.c.inc:2862:9: runtime error: control flow
integrity check for type 'void (struct DisasContext *, struct X86DecodedInsn
*)' failed during indirect function call
Set *entry to UNKNOWN_OPCODE to provoke the #UD exception, as we do
in decode_group1A() and decode_group11() for similar situations.
Thanks to the bug reporter for the clear description and analysis of
the bug and the simple reproducer.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3172
Fixes: fcd16539ebfe2 ("target/i386: convert CMPXCHG8B/CMPXCHG16B to new
decoder")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 4f503afc7eb503997fedad84f24e2cdf696a7a0e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 363114a4a054de315f82045bf6f4ef5e007b87e0
https://github.com/qemu/qemu/commit/363114a4a054de315f82045bf6f4ef5e007b87e0
Author: Albert Esteve <[email protected]>
Date: 2025-11-14 (Fri, 14 Nov 2025)
Changed paths:
M hw/virtio/vhost-user.c
Log Message:
-----------
vhost-user: fix shared object lookup handler logic
Refactor backend_read() function and add a reply_ack variable
to have the option for handlers to force tweak whether they should
send a reply or not without depending on VHOST_USER_NEED_REPLY_MASK
flag.
This fixes an issue with
vhost_user_backend_handle_shared_object_lookup() logic, as the
error path was not closing the backend channel correctly. So,
we can remove the reply call from within the handler, make
sure it returns early on errors as other handlers do and
set the reply_ack variable on backend_read() to true to ensure
that it will send a response, thus keeping the original intent.
Fixes: 1609476662 ("vhost-user: add shared_object msg")
Cc: [email protected]
Signed-off-by: Albert Esteve <[email protected]>
Reviewed-by: Stefano Garzarella <[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 fde5930cc37175cfcd0f03a089e26f4458a52311)
(Mjt: context fix)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: df5d79b9e3f1c9bd222424c18c7fc468827fb0f0
https://github.com/qemu/qemu/commit/df5d79b9e3f1c9bd222424c18c7fc468827fb0f0
Author: Shameer Kolothum <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M tests/qtest/bios-tables-test-allowed-diff.h
Log Message:
-----------
tests/qtest/bios-tables-test: Prepare for _DSM change in the DSDT table
Subsequent patch will fix the GPEX _DSM method. Add the affected DSDT blobs
to allowed-diff list for bios-table tests.
Signed-off-by: Shameer Kolothum <[email protected]>
Reviewed-by: Eric Auger <[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 3e6ad83f209ea8cf497e5d160e44c1bc5e518f1a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f55373aa793ba02349aff61a679f2b3ec0483595
https://github.com/qemu/qemu/commit/f55373aa793ba02349aff61a679f2b3ec0483595
Author: Eric Auger <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M hw/pci-host/gpex-acpi.c
Log Message:
-----------
hw/pci-host/gpex-acpi: Fix _DSM function 0 support return value
Currently, only function 0 is supported. According to the ACPI
Specification, Revision 6.6, Section 9.1.1 “_DSM (Device Specific
Method)”, bit 0 should be 0 to indicate that no other functions
are supported beyond function 0.
The resulting AML change looks like this:
Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If ((Arg0 == ToUUID ("e5c937d0-3553-4d7a-9117-ea4d19c3434d")
{
If ((Arg2 == Zero))
{
Return (Buffer (One)
{
- 0x01 // .
+ 0x00 // .
})
}
}
}
Fixes: 5b85eabe68f9 ("acpi: add acpi_dsdt_add_gpex")
Signed-off-by: Eric Auger <[email protected]>
Signed-off-by: Shameer Kolothum <[email protected]>
Tested-by: Zhangfei Gao <[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 325aa2d86a20786c308b0874d15a60d1b924bd0e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ac9e3c263ceb329593ca58af296ce64416f3089c
https://github.com/qemu/qemu/commit/ac9e3c263ceb329593ca58af296ce64416f3089c
Author: Shameer Kolothum <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M tests/data/acpi/aarch64/virt/DSDT
M tests/data/acpi/aarch64/virt/DSDT.acpihmatvirt
M tests/data/acpi/aarch64/virt/DSDT.memhp
M tests/data/acpi/aarch64/virt/DSDT.pxb
M tests/data/acpi/aarch64/virt/DSDT.topology
M tests/data/acpi/riscv64/virt/DSDT
M tests/data/acpi/x86/microvm/DSDT.pcie
M tests/qtest/bios-tables-test-allowed-diff.h
Log Message:
-----------
tests/qtest/bios-tables-test: Update DSDT blobs after GPEX _DSM change
Update the reference DSDT blobs after GPEX _DSM change. This affects the
aarch64 'virt', riscv64 "virt", loongarch64 "virt" and the x86 'microvm'
machines.
DSDT diff is the same for all the machines/tests:
/*
* Intel ACPI Component Architecture
* AML/ASL+ Disassembler version 20230628 (64-bit version)
* Copyright (c) 2000 - 2023 Intel Corporation
*
* Disassembling to symbolic ASL+ operators
*
- * Disassembly of tests/data/acpi/aarch64/virt/DSDT, Fri Oct 10 11:18:21 2025
+ * Disassembly of /tmp/aml-E6V9D3, Fri Oct 10 11:18:21 2025
*
* Original Table Header:
* Signature "DSDT"
* Length 0x000014D9 (5337)
* Revision 0x02
- * Checksum 0xA4
+ * Checksum 0xA5
* OEM ID "BOCHS "
* OEM Table ID "BXPC "
* OEM Revision 0x00000001 (1)
* Compiler ID "BXPC"
* Compiler Version 0x00000001 (1)
*/
DefinitionBlock ("", "DSDT", 2, "BOCHS ", "BXPC ", 0x00000001)
{
Scope (\_SB)
{
Device (C000)
{
Name (_HID, "ACPI0007" /* Processor Device */) // _HID: Hardware
ID
Name (_UID, Zero) // _UID: Unique ID
}
@@ -1822,33 +1822,33 @@
Else
{
CDW1 |= 0x04
}
Return (Arg3)
}
Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
{
If ((Arg0 == ToUUID ("e5c937d0-3553-4d7a-9117-ea4d19c3434d")
/* Device Labeling Interface */))
{
If ((Arg2 == Zero))
{
Return (Buffer (One)
{
- 0x01
// .
+ 0x00
// .
})
}
}
Return (Buffer (One)
{
0x00 // .
})
}
Device (RES0)
{
Name (_HID, "PNP0C02" /* PNP Motherboard Resources */) //
_HID: Hardware ID
Name (_CRS, ResourceTemplate () // _CRS: Current Resource
Settings
{
QWordMemory (ResourceProducer, PosDecode, MinFixed,
MaxFixed, NonCacheable, ReadWrite,
Signed-off-by: Shameer Kolothum <[email protected]>
Reviewed-by: Eric Auger <[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 ccf166d89dcf57c9d333f05173851f90e416097a)
(Mjt: regenerate all actual tables for 10.0.x)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 17a9b67d675c4325b34529244c22eb87f94fb59c
https://github.com/qemu/qemu/commit/17a9b67d675c4325b34529244c22eb87f94fb59c
Author: Akihiko Odaki <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M qemu-img.c
Log Message:
-----------
qemu-img: Fix amend option parse error handling
qemu_opts_del(opts) dereferences opts->list, which is the old amend_opts
pointer that can be dangling after executing
qemu_opts_append(amend_opts, bs->drv->create_opts) and cause
use-after-free.
Fix the potential use-after-free by moving the qemu_opts_del() call
before the qemu_opts_append() call.
Signed-off-by: Akihiko Odaki <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit f00bcc833790c72c08bc5eed97845fdaa7542507)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: cf17374ef53e15eb0f05413f7a576d32a2e8fc5d
https://github.com/qemu/qemu/commit/cf17374ef53e15eb0f05413f7a576d32a2e8fc5d
Author: Alberto Garcia <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M qemu-img.c
M tests/qemu-iotests/024
M tests/qemu-iotests/024.out
Log Message:
-----------
qemu-img rebase: don't exceed IO_BUF_SIZE in one operation
During a rebase operation data is copied from the backing chain into
the target image using a loop, and each iteration looks for a
contiguous region of allocated data of at most IO_BUF_SIZE (2 MB).
Once that region is found, and in order to avoid partial writes, its
boundaries are extended so they are aligned to the (sub)clusters of
the target image (see commit 12df580b).
This operation can however result in a region that exceeds the maximum
allowed IO_BUF_SIZE, crashing qemu-img.
This can be easily reproduced when the source image has a smaller
cluster size than the target image:
base <- int <- active
$ qemu-img create -f qcow2 base.qcow2 4M
$ qemu-img create -f qcow2 -F qcow2 -b base.qcow2 -o cluster_size=1M int.qcow2
$ qemu-img create -f qcow2 -F qcow2 -b int.qcow2 -o cluster_size=2M
active.qcow2
$ qemu-io -c "write -P 0xff 1M 2M" int.qcow2
$ qemu-img rebase -F qcow2 -b base.qcow2 active.qcow2
qemu-img: qemu-img.c:4102: img_rebase: Assertion `written + pnum <=
IO_BUF_SIZE' failed.
Aborted
Cc: qemu-stable <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3174
Fixes: 12df580b3b7f ("qemu-img: rebase: avoid unnecessary COW operations")
Signed-off-by: Alberto Garcia <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 909852ba6b4a22fd2b6f9d8b88adb5fc47dfa781)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f1fa65427ca2c7619ff9e2938dcba083b7f65688
https://github.com/qemu/qemu/commit/f1fa65427ca2c7619ff9e2938dcba083b7f65688
Author: Alberto Garcia <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M tests/qemu-iotests/024
M tests/qemu-iotests/024.out
Log Message:
-----------
tests/qemu-iotest: fix iotest 024 with qed images
Use 'qemu-io -c map' instead of 'qemu-img map' to get an output that
works with both image types.
Cc: qemu-stable <[email protected]>
Fixes: 909852ba6b4a ("qemu-img rebase: don't exceed IO_BUF_SIZE in one
operation")
Fixes: 585d5c1db8bd ("qemu-img rebase: don't exceed IO_BUF_SIZE in one
operation") in 10.0.x
Signed-off-by: Alberto Garcia <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Eric Blake <[email protected]>
Tested-by: Thomas Huth <[email protected]>
Signed-off-by: Eric Blake <[email protected]>
(cherry picked from commit 4c91719a6a78a1c24d8bb854f7594e767962d0d9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a413e6481d175dc19e88b1ddfdd062a33429cc83
https://github.com/qemu/qemu/commit/a413e6481d175dc19e88b1ddfdd062a33429cc83
Author: Eric Blake <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M io/net-listener.c
M io/trace-events
Log Message:
-----------
qio: Add trace points to net_listener
Upcoming patches will adjust how net_listener watches for new client
connections; adding trace points now makes it easier to debug that the
changes work as intended. For example, adding
--trace='qio_net_listener*' to the qemu-storage-daemon command line
before --nbd-server will track when the server first starts listening
for clients.
Signed-off-by: Eric Blake <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 59506e59e0f0a773e892104b945d0f15623381a7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4cb5b13ecd77dff818e669109582deb128c44d36
https://github.com/qemu/qemu/commit/4cb5b13ecd77dff818e669109582deb128c44d36
Author: Eric Blake <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M io/net-listener.c
Log Message:
-----------
qio: Unwatch before notify in QIONetListener
When changing the callback registered with QIONetListener, the code
was calling notify on the old opaque data prior to actually removing
the old GSource objects still pointing to that data. Similarly,
during finalize, it called notify before tearing down the various
GSource objects tied to the data.
In practice, a grep of the QEMU code base found that every existing
client of QIONetListener passes in a NULL notifier (the opaque data,
if non-NULL, outlives the NetListener and so does not need cleanup
when the NetListener is torn down), so this patch has no impact. And
even if a caller had passed in a reference-counted object with a
notifier of object_unref but kept its own reference on the data, then
the early notify would merely reduce a refcount from (say) 2 to 1, but
not free the object. However, it is a latent bug waiting to bite any
future caller that passes in data where the notifier actually frees
the object, because the GSource could then trigger a use-after-free if
it loses the race on a last-minute client connection resulting in the
data being passed to one final use of the async callback.
Better is to delay the notify call until after all GSource that have
been given a copy of the opaque data are torn down.
CC: [email protected]
Fixes: 530473924d "io: introduce a network socket listener API", v2.12.0
Signed-off-by: Eric Blake <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 6e03d5cdc991f5db86969fc6aeaca96234426263)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 62b43d94d29fd571de970d9b427d251785349c38
https://github.com/qemu/qemu/commit/62b43d94d29fd571de970d9b427d251785349c38
Author: Eric Blake <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M include/io/net-listener.h
M io/net-listener.c
M io/trace-events
Log Message:
-----------
qio: Remember context of qio_net_listener_set_client_func_full
io/net-listener.c has two modes of use: asynchronous (the user calls
qio_net_listener_set_client_func to wake up the callback via the
global GMainContext, or qio_net_listener_set_client_func_full to wake
up the callback via the caller's own alternative GMainContext), and
synchronous (the user calls qio_net_listener_wait_client which creates
its own GMainContext and waits for the first client connection before
returning, with no need for a user's callback). But commit 938c8b79
has a latent logic flaw: when qio_net_listener_wait_client finishes on
its temporary context, it reverts all of the siocs back to the global
GMainContext rather than the potentially non-NULL context they might
have been originally registered with. Similarly, if the user creates
a net-listener, adds initial addresses, registers an async callback
with a non-default context (which ties to all siocs for the initial
addresses), then adds more addresses with qio_net_listener_add, the
siocs for later addresses are blindly placed in the global context,
rather than sharing the context of the earlier ones.
In practice, I don't think this has caused issues. As pointed out by
the original commit, all async callers prior to that commit were
already okay with the NULL default context; and the typical usage
pattern is to first add ALL the addresses the listener will pay
attention to before ever setting the async callback. Likewise, if a
file uses only qio_net_listener_set_client_func instead of
qio_net_listener_set_client_func_full, then it is never using a custom
context, so later assignments of async callbacks will still be to the
same global context as earlier ones. Meanwhile, any callers that want
to do the sync operation to grab the first client are unlikely to
register an async callback; altogether bypassing the question of
whether later assignments of a GSource are being tied to a different
context over time.
I do note that chardev/char-socket.c is the only file that calls both
qio_net_listener_wait_client (sync for a single client in
tcp_chr_accept_server_sync), and qio_net_listener_set_client_func_full
(several places, all with chr->gcontext, but sometimes with a NULL
callback function during teardown). But as far as I can tell, the two
uses are mutually exclusive, based on the is_waitconnect parameter to
qmp_chardev_open_socket_server.
That said, it is more robust to remember when an async callback
function is tied to a non-default context, and have both the sync wait
and any late address additions honor that same context. That way, the
code will be robust even if a later user performs a sync wait for a
specific client in the middle of servicing a longer-lived
QIONetListener that has an async callback for all other clients.
CC: [email protected]
Fixes: 938c8b79 ("qio: store gsources for net listeners", v2.12.0)
Signed-off-by: Eric Blake <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit b5676493a08b4ff80680aae7a1b1bfef8797c6e7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ec2f4f9cae66840450ca01941ec4f4555051d3a8
https://github.com/qemu/qemu/commit/ec2f4f9cae66840450ca01941ec4f4555051d3a8
Author: Eric Blake <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M include/io/net-listener.h
M io/net-listener.c
Log Message:
-----------
qio: Protect NetListener callback with mutex
Without a mutex, NetListener can run into this data race between a
thread changing the async callback callback function to use when a
client connects, and the thread servicing polling of the listening
sockets:
Thread 1:
qio_net_listener_set_client_func(lstnr, f1, ...);
=> foreach sock: socket
=> object_ref(lstnr)
=> sock_src = qio_channel_socket_add_watch_source(sock, ....,
lstnr, object_unref);
Thread 2:
poll()
=> event POLLIN on socket
=> ref(GSourceCallback)
=> if (lstnr->io_func) // while lstnr->io_func is f1
...interrupt..
Thread 1:
qio_net_listener_set_client_func(lstnr, f2, ...);
=> foreach sock: socket
=> g_source_unref(sock_src)
=> foreach sock: socket
=> object_ref(lstnr)
=> sock_src = qio_channel_socket_add_watch_source(sock, ....,
lstnr, object_unref);
Thread 2:
=> call lstnr->io_func(lstnr->io_data) // now sees f2
=> return dispatch(sock)
=> unref(GSourceCallback)
=> destroy-notify
=> object_unref
Found by inspection; I did not spend the time trying to add sleeps or
execute under gdb to try and actually trigger the race in practice.
This is a SEGFAULT waiting to happen if f2 can become NULL because
thread 1 deregisters the user's callback while thread 2 is trying to
service the callback. Other messes are also theoretically possible,
such as running callback f1 with an opaque pointer that should only be
passed to f2 (if the client code were to use more than just a binary
choice between a single async function or NULL).
Mitigating factor: if the code that modifies the QIONetListener can
only be reached by the same thread that is executing the polling and
async callbacks, then we are not in a two-thread race documented above
(even though poll can see two clients trying to connect in the same
window of time, any changes made to the listener by the first async
callback will be completed before the thread moves on to the second
client). However, QEMU is complex enough that this is hard to
generically analyze. If QMP commands (like nbd-server-stop) are run
in the main loop and the listener uses the main loop, things should be
okay. But when a client uses an alternative GMainContext, or if
servicing a QMP command hands off to a coroutine to avoid blocking, I
am unable to state with certainty whether a given net listener can be
modified by a thread different from the polling thread running
callbacks.
At any rate, it is worth having the API be robust. To ensure that
modifying a NetListener can be safely done from any thread, add a
mutex that guarantees atomicity to all members of a listener object
related to callbacks. This problem has been present since
QIONetListener was introduced.
Note that this does NOT prevent the case of a second round of the
user's old async callback being invoked with the old opaque data, even
when the user has already tried to change the async callback during
the first async callback; it is only about ensuring that there is no
sharding (the eventual io_func(io_data) call that does get made will
correspond to a particular combination that the user had requested at
some point in time, and not be sharded to a combination that never
existed in practice). In other words, this patch maintains the status
quo that a user's async callback function already needs to be robust
to parallel clients landing in the same window of poll servicing, even
when only one client is desired, if that particular listener can be
amended in a thread other than the one doing the polling.
CC: [email protected]
Fixes: 53047392 ("io: introduce a network socket listener API", v2.12.0)
Signed-off-by: Eric Blake <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
[eblake: minor commit message wording improvements]
Signed-off-by: Eric Blake <[email protected]>
(cherry picked from commit 9d86181874ab7b0e95ae988f6f80715943c618c6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f6d2af610a3477da8b71348a0f16230659a31c55
https://github.com/qemu/qemu/commit/f6d2af610a3477da8b71348a0f16230659a31c55
Author: Peter Maydell <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M hw/net/e1000e_core.c
Log Message:
-----------
hw/net/e1000e_core: Don't advance desc_offset for NULL buffer RX descriptors
In e1000e_write_packet_to_guest() we don't write data for RX descriptors
where the buffer address is NULL (as required by the i82574 datasheet
section 7.1.7.2). However, when we do this we still update desc_offset
by the amount of data we would have written to the RX descriptor if
it had a valid buffer pointer, resulting in our dropping that data
entirely. The data sheet is not 100% clear on the subject, but this
seems unlikely to be the correct behaviour.
Rearrange the null-descriptor logic so that we don't treat these
do-nothing descriptors as if we'd really written the data.
This both fixes a bug and also is a prerequisite to cleaning up
the size calculation logic in the next patch.
(Cc to stable largely because it will be needed for the next patch,
which fixes a more serious bug.)
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit 6da0c9828194eb21e54fe4264cd29a1b85a29f33)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 61f8acd3e6d21827c38cb43977b73def7ff22400
https://github.com/qemu/qemu/commit/61f8acd3e6d21827c38cb43977b73def7ff22400
Author: Peter Maydell <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M hw/net/e1000e_core.c
Log Message:
-----------
hw/net/e1000e_core: Correct rx oversize packet checks
In e1000e_write_packet_to_guest() we attempt to ensure that we don't
write more of a packet to a descriptor than will fit in the guest
configured receive buffers. However, this code does not allow for
the "packet split" feature. When packet splitting is enabled, the
first of up to 4 buffers in the descriptor is used for the packet
header only, with the payload going into buffers 2, 3 and 4. Our
length check only checks against the total sizes of all 4 buffers,
which meant that if an incoming packet was large enough to fit in (1
+ 2 + 3 + 4) but not into (2 + 3 + 4) and packet splitting was
enabled, we would run into the assertion in
e1000e_write_hdr_frag_to_rx_buffers() that we had enough buffers for
the data:
qemu-system-i386: ../../hw/net/e1000e_core.c:1418: void
e1000e_write_payload_frag_to_rx_buffers(E1000ECore *, hwaddr *, E1000EBAState
*, const char *, dma_addr_t): Assertion `bastate->cur_idx < MAX_PS_BUFFERS'
failed.
A malicious guest could provoke this assertion by configuring the
device into loopback mode, and then sending itself a suitably sized
packet into a suitably arrange rx descriptor.
The code also fails to deal with the possibility that the descriptor
buffers are sized such that the trailing checksum word does not fit
into the last descriptor which has actual data, which might also
trigger this assertion.
Rework the length handling to use two variables:
* desc_size is the total amount of data DMA'd to the guest
for the descriptor being processed in this iteration of the loop
* rx_desc_buf_size is the total amount of space left in it
As we copy data to the guest (packet header, payload, checksum),
update these two variables. (Previously we attempted to calculate
desc_size once at the top of the loop, but this is too difficult to
do correctly.) Then we can use the variables to ensure that we clamp
the amount of copied payload data to the remaining space in the
descriptor's buffers, even if we've used one of the buffers up in the
packet-split code, and we can tell whether we have enough space for
the full checksum word in this descriptor or whether we're going to
need to split that to the following descriptor.
I have included comments that hopefully help to make the loop
logic a little clearer.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/537
Reviewed-by: Akihiko Odaki <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit 9d946d56a2ac8a6c2df186e20d24810255c83a3f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a1dc98ef72b80f56fb520d5644112b941ae810e3
https://github.com/qemu/qemu/commit/a1dc98ef72b80f56fb520d5644112b941ae810e3
Author: Peter Maydell <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M hw/net/e1000e_core.c
Log Message:
-----------
hw/net/e1000e_core: Adjust e1000e_write_payload_frag_to_rx_buffers() assert
An assertion in e1000e_write_payload_frag_to_rx_buffers() attempts to
guard against the calling code accidentally trying to write too much
data to a single RX descriptor, such that the E1000EBAState::cur_idx
indexes off the end of the EB1000BAState::written[] array.
Unfortunately it is overzealous: it asserts that cur_idx is in
range after it has been incremented. This will fire incorrectly
for the case where the guest configures four buffers and exactly
enough bytes are written to fill all four of them.
The only places where we use cur_idx and index in to the written[]
array are the functions e1000e_write_hdr_frag_to_rx_buffers() and
e1000e_write_payload_frag_to_rx_buffers(), so we can rewrite this to
assert before doing the array dereference, rather than asserting
after updating cur_idx.
Cc: [email protected]
Reviewed-by: Akihiko Odaki <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit bab496a18358643b686f69e2b97d73fb98d37e79)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 134f0c58547bc680732a9fc7556329134ef81dee
https://github.com/qemu/qemu/commit/134f0c58547bc680732a9fc7556329134ef81dee
Author: Peter Maydell <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M net/net.c
Log Message:
-----------
net: pad packets to minimum length in qemu_receive_packet()
In commits like 969e50b61a28 ("net: Pad short frames to minimum size
before sending from SLiRP/TAP") we switched away from requiring
network devices to handle short frames to instead having the net core
code do the padding of short frames out to the ETH_ZLEN minimum size.
We then dropped the code for handling short frames from the network
devices in a series of commits like 140eae9c8f7 ("hw/net: e1000:
Remove the logic of padding short frames in the receive path").
This missed one route where the device's receive code can still see a
short frame: if the device is in loopback mode and it transmits a
short frame via the qemu_receive_packet() function, this will be fed
back into its own receive code without being padded.
Add the padding logic to qemu_receive_packet().
This fixes a buffer overrun which can be triggered in the
e1000_receive_iov() logic via the loopback code path.
Other devices that use qemu_receive_packet() to implement loopback
are cadence_gem, dp8393x, lan9118, msf2-emac, pcnet, rtl8139
and sungem.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3043
Reviewed-by: Akihiko Odaki <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit a01344d9d78089e9e585faaeb19afccff2050abf)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c0d4545f715a4e776bee53563be9ff54bdc5b927
https://github.com/qemu/qemu/commit/c0d4545f715a4e776bee53563be9ff54bdc5b927
Author: Peter Maydell <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M hw/display/xlnx_dp.c
Log Message:
-----------
hw/display/xlnx_dp.c: Don't abort on AUX FIFO overrun/underrun
The documentation of the Xilinx DisplayPort subsystem at
https://www.xilinx.com/support/documents/ip_documentation/v_dp_txss1/v3_1/pg299-v-dp-txss1.pdf
doesn't say what happens if a guest tries to issue an AUX write
command with a length greater than the amount of data in the AUX
write FIFO, or tries to write more data to the write FIFO than it can
hold, or issues multiple commands that put data into the AUX read
FIFO without reading it such that it overflows.
Currently QEMU will abort() in these guest-error situations, either
in xlnx_dp.c itself or in the fifo8 code. Make these cases all be
logged as guest errors instead. We choose to ignore the new data on
overflow, and return 0 on underflow. This is in line with how we handled
the "read from empty RX FIFO" case in commit a09ef5040477.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1418
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1419
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1424
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Edgar E. Iglesias <[email protected]>
Message-id: [email protected]
(cherry picked from commit f52db7f34242d3398bab0bacaa3e5dde99be5258)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7030471ef5891d8d5aa997e202e9caaba3358149
https://github.com/qemu/qemu/commit/7030471ef5891d8d5aa997e202e9caaba3358149
Author: Peter Maydell <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M hw/display/xlnx_dp.c
Log Message:
-----------
hw/display/xlnx_dp: Don't abort for unsupported graphics formats
If the guest writes an invalid or unsupported value to the
AV_BUF_FORMAT register, currently we abort(). Instead, log this as
either a guest error or an unimplemented error and continue.
The existing code treats DP_NL_VID_CB_Y0_CR_Y1 as x8b8g8r8
via a "case 0" that does not use the enum constant name for some
reason; we leave that alone beyond adding a comment about the
weird code.
Documentation of this register seems to be at:
https://docs.amd.com/r/en-US/ug1087-zynq-ultrascale-registers/AV_BUF_FORMAT-DISPLAY_PORT-Register
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1415
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Edgar E. Iglesias <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
(cherry picked from commit 032333eba77b83dfbd74071cc2971f0bda9a3d4f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6d2449eab8039534bb0e4295d2b74f25d1e45404
https://github.com/qemu/qemu/commit/6d2449eab8039534bb0e4295d2b74f25d1e45404
Author: Peter Maydell <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M hw/misc/npcm_clk.c
Log Message:
-----------
hw/misc/npcm_clk: Don't divide by zero when calculating frequency
If the guest misprograms the PLL registers to request a zero
divisor, we currently fall over with a division by zero:
../../hw/misc/npcm_clk.c:221:14: runtime error: division by zero
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
../../hw/misc/npcm_clk.c:221:14
Thread 1 "qemu-system-aar" received signal SIGFPE, Arithmetic exception.
0x00005555584d8f6d in npcm7xx_clk_update_pll (opaque=0x7fffed159a20) at
../../hw/misc/npcm_clk.c:221
221 freq /= PLLCON_INDV(con) * PLLCON_OTDV1(con) *
PLLCON_OTDV2(con);
Avoid this by treating this invalid setting like a stopped clock
(setting freq to 0).
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/549
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
(cherry picked from commit 5fc50b4ec841c8a01e7346c2c804088fc3accb6b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d5fb3f5409d1129900f524fab166e411fb2898cf
https://github.com/qemu/qemu/commit/d5fb3f5409d1129900f524fab166e411fb2898cf
Author: Vincent Vanlaer <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M block/commit.c
Log Message:
-----------
block: get type of block allocation in commit_run
bdrv_co_common_block_status_above not only returns whether the block is
allocated, but also if it contains zeroes.
Signed-off-by: Vincent Vanlaer <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
(cherry picked from commit 71365ee433125026d9744a0a37142c81ff312b53)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 140b48435538c2a548b2777a3aa3dff6aeadaab9
https://github.com/qemu/qemu/commit/140b48435538c2a548b2777a3aa3dff6aeadaab9
Author: Vincent Vanlaer <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M block/commit.c
Log Message:
-----------
block: move commit_run loop to separate function
Signed-off-by: Vincent Vanlaer <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
(cherry picked from commit 23743ab282af4fbb80fdc049bff2c93668c73c83)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4867965a59677107f40765a5dddc88625c88c42a
https://github.com/qemu/qemu/commit/4867965a59677107f40765a5dddc88625c88c42a
Author: Vincent Vanlaer <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M block/commit.c
Log Message:
-----------
block: refactor error handling of commit_iteration
Signed-off-by: Vincent Vanlaer <[email protected]>
Message-Id: <[email protected]>
[vsementsov]: move action declaration to the top of the function
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
(cherry picked from commit 0648c76ad198e91515771fbbeaac3a3807669a4a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 65c2376abe0c2ae78e80cd2f7213b22d181a4a09
https://github.com/qemu/qemu/commit/65c2376abe0c2ae78e80cd2f7213b22d181a4a09
Author: Vincent Vanlaer <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M block/commit.c
Log Message:
-----------
block: allow commit to unmap zero blocks
Non-active block commits do not discard blocks only containing zeros,
causing images to lose sparseness after the commit. This commit fixes
that by writing zero blocks using blk_co_pwrite_zeroes rather than
writing them out as any other arbitrary data.
Signed-off-by: Vincent Vanlaer <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
(cherry picked from commit 6f3199f99600fe75f32f78574e507f347de80854)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b0a1f27e2118caf603f4df37eb17ae39bc4a4c1f
https://github.com/qemu/qemu/commit/b0a1f27e2118caf603f4df37eb17ae39bc4a4c1f
Author: Vincent Vanlaer <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
A tests/qemu-iotests/tests/commit-zero-blocks
A tests/qemu-iotests/tests/commit-zero-blocks.out
Log Message:
-----------
block: add test non-active commit with zeroed data
Signed-off-by: Vincent Vanlaer <[email protected]>
Tested-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
(cherry picked from commit 68aba2a9350345d109f8036f9eff68b81b1c2167)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 91da2fc0f0b4f7031596926509e0373f8146fa4e
https://github.com/qemu/qemu/commit/91da2fc0f0b4f7031596926509e0373f8146fa4e
Author: Alex Bennée <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M tests/functional/test_aarch64_xen.py
Log Message:
-----------
tests: move test_xen assets to share.linaro.org
Linaro are migrating file-hosting from the old NextCloud instance to
another sharing site.
Reviewed-by: Thomas Huth <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
(cherry picked from commit 863449cc8ec7ff23d41ac71d462e2349e11b3852)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 28c399a160e11b3ea8462bd0bf87d7839661e5a3
https://github.com/qemu/qemu/commit/28c399a160e11b3ea8462bd0bf87d7839661e5a3
Author: Alex Bennée <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M tests/functional/test_aarch64_virt.py
Log Message:
-----------
tests: move test_virt assets to share.linaro.org
Linaro are migrating file-hosting from the old NextCloud instance to
another sharing site. While I'm at it drop the old pauth-impdef flag
which is no longer needed.
Reviewed-by: Thomas Huth <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
(cherry picked from commit dfaf3695b20d653338c2f34edbbb552f697033c3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: bbfdddd74ebab999a3b54694e05a2d9b379f7890
https://github.com/qemu/qemu/commit/bbfdddd74ebab999a3b54694e05a2d9b379f7890
Author: Alex Bennée <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M tests/functional/test_netdev_ethtool.py
Log Message:
-----------
tests: move test_netdev_ethtool to share.linaro.org
Linaro are migrating file-hosting from the old NextCloud instance to
another sharing site.
Reviewed-by: Thomas Huth <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
(cherry picked from commit 5ff8d1fac98ba35391412883a17feb16a5b464e9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7a4c4725abc6a7aaabc6a733b5501f5c754707b4
https://github.com/qemu/qemu/commit/7a4c4725abc6a7aaabc6a733b5501f5c754707b4
Author: Alex Bennée <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M tests/functional/test_x86_64_kvm_xen.py
Log Message:
-----------
tests: move test_kvm_xen to share.linaro.org
Linaro are migrating file-hosting from the old NextCloud instance to
another sharing site.
Reviewed-by: Thomas Huth <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
(cherry picked from commit 533b5ac2d6a826619cf80b009bf23ae3246d7011)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f44086c8114e86293e587f73ef1efb3eaf4c6312
https://github.com/qemu/qemu/commit/f44086c8114e86293e587f73ef1efb3eaf4c6312
Author: Alex Bennée <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M tests/functional/test_aarch64_virt_gpu.py
Log Message:
-----------
tests: move test_virt_gpu to share.linaro.org
Linaro are migrating file-hosting from the old NextCloud instance to
another sharing site.
Cc: [email protected]
Reviewed-by: Thomas Huth <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
(cherry picked from commit 497d3e87ce2d58a4781de03c6f5b0200ef79909f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 23f0865f1bffbf44dfad1ac599a0f737abc19c97
https://github.com/qemu/qemu/commit/23f0865f1bffbf44dfad1ac599a0f737abc19c97
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M block/rbd.c
Log Message:
-----------
rbd: Run co BH CB in the coroutine’s AioContext
qemu_rbd_completion_cb() schedules the request completion code
(qemu_rbd_finish_bh()) to run in the BDS’s AioContext, assuming that
this is the same thread in which qemu_rbd_start_co() runs.
To explain, this is how both latter functions interact:
In qemu_rbd_start_co():
while (!task.complete)
qemu_coroutine_yield();
In qemu_rbd_finish_bh():
task->complete = true;
aio_co_wake(task->co); // task->co is qemu_rbd_start_co()
For this interaction to work reliably, both must run in the same thread
so that qemu_rbd_finish_bh() can only run once the coroutine yields.
Otherwise, finish_bh() may run before start_co() checks task.complete,
which will result in the latter seeing .complete as true immediately and
skipping the yield altogether, even though finish_bh() still wakes it.
With multiqueue, the BDS’s AioContext is not necessarily the thread
start_co() runs in, and so finish_bh() may be scheduled to run in a
different thread than start_co(). With the right timing, this will
cause the problems described above; waking a non-yielding coroutine is
not good, as can be reproduced by putting e.g. a usleep(100000) above
the while loop in start_co() (and using multiqueue), giving finish_bh()
a much better chance at exiting before start_co() can yield.
So instead of scheduling finish_bh() in the BDS’s AioContext, schedule
finish_bh() in task->co’s AioContext.
In addition, we can get rid of task.complete altogether because we will
get woken exactly once, when the task is indeed complete, no need to
check.
(We could go further and drop the BH, running aio_co_wake() directly in
qemu_rbd_completion_cb() because we are allowed to do that even if the
coroutine isn’t yet yielding and we’re in a different thread – but the
doc comment on qemu_rbd_completion_cb() says to be careful, so I decided
not to go so far here.)
Buglink: https://issues.redhat.com/browse/RHEL-67115
Reported-by: Junyao Zhao <[email protected]>
Cc: [email protected]
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 89d22536d1a1715083ef8118fe7e6e9239f900c1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: aa2ec06680b1924980a177e98502494293e4e9d9
https://github.com/qemu/qemu/commit/aa2ec06680b1924980a177e98502494293e4e9d9
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M block/nfs.c
Log Message:
-----------
nfs: Run co BH CB in the coroutine’s AioContext
Like in “rbd: Run co BH CB in the coroutine’s AioContext”, drop the
completion flag, yield exactly once, and run the BH in the coroutine’s
AioContext.
(Can be reproduced with multiqueue by adding a usleep(100000) before the
`while (!task.complete)` loops.)
Like in “iscsi: Run co BH CB in the coroutine’s AioContext”, this makes
nfs_co_generic_bh_cb() trivial, so we can drop it in favor of just
calling aio_co_wake() directly.
Cc: [email protected]
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit deb35c129b859b9bec70fd42f856a0b7c1dc6e61)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 03778618b1952a0192f88286789a6f7e9adfa7bd
https://github.com/qemu/qemu/commit/03778618b1952a0192f88286789a6f7e9adfa7bd
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M block/curl.c
Log Message:
-----------
curl: Fix coroutine waking
If we wake a coroutine from a different context, we must ensure that it
will yield exactly once (now or later), awaiting that wake.
curl’s current .ret == -EINPROGRESS loop may lead to the coroutine not
yielding if the request finishes before the loop gets run. To fix it,
we must drop the loop and yield exactly once, if we need to yield.
Finding out that latter part ("if we need to yield") makes it a bit
complicated: Requests may be served from a cache internal to the curl
block driver, or fail before being submitted. In these cases, we must
not yield. However, if we find a matching but still ongoing request in
the cache, we will have to await that, i.e. still yield.
To address this, move the yield inside of the respective functions:
- Inside of curl_find_buf() when awaiting ongoing concurrent requests,
- Inside of curl_setup_preadv() when having created a new request.
Rename curl_setup_preadv() to curl_do_preadv() to reflect this.
(Can be reproduced with multiqueue by adding a usleep(100000) before the
`while (acb.ret == -EINPROGRESS)` loop.)
Also, add a comment why aio_co_wake() is safe regardless of whether the
coroutine and curl_multi_check_completion() run in the same context.
Cc: [email protected]
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 53d5c7ffac7bd4e0d12174432ebb2b3e88614b15)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ca02694bbc2b24b329608cc20820590e87cd6a78
https://github.com/qemu/qemu/commit/ca02694bbc2b24b329608cc20820590e87cd6a78
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M block/nvme.c
Log Message:
-----------
nvme: Kick and check completions in BDS context
nvme_process_completion() must run in the main BDS context, so schedule
a BH for requests that aren’t there.
The context in which we kick does not matter, but let’s just keep kick
and process_completion together for simplicity’s sake.
(For what it’s worth, a quick fio bandwidth test indicates that on my
test hardware, if anything, this may be a bit better than kicking
immediately before scheduling a pure nvme_process_completion() BH. But
I wouldn’t take more from those results than that it doesn’t really seem
to matter either way.)
Cc: [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 7a501bbd51941fb1867d78e6b0d1dc69e396b9e2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 361bd4a6c8ca57f48dd5a9e590d2c69a87e7dda1
https://github.com/qemu/qemu/commit/361bd4a6c8ca57f48dd5a9e590d2c69a87e7dda1
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M block/nvme.c
Log Message:
-----------
nvme: Fix coroutine waking
nvme wakes the request coroutine via qemu_coroutine_enter() from a BH
scheduled in the BDS AioContext. This may not be the same context as
the one in which the request originally ran, which would be wrong:
- It could mean we enter the coroutine before it yields,
- We would move the coroutine in to a different context.
(Can be reproduced with multiqueue by adding a usleep(100000) before the
`while (data.ret == -EINPROGRESS)` loop.)
To fix that, use aio_co_wake() to run the coroutine in its home context.
Just like in the preceding iscsi and nfs patches, we can drop the
trivial nvme_rw_cb_bh() and use aio_co_wake() directly.
With this, we can remove NVMeCoData.ctx.
Note the check of data->co == NULL to bypass the BH/yield combination in
case nvme_rw_cb() is called from nvme_submit_command(): We probably want
to keep this fast path for performance reasons, but we have to be quite
careful about it:
- We cannot overload .ret for this, but have to use a dedicated
.skip_yield field. Otherwise, if nvme_rw_cb() runs in a different
thread than the coroutine, it may see .ret set and skip the yield,
while nvme_rw_cb() will still schedule a BH for waking. Therefore,
the signal to skip the yield can only be set in nvme_rw_cb() if waking
too is skipped, which is independent from communicating the return
value.
- We can only skip the yield if nvme_rw_cb() actually runs in the
request coroutine. Otherwise (specifically if they run in different
AioContexts), the order between this function’s execution and the
coroutine yielding (or not yielding) is not reliable.
- There is no point to yielding in a loop; there are no spurious wakes,
so once we yield, we will only be re-entered once the command is done.
Replace `while` by `if`.
Cc: [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 0f142cbd919fcb6cea7aa176f7e4939925806dd9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: da9a175f362b8a89ac2f8786d88f32a234127ec3
https://github.com/qemu/qemu/commit/da9a175f362b8a89ac2f8786d88f32a234127ec3
Author: Hanna Czenczek <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M block/io.c
Log Message:
-----------
block/io: Take reqs_lock for tracked_requests
bdrv_co_get_self_request() does not take a lock around iterating through
bs->tracked_requests. With multiqueue, it may thus iterate over a list
that is in the process of being modified, producing an assertion
failure:
../block/file-posix.c:3702: raw_do_pwrite_zeroes: Assertion `req' failed.
[0] abort() at /lib64/libc.so.6
[1] __assert_fail_base.cold() at /lib64/libc.so.6
[2] raw_do_pwrite_zeroes() at ../block/file-posix.c:3702
[3] bdrv_co_do_pwrite_zeroes() at ../block/io.c:1910
[4] bdrv_aligned_pwritev() at ../block/io.c:2109
[5] bdrv_co_do_zero_pwritev() at ../block/io.c:2192
[6] bdrv_co_pwritev_part() at ../block/io.c:2292
[7] bdrv_co_pwritev() at ../block/io.c:2225
[8] handle_alloc_space() at ../block/qcow2.c:2573
[9] qcow2_co_pwritev_task() at ../block/qcow2.c:2625
Fix this by taking reqs_lock.
Cc: [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 9b9ee60c07f52009f9bb659f54c42afae95c1d94)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5dfc7d7cc6c8c09e1311299a86682de9163fa212
https://github.com/qemu/qemu/commit/5dfc7d7cc6c8c09e1311299a86682de9163fa212
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M tests/functional/qemu_test/asset.py
Log Message:
-----------
tests/functional: fix formatting of exception args
The catch-all exception handler forgot the placeholder for
the exception details.
Signed-off-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 124ab930ba38c41a86533dbfabb7a3b3b270ef98)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: abd554bafefcc75f560ea3b85502356e29327a22
https://github.com/qemu/qemu/commit/abd554bafefcc75f560ea3b85502356e29327a22
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M tests/functional/qemu_test/asset.py
Log Message:
-----------
tests/functional: handle URLError when fetching assets
We treat most HTTP errors as non-fatal when fetching assets,
but forgot to handle network level errors. This adds catching
of URLError so that we retry on failure, and will ultimately
trigger graceful skipping in the pre-cache task.
Signed-off-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 335da23abec85cd2f6d10f1fe36b28a02088e723)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3873acda9337b9db9e4844b751221c2caffeed1d
https://github.com/qemu/qemu/commit/3873acda9337b9db9e4844b751221c2caffeed1d
Author: Yannick Voßen <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M hw/dma/xlnx-zynq-devcfg.c
Log Message:
-----------
hw/dma/zynq-devcfg: Fix register memory
Registers are always 32 bit aligned. R_MAX is not the maximum
register address, it is the maximum register number. The memory
size can be determined by 4 * R_MAX.
Currently every register with an offset bigger than 0x40 will be
ignored, because the memory size is set wrong. This effects the
MCTRL register and makes it useless. This commit restores the
correct behaviour.
Cc: [email protected]
Fixes: 034c2e69023 ("dma: Add Xilinx Zynq devcfg device model")
Signed-off-by: YannickV <[email protected]>
Reviewed-by: Edgar E. Iglesias <[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 a344e22917f48d8cd876d72057bcfb938beb0630)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ec87d57a177699d049ec3fec08a0b5fc4f5590dc
https://github.com/qemu/qemu/commit/ec87d57a177699d049ec3fec08a0b5fc4f5590dc
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M include/hw/misc/lasi.h
Log Message:
-----------
hw/southbridge/lasi: Correct LasiState parent
TYPE_LASI_CHIP inherits from TYPE_SYS_BUS_DEVICE, not
TYPE_PCI_HOST_BRIDGE, so its parent structure is of
SysBusDevice type.
Cc: [email protected]
Fixes: 376b851909d ("hppa: Add support for LASI chip with i82596 NIC")
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Gustavo Romero <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 9c3b76a0d40671cbdf1f97c662311ec8bb517c76)
(Mjt: context fixup)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1a854ae15f32515f25352cc1ee5481ddeea3bb5c
https://github.com/qemu/qemu/commit/1a854ae15f32515f25352cc1ee5481ddeea3bb5c
Author: Peter Maydell <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M target/i386/tcg/decode-new.c.inc
Log Message:
-----------
target/i386: Mark VPERMILPS as not valid with prefix 0
There are a small set of binary SSE insns which have no MMX
equivalent, which we create the gen functions for with the
BINARY_INT_SSE() macro. This forwards to gen_binary_int_sse() with a
NULL pointer for 'mmx'.
For almost all of these insns we correctly mark them in the decode
table as not permitting a zero prefix byte; however we got this wrong
for VPERMILPS, with the result that a bogus instruction would get
through the decode checks and end up in gen_binary_int_sse() trying
to call a NULL pointer.
Correct the decode table entry for VPERMILPS so that we get the
expected #UD exception.
In the x86 SDM, table A-4 "Three-byte Opcode Map: 08H-FFH
(First Two Bytes are 0F 38H)" confirms that there is no pfx 0
version of VPERMILPS.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3199
Signed-off-by: Peter Maydell <[email protected]>
Link:
https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit ebd9ea2947d88f237e20333fe547ca8817d0b0ee)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fdda67ec29d8d5c4875e9e0a53ad79dd19767321
https://github.com/qemu/qemu/commit/fdda67ec29d8d5c4875e9e0a53ad79dd19767321
Author: Paolo Bonzini <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M target/i386/tcg/decode-new.c.inc
Log Message:
-----------
target/i386/tcg: validate segment registers
Correctly reject invalid segment registers, including CS when used as
the destination of a MOV. Ignore the REX prefix as well.
Fixes: 5e9e21bcc4d ("target/i386: move 60-BF opcodes to new decoder",
2024-05-07)
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3195
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit ebb46ba6a4a20d393a6889c21e8a80dabab4cc8e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9898237cf25ae02a21721905b81ae42d18c201c2
https://github.com/qemu/qemu/commit/9898237cf25ae02a21721905b81ae42d18c201c2
Author: Paolo Bonzini <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M target/i386/tcg/helper-tcg.h
M target/i386/tcg/system/svm_helper.c
Log Message:
-----------
target/i386: svm: fix sign extension of exit code
The exit_code parameter of cpu_vmexit is declared as uint32_t, but exit
codes are 64 bits wide according to the AMD SVM specification. And because
uint32_t is unsigned, this causes exit codes to be zero-extended, for example
writing SVM_EXIT_ERR as 0xffff_ffff instead of the expected
0xffff_ffff_ffff_ffff.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2977
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 9c3afb9d9b92d166d227b43d890c6a8ad33a928d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e3f70ada9095ad96d56dc300490433f8da588707
https://github.com/qemu/qemu/commit/e3f70ada9095ad96d56dc300490433f8da588707
Author: Paolo Bonzini <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M target/i386/tcg/seg_helper.c
Log Message:
-----------
target/i386: fix stack size when delivering real mode interrupts
The stack can be 32-bit even in real mode, and in this case
the stack pointer must be updated in its entirety rather than
just the bottom 16 bits. The same is true of real mode IRET,
for which there was even a comment suggesting the right thing
to do.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1506
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 106d766c9d5b549bc9780d2d2c519aa2bbebc89a)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/e098f79eb26b...e3f70ada9095
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
