Branch: refs/heads/staging-10.1
Home: https://github.com/qemu/qemu
Commit: 79222d2462de53fc86b359d431c08c8df2c61d19
https://github.com/qemu/qemu/commit/79222d2462de53fc86b359d431c08c8df2c61d19
Author: Richard Henderson <[email protected]>
Date: 2025-10-21 (Tue, 21 Oct 2025)
Changed paths:
M tcg/arm/tcg-target.c.inc
Log Message:
-----------
tcg/arm: Fix tgen_deposit
When converting from tcg_out_deposit, the arguments were not
shuffled properly.
Cc: [email protected]
Fixes: cf4905c03135f1181e8 ("tcg: Convert deposit to TCGOutOpDeposit")
Reported-by: Michael Tokarev <[email protected]>
Tested-by: Michael Tokarev <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 27ea28a0b369b4b14a485a5d6f045e0dc1db4e38)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e1cec1c47accd3bb74c0ba55029ea3d8553ab36e
https://github.com/qemu/qemu/commit/e1cec1c47accd3bb74c0ba55029ea3d8553ab36e
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: 8ba0034ddffd14b1ceddeb223199c17becf0a02f
https://github.com/qemu/qemu/commit/8ba0034ddffd14b1ceddeb223199c17becf0a02f
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: 395347bdf9f896e1d8cdeea5d77782585d03c9a1
https://github.com/qemu/qemu/commit/395347bdf9f896e1d8cdeea5d77782585d03c9a1
Author: John Levon <[email protected]>
Date: 2025-10-23 (Thu, 23 Oct 2025)
Changed paths:
M hw/core/sysbus-fdt.c
M hw/vfio-user/device.c
M hw/vfio/ccw.c
M hw/vfio/device.c
M hw/vfio/iommufd.c
M hw/vfio/pci.c
M hw/vfio/platform.c
M include/hw/vfio/vfio-device.h
Log Message:
-----------
vfio: rename field to "num_initial_regions"
We set VFIODevice::num_regions at initialization time, and do not
otherwise refresh it. As it is valid in theory for a VFIO device to
later increase the number of supported regions, rename the field to
"num_initial_regions" to better reflect its semantics.
Signed-off-by: John Levon <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Reviewed-by: Alex Williamson <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit aaca725884b57c9245528a0afb3f32e078543faf)
[ clg: Modified hw/core/sysbus-fdt.c and hw/vfio/platform.c ]
Signed-off-by: Cédric Le Goater <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e7f3e864cb2d380a33c34b523788402f7a4e4c02
https://github.com/qemu/qemu/commit/e7f3e864cb2d380a33c34b523788402f7a4e4c02
Author: John Levon <[email protected]>
Date: 2025-10-23 (Thu, 23 Oct 2025)
Changed paths:
M hw/vfio/device.c
Log Message:
-----------
vfio: only check region info cache for initial regions
It is semantically valid for a VFIO device to increase the number of
regions after initialization. In this case, we'd attempt to check for
cached region info past the size of the ->reginfo array. Check for the
region index and skip the cache in these cases.
This also works around some VGPU use cases which appear to be a bug,
where VFIO_DEVICE_QUERY_GFX_PLANE returns a region index beyond the
reported ->num_regions.
Fixes: 95cdb024 ("vfio: add region info cache")
Signed-off-by: John Levon <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Reviewed-by: Alex Williamson <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit ecbe424a63c9f860a901d6a4a75724b046abd796)
Signed-off-by: Cédric Le Goater <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
Commit: dbc57c91247dc93ff6fdedc022f41091f5c7ecb4
https://github.com/qemu/qemu/commit/dbc57c91247dc93ff6fdedc022f41091f5c7ecb4
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: 31aa4bd5bb690952fe98406f048e36db257f9e52
https://github.com/qemu/qemu/commit/31aa4bd5bb690952fe98406f048e36db257f9e52
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: ea55569b5979e55c1b55333b7a9ab3ee7eb42c19
https://github.com/qemu/qemu/commit/ea55569b5979e55c1b55333b7a9ab3ee7eb42c19
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: eeed470b25f95eeac5cc0ca08c4549968ed8cbae
https://github.com/qemu/qemu/commit/eeed470b25f95eeac5cc0ca08c4549968ed8cbae
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: 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: 9423689285b3d40f562a9e24b637001805304a18
https://github.com/qemu/qemu/commit/9423689285b3d40f562a9e24b637001805304a18
Author: Daniel Henrique Barboza <[email protected]>
Date: 2025-10-24 (Fri, 24 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: 2e49baf7ce52d6dac2dd60f623b87b9626afb548
https://github.com/qemu/qemu/commit/2e49baf7ce52d6dac2dd60f623b87b9626afb548
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: ee3321ec210ddf54ad17cf4d5a59438dfcc2cd4b
https://github.com/qemu/qemu/commit/ee3321ec210ddf54ad17cf4d5a59438dfcc2cd4b
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: a2b7a95350c23b484543001734e1f22be6fe87f8
https://github.com/qemu/qemu/commit/a2b7a95350c23b484543001734e1f22be6fe87f8
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: 174b99e8d55927f4fe82a2f2e9a0a849a8c8542b
https://github.com/qemu/qemu/commit/174b99e8d55927f4fe82a2f2e9a0a849a8c8542b
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: dfd597681092ba72c2c050cd0aa1d80a87822804
https://github.com/qemu/qemu/commit/dfd597681092ba72c2c050cd0aa1d80a87822804
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: a0c14a76f3461d4bd4d4ab6181342bd189398d39
https://github.com/qemu/qemu/commit/a0c14a76f3461d4bd4d4ab6181342bd189398d39
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")
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: 072470dfae125f5622e2250ebd1daf626d4023b7
https://github.com/qemu/qemu/commit/072470dfae125f5622e2250ebd1daf626d4023b7
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: 99b53ecaf8aa721e83d74654e2c9204ac6d62b05
https://github.com/qemu/qemu/commit/99b53ecaf8aa721e83d74654e2c9204ac6d62b05
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: ba2887244cee624060daf44c250ef32c2883de48
https://github.com/qemu/qemu/commit/ba2887244cee624060daf44c250ef32c2883de48
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: dd26885484a306de656427c429dcb2e963a95330
https://github.com/qemu/qemu/commit/dd26885484a306de656427c429dcb2e963a95330
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: 34b92fa32d7cc695fc96ed367e27f08fbfbd301f
https://github.com/qemu/qemu/commit/34b92fa32d7cc695fc96ed367e27f08fbfbd301f
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: 98107c5d4c1c0a16f1a02a5efbfe01b567215cc6
https://github.com/qemu/qemu/commit/98107c5d4c1c0a16f1a02a5efbfe01b567215cc6
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: cf8dff8d9f9 ("i386/cpu: Prevent delivering SIPI during SMM in TCG mode",
in 10.1.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: 70c66701f3915d009d66a223c98914e34a093a61
https://github.com/qemu/qemu/commit/70c66701f3915d009d66a223c98914e34a093a61
Author: peng guo <[email protected]>
Date: 2025-10-31 (Fri, 31 Oct 2025)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
hw/i386/pc: Avoid overlap between CXL window and PCI 64bit BARs in QEMU
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.
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" \
-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]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit d1193481dee63442fc41e47ca6ebc4cd34f1f69c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 18d5f261d864343f1930263a6812d3fb182e6907
https://github.com/qemu/qemu/commit/18d5f261d864343f1930263a6812d3fb182e6907
Author: Xiaoyao Li <[email protected]>
Date: 2025-10-31 (Fri, 31 Oct 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: 6130ab24d03e ("i386/cpu: Enable SMM cpu address space under KVM"), 10.1.1
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4523ad243808c236bfaf27823808c5d8ee52dff8
https://github.com/qemu/qemu/commit/4523ad243808c236bfaf27823808c5d8ee52dff8
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-10-31 (Fri, 31 Oct 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: f6d90041d6b91f1b644af9da48c726d4e586e561
https://github.com/qemu/qemu/commit/f6d90041d6b91f1b644af9da48c726d4e586e561
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-10-31 (Fri, 31 Oct 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: 45d9db94f4341608ba3248b76dc078081719e483
https://github.com/qemu/qemu/commit/45d9db94f4341608ba3248b76dc078081719e483
Author: Richard W.M. Jones <[email protected]>
Date: 2025-10-31 (Fri, 31 Oct 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: a8db605f8f5dffdd3b71215586b1844f0d4b7127
https://github.com/qemu/qemu/commit/a8db605f8f5dffdd3b71215586b1844f0d4b7127
Author: Sean Anderson <[email protected]>
Date: 2025-10-31 (Fri, 31 Oct 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: 5ec7135676d49adc3511ab80b4fc15ff18192f34
https://github.com/qemu/qemu/commit/5ec7135676d49adc3511ab80b4fc15ff18192f34
Author: Edgar E. Iglesias <[email protected]>
Date: 2025-11-01 (Sat, 01 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: d428a048c0733e65416722233e2926fb8196bda8
https://github.com/qemu/qemu/commit/d428a048c0733e65416722233e2926fb8196bda8
Author: Edgar E. Iglesias <[email protected]>
Date: 2025-11-01 (Sat, 01 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: b6fd8fa68d4308de6d5a77b85320351d60d81876
https://github.com/qemu/qemu/commit/b6fd8fa68d4308de6d5a77b85320351d60d81876
Author: Edgar E. Iglesias <[email protected]>
Date: 2025-11-01 (Sat, 01 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: dd1df0fa0cfe90201d451eb9d89403b221afe02f
https://github.com/qemu/qemu/commit/dd1df0fa0cfe90201d451eb9d89403b221afe02f
Author: Ilya Leoshkevich <[email protected]>
Date: 2025-11-04 (Tue, 04 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: c35275c2edd079d3653dab7613232fb775d0aafa
https://github.com/qemu/qemu/commit/c35275c2edd079d3653dab7613232fb775d0aafa
Author: Ilya Leoshkevich <[email protected]>
Date: 2025-11-04 (Tue, 04 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: 7f3f07014e535548f204687cd1b66c17aa311dae
https://github.com/qemu/qemu/commit/7f3f07014e535548f204687cd1b66c17aa311dae
Author: Ilya Leoshkevich <[email protected]>
Date: 2025-11-04 (Tue, 04 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: 22eb797a458926f0512373df6356956588f8e9f0
https://github.com/qemu/qemu/commit/22eb797a458926f0512373df6356956588f8e9f0
Author: Ilya Leoshkevich <[email protected]>
Date: 2025-11-04 (Tue, 04 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: 1e9f5deccd9c2dead3e9f2087a84c56a188d668d
https://github.com/qemu/qemu/commit/1e9f5deccd9c2dead3e9f2087a84c56a188d668d
Author: Chenyi Qiang <[email protected]>
Date: 2025-11-05 (Wed, 05 Nov 2025)
Changed paths:
M system/ram-block-attributes.c
Log Message:
-----------
ram-block-attributes: fix interaction with hugetlb memory backends
Currently, CoCo VMs can perform conversion at the base page granularity,
which is the granularity that has to be tracked. In relevant setups, the
target page size is assumed to be equal to the host page size, thus
fixing the block size to the host page size.
However, since private memory and shared memory have different backend
at present, users can specify shared memory with a hugetlbfs backend
while private memory with guest_memfd backend only supports 4K page
size. In this scenario, ram_block->page_size is different from the host
page size which will trigger an assertion when retrieving the block
size.
To address this, return the host page size directly to relax the
restriction. This changes fixes a regression of using hugetlbfs backend
for shared memory within CoCo VMs, with or without VFIO devices' presence.
Acked-by: David Hildenbrand <[email protected]>
Tested-by: Farrah Chen <[email protected]>
Signed-off-by: Chenyi Qiang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[peterx: fix subject, per david]
Cc: qemu-stable <[email protected]>
Signed-off-by: Peter Xu <[email protected]>
(cherry picked from commit 8922a758b29251d9009ec509e7f580b76509ab3d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9f26d3a36994b0f11fccae6b59fc6164d28e5df0
https://github.com/qemu/qemu/commit/9f26d3a36994b0f11fccae6b59fc6164d28e5df0
Author: Xiaoyao Li <[email protected]>
Date: 2025-11-05 (Wed, 05 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: a3c1fc35008f938d2904a0df23692a48e9cc059a
https://github.com/qemu/qemu/commit/a3c1fc35008f938d2904a0df23692a48e9cc059a
Author: Peter Maydell <[email protected]>
Date: 2025-11-10 (Mon, 10 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: 5b463530add462da8cca8548d46eea8bf70a7c28
https://github.com/qemu/qemu/commit/5b463530add462da8cca8548d46eea8bf70a7c28
Author: Albert Esteve <[email protected]>
Date: 2025-11-10 (Mon, 10 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: 9a51f0cf9dd9e119d2f7b6c937d2b576ac313f33
https://github.com/qemu/qemu/commit/9a51f0cf9dd9e119d2f7b6c937d2b576ac313f33
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: 90f5f434bfc834c03a417f43179a2f7674770c13
https://github.com/qemu/qemu/commit/90f5f434bfc834c03a417f43179a2f7674770c13
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: b294ca85b8d1c59c9e39fdc7aa399d1c88793249
https://github.com/qemu/qemu/commit/b294ca85b8d1c59c9e39fdc7aa399d1c88793249
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.acpipcihp
M tests/data/acpi/aarch64/virt/DSDT.hpoffacpiindex
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/aarch64/virt/DSDT.viot
M tests/data/acpi/loongarch64/virt/DSDT
M tests/data/acpi/loongarch64/virt/DSDT.memhp
M tests/data/acpi/loongarch64/virt/DSDT.numamem
M tests/data/acpi/loongarch64/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)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9ea383331531e6d481050e3fc9daa4f46d64e015
https://github.com/qemu/qemu/commit/9ea383331531e6d481050e3fc9daa4f46d64e015
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: fcffa892ea09612c485f85af8ab214ea83dbdbbf
https://github.com/qemu/qemu/commit/fcffa892ea09612c485f85af8ab214ea83dbdbbf
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: 9d45af9d1c2f3b002b0c06663da522c792af44c3
https://github.com/qemu/qemu/commit/9d45af9d1c2f3b002b0c06663da522c792af44c3
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: 26b17e34bedb ("qemu-img rebase: don't exceed IO_BUF_SIZE in one
operation") in 10.1.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: 0710635a01dec501ae87ce8e0d5bb218ea9daa3f
https://github.com/qemu/qemu/commit/0710635a01dec501ae87ce8e0d5bb218ea9daa3f
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: 6b716806e8e6d290b01aad7e1f1985bab89f6055
https://github.com/qemu/qemu/commit/6b716806e8e6d290b01aad7e1f1985bab89f6055
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: e07535caac1c0aeb9f323c8abb3572bf84a2bd58
https://github.com/qemu/qemu/commit/e07535caac1c0aeb9f323c8abb3572bf84a2bd58
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: 63b23ad20c3a12db27f22e9e2f068229d6747197
https://github.com/qemu/qemu/commit/63b23ad20c3a12db27f22e9e2f068229d6747197
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: cbef0fa9bdd188d668e1a71a4608fbb05669212d
https://github.com/qemu/qemu/commit/cbef0fa9bdd188d668e1a71a4608fbb05669212d
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: 26ec74ff6791e149b455a6dbd418fc7fdb0de542
https://github.com/qemu/qemu/commit/26ec74ff6791e149b455a6dbd418fc7fdb0de542
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: 6642c402f557eed9575a0da10e7a349fc4118571
https://github.com/qemu/qemu/commit/6642c402f557eed9575a0da10e7a349fc4118571
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: 467397ea3051dcdf40fc5b3f6005ed5538937b01
https://github.com/qemu/qemu/commit/467397ea3051dcdf40fc5b3f6005ed5538937b01
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: d68f54e1a721a52430281b397d261c52d72f28a4
https://github.com/qemu/qemu/commit/d68f54e1a721a52430281b397d261c52d72f28a4
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: efe30a21c790a2b05a47f57646bd6d74543dec68
https://github.com/qemu/qemu/commit/efe30a21c790a2b05a47f57646bd6d74543dec68
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: f9c2b17c74a10a45df8488698668cb26d16db4ce
https://github.com/qemu/qemu/commit/f9c2b17c74a10a45df8488698668cb26d16db4ce
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: ac6b86eaa55d7a95b14b0a73f8c85d42e7445429
https://github.com/qemu/qemu/commit/ac6b86eaa55d7a95b14b0a73f8c85d42e7445429
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: 9cac0db512897ed0e3f91ce24a6d0a544a58bfb9
https://github.com/qemu/qemu/commit/9cac0db512897ed0e3f91ce24a6d0a544a58bfb9
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: 75471c8772962cef15139705605e7e15eab14c31
https://github.com/qemu/qemu/commit/75471c8772962cef15139705605e7e15eab14c31
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: d54fb6d54d73ec9ad9552f4ef96653d8e6f24ee4
https://github.com/qemu/qemu/commit/d54fb6d54d73ec9ad9552f4ef96653d8e6f24ee4
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: 0633dcb9579ef701724afa9060870a7ed6ec47fe
https://github.com/qemu/qemu/commit/0633dcb9579ef701724afa9060870a7ed6ec47fe
Author: Alex Bennée <[email protected]>
Date: 2025-11-21 (Fri, 21 Nov 2025)
Changed paths:
M tests/functional/test_aarch64_kvm.py
Log Message:
-----------
tests: move test_kvm 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 ced9f2ffc20dd182b2504fb08391a796c65bb0af)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9dbc842e9ab0790df34ed5111785b713a18daaad
https://github.com/qemu/qemu/commit/9dbc842e9ab0790df34ed5111785b713a18daaad
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: e8e9ed8b1127a39c95eba77d7410a0076dbd761c
https://github.com/qemu/qemu/commit/e8e9ed8b1127a39c95eba77d7410a0076dbd761c
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: f9d1e16005d3a59f3dc920b603840b791dfb3cc3
https://github.com/qemu/qemu/commit/f9d1e16005d3a59f3dc920b603840b791dfb3cc3
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: 80808526162fe6f71a075a9b2a2ec11c4953e46c
https://github.com/qemu/qemu/commit/80808526162fe6f71a075a9b2a2ec11c4953e46c
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: 9bcfcb5b95cb92826ab7052255f75f25b50ceedf
https://github.com/qemu/qemu/commit/9bcfcb5b95cb92826ab7052255f75f25b50ceedf
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: 619c2350fae574af67d371f68f701692d9b8487a
https://github.com/qemu/qemu/commit/619c2350fae574af67d371f68f701692d9b8487a
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: 80d0d15157bd66d2971c6eaf0e0d4610763d836d
https://github.com/qemu/qemu/commit/80d0d15157bd66d2971c6eaf0e0d4610763d836d
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: 3e342e42d8987f48888753e3422b2c67d8c4616c
https://github.com/qemu/qemu/commit/3e342e42d8987f48888753e3422b2c67d8c4616c
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: 3362add5dabc0052fff2b849418939fb679cc254
https://github.com/qemu/qemu/commit/3362add5dabc0052fff2b849418939fb679cc254
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: 64f5d4ad31c3d6f3f8159947adc61e3ae276a8a9
https://github.com/qemu/qemu/commit/64f5d4ad31c3d6f3f8159947adc61e3ae276a8a9
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: 4e9b8960008fe13aab26e3a8e3a91bf110038724
https://github.com/qemu/qemu/commit/4e9b8960008fe13aab26e3a8e3a91bf110038724
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)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 61a2fd40273379cfe387e3dda04eaee56628f9f3
https://github.com/qemu/qemu/commit/61a2fd40273379cfe387e3dda04eaee56628f9f3
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: 49540ef6360bf7c619ca6db6a1746e56cda80197
https://github.com/qemu/qemu/commit/49540ef6360bf7c619ca6db6a1746e56cda80197
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: bb9a9bac9e0ce3062e2e0e22a1766b2959ec2175
https://github.com/qemu/qemu/commit/bb9a9bac9e0ce3062e2e0e22a1766b2959ec2175
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: d16a8a8e7019b494c444ad8f44248b9d22aabdbe
https://github.com/qemu/qemu/commit/d16a8a8e7019b494c444ad8f44248b9d22aabdbe
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/ccaea6b2656e...d16a8a8e7019
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
