Dmitry Osipenko [Wed, 4 Mar 2026 16:50:33 +0000 (16:50 +0000)]
virtio-gpu: Support asynchronous fencing
Support asynchronous fencing feature of virglrenderer. It allows Qemu to
handle fence as soon as it's signalled instead of periodically polling
the fence status. This feature is required for enabling DRM context
support in Qemu because legacy fencing mode isn't supported for DRM
contexts in virglrenderer.
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Yiwei Zhang <zzyiwei@gmail.com> Tested-by: Yiwei Zhang <zzyiwei@gmail.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Message-ID: <20260303151422.977399-10-dmitry.osipenko@collabora.com>
Message-ID: <20260304165043.1437519-12-alex.bennee@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Dmitry Osipenko [Wed, 4 Mar 2026 16:50:31 +0000 (16:50 +0000)]
virtio-gpu: Ensure BHs are invoked only from main-loop thread
QEMU's display GL core is tied to main-loop thread and virtio-gpu
interacts with display while processing GPU commands. Virtio-gpu BHs
work in generic AIO context that can be invoked on vCPU thread, while
GL and UI toolkits are bound to the main-loop thread.
Make virtio-gpu BHs use iohandler AIO context that is handled in a
main-loop thread only.
Dmitry Osipenko [Wed, 4 Mar 2026 16:50:29 +0000 (16:50 +0000)]
ui/sdl2: Restore original context after new context creation
SDL API changes GL context to a newly created GL context, which differs
from other GL providers that don't switch context. Change SDL backend to
restore the original GL context. This allows Qemu's virtio-gpu to support
new virglrenderer async-fencing feature for Virgl contexts, otherwise
virglrenderer's vrend creates a fence-sync context on the Qemu's
main-loop thread that erroneously stays in-use by the main-loop after
creation, not allowing vrend's fence-sync thread switch to this new
context that belongs to it.
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Yiwei Zhang <zzyiwei@gmail.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Message-ID: <20260303151422.977399-6-dmitry.osipenko@collabora.com>
Message-ID: <20260304165043.1437519-8-alex.bennee@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Dmitry Osipenko [Wed, 4 Mar 2026 16:50:28 +0000 (16:50 +0000)]
ui/gdk: Restore original context after new context creation
Get currently bound GL context when creating new GL context and restore
it after the creation for consistency with behavior expected by virglrenderer
that assumes context-creation doesn't switch context.
Dmitry Osipenko [Wed, 4 Mar 2026 16:50:27 +0000 (16:50 +0000)]
ui/egl: Don't change bound GL context when creating new context
Don't change bound GL context when creating new GL context for consistency
with behavior expected by virglrenderer that assumes context-creation doesn't
switch context. eglCreateContext() doesn't require GL context to be bound
when it's invoked. Update qemu_egl_create_context() to spawn GL sub-contexts
from a given shared GL context instead of a currently-bound context.
Dmitry Osipenko [Wed, 4 Mar 2026 16:50:26 +0000 (16:50 +0000)]
ui/sdl2: Don't disable scanout when display is refreshed
Display refreshment is invoked by a timer and it erroneously disables
the active scanout if it happens to be invoked after scanout has been
enabled. This offending scanout-disable race condition with a timer
can be easily hit when Qemu runs with a disabled vsync by using SDL or
GTK displays (with vblank_mode=0 for GTK). Refreshment of display's
content shouldn't disable the active display. Fix it by keeping the
scanout's state unchanged when display is redrawn.
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Yiwei Zhang <zzyiwei@gmail.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Message-ID: <20260303151422.977399-3-dmitry.osipenko@collabora.com>
Message-ID: <20260304165043.1437519-5-alex.bennee@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Dmitry Osipenko [Wed, 4 Mar 2026 16:50:25 +0000 (16:50 +0000)]
ui/gtk: Don't disable scanout when display is refreshed
Display refreshment is invoked by a timer and it erroneously disables
the active scanout if it happens to be invoked after scanout has been
enabled. This offending scanout-disable race condition with a timer
can be easily hit when Qemu runs with a disabled vsync by using SDL or
GTK displays (with vblank_mode=0 for GTK). Refreshment of display's
content shouldn't disable the active display. Fix it by keeping the
scanout's state unchanged when display is redrawn.
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Yiwei Zhang <zzyiwei@gmail.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Message-ID: <20260303151422.977399-2-dmitry.osipenko@collabora.com>
Message-ID: <20260304165043.1437519-4-alex.bennee@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Dongwon Kim [Wed, 4 Mar 2026 20:32:30 +0000 (12:32 -0800)]
virtio-gpu: Fix scanout dmabuf cleanup during resource destruction
When a virtio-gpu resource is destroyed, any associated udmabuf must be
properly torn down. Currently, the code may leave dangling references
to dmabuf file descriptors in the scanout primary buffers.
This patch updates virtio_gpu_fini_udmabuf to:
1. Iterate through all active scanouts.
2. Identify dmabufs that match the resource's file descriptor.
3. Close the dmabuf and invalidate the resource's FD reference to
prevent use-after-free or double-close scenarios.
4. Finally, trigger the underlying udmabuf destruction.
This ensures that the display backend does not attempt to access
memory or FDs that have been released by the guest or the host.
Cc: Alex Bennée <alex.bennee@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
Message-ID: <20260304203230.1955266-1-dongwon.kim@intel.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Andrew Keesler [Wed, 4 Mar 2026 16:50:23 +0000 (16:50 +0000)]
Support per-head resolutions with virtio-gpu
In 454f4b0f, we started down the path of supporting separate
configurations per display head (e.g., you have 2 heads - one with
EDID name "AAA" and the other with EDID name "BBB").
In this change, we add resolution to this configuration surface (e.g.,
you have 2 heads - one with resolution 111x222 and the other with
resolution 333x444).
Here is the behavior matrix of the current resolution configuration
surface (xres/yres) with the new resolution configuration surface
(outputs[i].xres/yres).
Note - we use "xres" and "yres" (instead of, say, "width" and "height")
to match analogous virtio_gpu_base_conf.xres/yres.
Case: !(xres || yres) && !(outputs[i].has_xres && outputs[i].has_yres)
Behavior: current behavior - outputs[0] enabled with default xres/yres
Case: (xres || yres) && !(outputs[i].has_xres && outputs[i].has_yres)
Behavior: current behavior - outputs[0] enabled with xres/yres
Case: outputs[i].has_xres && outputs[i].has_yres
Behavior: new behavior - outputs[i] enabled with outputs[i].xres/yres
Signed-off-by: Andrew Keesler <ankeesler@google.com> Acked-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260210123038.2332364-2-ankeesler@google.com>
[AJB: fix format strings for size_t in error_setg]
Message-ID: <20260304165043.1437519-2-alex.bennee@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Hanna Czenczek [Fri, 30 May 2025 08:44:47 +0000 (10:44 +0200)]
iotests/244: Add test cases for keep_data_file
Add various test cases around keep_data_file to the existing data_file
test suite 244.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20250530084448.192369-5-hreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
[kwolf: Added prealloc=full to the test] Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Hanna Czenczek [Fri, 30 May 2025 08:44:46 +0000 (10:44 +0200)]
iotests/common.filter: Sort keep_data_file
Sort the new keep_data_file creation option together with data_file and
data_file_raw.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20250530084448.192369-4-hreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Hanna Czenczek [Fri, 30 May 2025 08:44:45 +0000 (10:44 +0200)]
qcow2: Simplify size round-up in co_create_opts
Use the now-existing qcow2_opts pointer to simplify the size rounding up
code.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20250530084448.192369-3-hreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Hanna Czenczek [Fri, 30 May 2025 08:44:44 +0000 (10:44 +0200)]
qcow2: Add keep_data_file command-line option
Add a command-line-only option to prevent overwriting the file specified
as external data file.
This option is only available on the qemu-img create command line, not
via blockdev-create, as it makes no sense there: That interface
separates file creation and formatting, so where the external data file
attached to a newly formatted qcow2 node comes from is completely up to
the user.
Implementation detail: Enabling this option will not only not overwrite
the external data file, but also assume it already exists, for two
reasons:
- It is simpler than checking whether the file exists, and only skipping
creating it when it does not. It is therefore also less error-prone,
i.e. we can never accidentally overwrite an existing file because we
made some mistake in checking whether it exists.
- I think it makes sense from a user's perspective: You set this option
when you want to use an existing data file, and you unset it when you
want a new one. Getting an error when you expect to use an existing
data file seems to me a nice warning that something is not right.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20250530084448.192369-2-hreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
[kwolf: Removed redundant has_data_file_raw check] Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Hanna Czenczek [Fri, 2 Jan 2026 15:32:46 +0000 (16:32 +0100)]
block/nfs: Do not enter coroutine from CB
The reasoning I gave for why it would be safe to call aio_co_wake()
despite holding the mutex was wrong: It is true that the current request
will not re-acquire the mutex, but a subsequent request in the same
coroutine can. Because the mutex is a non-coroutine mutex, this will
result in a deadlock.
Therefore, we must either not enter the coroutine here (only scheduling
it), or release the mutex around aio_co_wake(). I opt for the former,
as it is the behavior prior to the offending commit, and so seems safe
to do.
Fixes: deb35c129b859b9bec70fd42f856a0b7c1dc6e61
("nfs: Run co BH CB in the coroutine’s AioContext") Buglink: https://gitlab.com/qemu-project/qemu/-/issues/2622#note_2965097035 Cc: qemu-stable@nongnu.org Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20260102153246.154207-1-hreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Kevin Wolf [Wed, 4 Mar 2026 12:28:00 +0000 (13:28 +0100)]
block: Never drop BLOCK_IO_ERROR with action=stop for rate limiting
Commit 2155d2dd introduced rate limiting for BLOCK_IO_ERROR to emit an
event only once a second. This makes sense for cases in which the guest
keeps running and can submit more requests that would possibly also fail
because there is a problem with the backend.
However, if the error policy is configured so that the VM is stopped on
errors, this is both unnecessary because stopping the VM means that the
guest can't issue more requests and in fact harmful because stopping the
VM is an important state change that management tools need to keep track
of even if it happens more than once in a given second. If an event is
dropped, the management tool would see a VM randomly going to paused
state without an associated error, so it has a hard time deciding how to
handle the situation.
This patch disables rate limiting for action=stop by not relying on the
event type alone any more in monitor_qapi_event_queue_no_reenter(), but
checking action for BLOCK_IO_ERROR, too. If the error is reported to the
guest or ignored, the rate limiting stays in place.
Fixes: 2155d2dd7f73 ('block-backend: per-device throttling of BLOCK_IO_ERROR reports') Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20260304122800.51923-1-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The function schedule_next_request is called with tg->lock held and
it may call throttle_group_co_restart_queue, which takes
tgm->throttled_reqs_lock, qemu_co_mutex_lock may leave current
coroutine if other iothread has taken the lock. If the next
coroutine will call throttle_group_co_io_limits_intercept - it
will try to take the mutex tg->lock which will never be released.
Here is the backtrace of the iothread:
Thread 30 (Thread 0x7f8aad1fd6c0 (LWP 24240) "IO iothread2"):
#0 futex_wait (futex_word=0x5611adb7d828, expected=2, private=0) at ../sysdeps/nptl/futex-internal.h:146
#1 __GI___lll_lock_wait (futex=futex@entry=0x5611adb7d828, private=0) at lowlevellock.c:49
#2 0x00007f8ab5a97501 in lll_mutex_lock_optimized (mutex=0x5611adb7d828) at pthread_mutex_lock.c:48
#3 ___pthread_mutex_lock (mutex=0x5611adb7d828) at pthread_mutex_lock.c:93
#4 0x00005611823f5482 in qemu_mutex_lock_impl (mutex=0x5611adb7d828, file=0x56118289daca "../block/throttle-groups.c", line=372) at ../util/qemu-thread-posix.c:94
#5 0x00005611822b0b39 in throttle_group_co_io_limits_intercept (tgm=0x5611af1bb4d8, bytes=4096, direction=THROTTLE_READ) at ../block/throttle-groups.c:372
#6 0x00005611822473b1 in blk_co_do_preadv_part (blk=0x5611af1bb490, offset=15972311040, bytes=4096, qiov=0x7f8aa4000f98, qiov_offset=0, flags=BDRV_REQ_REGISTERED_BUF) at ../block/block-backend.c:1354
#7 0x0000561182247fa0 in blk_aio_read_entry (opaque=0x7f8aa4005910) at ../block/block-backend.c:1619
#8 0x000056118241952e in coroutine_trampoline (i0=-1543497424, i1=32650) at ../util/coroutine-ucontext.c:175
#9 0x00007f8ab5a56f70 in ?? () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:66 from target:/lib64/libc.so.6
#10 0x00007f8aad1ef190 in ?? ()
#11 0x0000000000000000 in ?? ()
The lock is taken in line 386:
(gdb) p tg.lock
$1 = {lock = {__data = {__lock = 2, __count = 0, __owner = 24240, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},
__size = "\002\000\000\000\000\000\000\000\260^\000\000\001", '\000' <repeats 26 times>, __align = 2}, file = 0x56118289daca "../block/throttle-groups.c",
line = 386, initialized = true}
The solution is to use tg->lock to protect both ThreadGroup fields and
ThrottleGroupMember.throttled_reqs. It doesn't seem to be possible
to use separate locks because we need to first manipulate ThrottleGroup
fields, then schedule next coroutine using throttled_reqs and after than
update token field from ThrottleGroup depending on the throttled_reqs
state.
Signed-off-by: Dmitry Guryanov <dmitry.guryanov@gmail.com>
Message-ID: <20251208085528.890098-1-dmitry.guryanov@gmail.com> Reviewed-by: Hanna Czenczek <hreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Peter Maydell [Fri, 6 Mar 2026 15:58:24 +0000 (15:58 +0000)]
Merge tag 'pull-target-arm-20260306-2' of https://gitlab.com/pm215/qemu into staging
* Remove deprecated 'highbank' and 'midway' machines
* hw/arm: Add missing dependencies for STM32F405 SoC
* hw/arm/smmuv3-accel: Read and propagate host vIOMMU events
* Minor MAINTAINERS updates
* target/arm: Improve logging of migration errors due to system
register mismatches between source and destination
* hw/arm/aspeed_gpio: Don't leak string in aspeed_gpio_init()
* tests/qtest/iommu-smmuv3-test: Free QPCIDevice
* chardev: Fix various sanitizer detected leaks
* tests/qtest/test-x86-cpuid-compat: Free allocated memory
* tests/qtest/qos-test: Plug a couple of leaks
* hw/arm/smmuv3: Fix various minor bugs
* hvf/arm: expose FEAT_SME2 to guest if available
* hvf/arm: drop unneeded includes
* tag 'pull-target-arm-20260306-2' of https://gitlab.com/pm215/qemu: (36 commits)
hvf: hvf-all: stop including hvf_arm.h
hw/arm: virt: remove hvf_arm.h include
hvf/arm: expose FEAT_SME2 to guest if available
hvf/arm: handle FEAT_SME2 migration
hw/arm/smmuv3: Fix CFGI_CD handling when stage-1 is unsupported
hw/arm/smmuv3: Correct SMMUEN field name in CR0
hw/arm/smmuv3-common: Fix incorrect reserved mask for SMMU CR0 register
tests/qtest/qos-test: Plug a couple of leaks
tests/qtest/test-x86-cpuid-compat: Free allocated memory
chardev: Consolidate yank registration
chardev: Don't attempt to unregister yank function more than once
chardev: Fix QIOChannel refcount
tests/qtest/iommu-smmuv3-test: Free QPCIDevice
hw/arm/aspeed_gpio: Don't leak string in aspeed_gpio_init()
scripts/lsan_suppressions.txt: Add more leaks
scripts: Move lsan_suppressions.txt out of oss-fuzz subdir
target/arm/machine: Fix detection of unknown incoming cpregs
target/arm/machine: Trace all register mismatches
target/arm/machine: Trace cpreg names which do not match on migration
target/arm/kvm: Tweak print_register_name() for arm64 system register
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
SME2 support adds the following state for HVF guests:
- Vector registers Z0, ... , Z31 (introduced by FEAT_SVE but HVF does
not support it)
- Predicate registers P0, .., P15 (also FEAT_SVE)
- ZA register
- ZT0 register
- PSTATE.{SM,ZA} bits (SVCR pseudo-register)
- SMPRI_EL1 which handles the PE's priority in the SMCU
- TPIDR2_EL0 the thread local ID register for SME
Peter Maydell [Fri, 6 Mar 2026 12:55:47 +0000 (12:55 +0000)]
Merge tag 'pr-hw_virtio_single_binary-20260305' of https://gitlab.com/pbo-linaro/qemu into staging
Changes:
- [PATCH v2 0/6] hw/virtio/virtio-access.h: remove target specific code (=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>) Link: https://lore.kernel.org/qemu-devel/20260225041948.52929-1-philmd@linaro.org
# -----BEGIN PGP SIGNATURE-----
#
# iQGzBAABCgAdFiEEZrmU7KFPfy5auggff5BUDQoc0A8FAmmp8GkACgkQf5BUDQoc
# 0A/elwv+JgnJ1yLXP2ZTCB59tGT0TJuvTVf//h13YIxbeGdvfcoTLocCRyGix7pu
# rMbT5gaKBypF/BEqmeF5ST3dRTQ6h4P79eF4e3LILFhgs41kNltgLl6yXx9m1jtg
# g+b3bDX2Jlb9Qhvud72+pfGGUsIcQB68XBpkz9BS+R9Qy/kylvMAtr8MgUHFiwnU
# 5lq1W99DBZZ1kzR9H1jrJGge7s/OcDTA8/Lb6Qje3SYw3HR6yzWL4OXiDNh/UilV
# p4hVXGbDPDrpM7GUVPfU/A5vwVedeXnXdPsXxFqunvbKcCgiuLX8YMNikmBGqyL/
# VrRhQPKvd13o9uVLQH3hVKQA73A0xcyK/NvZVRQh9RoqGbHZKgaAAHl5way8w6ch
# /XPHhBzFxLYlnCGulDczio0vxHX7baxP6eOjD8vyb5v5DU0eoW1hoeQL5s0MPOKK
# ggd1XvJaygcYmxPPqQyg9OgTBxyFSMVd4oQvpo73+kYOvBYTMbspKNxgGegpErra
# fxOkl2Ue
# =EQ+o
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu Mar 5 21:06:49 2026 GMT
# gpg: using RSA key 66B994ECA14F7F2E5ABA081F7F90540D0A1CD00F
# gpg: Good signature from "Pierrick Bouvier <pierrick.bouvier@linaro.org>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 66B9 94EC A14F 7F2E 5ABA 081F 7F90 540D 0A1C D00F
* tag 'pr-hw_virtio_single_binary-20260305' of https://gitlab.com/pbo-linaro/qemu:
hw/virtio/: make all compilation units common
hw/virtio/virtio-qmp: make compilation unit common
hw/virtio/vhost-user: make compilation unit common
hw/virtio: Inline virtio_access_is_big_endian()
hw/virtio: Simplify virtio_access_is_big_endian()
hw/virtio: Add virtio_vdev_is_legacy()
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Fri, 6 Mar 2026 12:55:16 +0000 (12:55 +0000)]
Merge tag 'pr-plugins-20260305' of https://gitlab.com/pbo-linaro/qemu into staging
Changes:
- [PATCH v7 0/8] Enable PC diversion via the plugin API (Florian Hofhammer <florian.hofhammer@epfl.ch>) Link: https://lore.kernel.org/qemu-devel/20260305-setpc-v5-v7-0-4c3adba52403@epfl.ch
- [PATCH trivial] plugins: add missing callbacks to version history (Florian Hofhammer <florian.hofhammer@epfl.ch>) Link: https://lore.kernel.org/qemu-devel/c4ecefb4-8769-403f-8420-8bce42e43e13@epfl.ch
- [PATCH 0/3] tests/tcg/plugins: Fix sanitizer issues (Peter Maydell <peter.maydell@linaro.org>) Link: https://lore.kernel.org/qemu-devel/20260305161531.1774895-1-peter.maydell@linaro.org
# -----BEGIN PGP SIGNATURE-----
#
# iQGzBAABCgAdFiEEZrmU7KFPfy5auggff5BUDQoc0A8FAmmp7N8ACgkQf5BUDQoc
# 0A8TfwwAiuLmdRmUIN8Gfd+3ELdamAMb60hXGIh3mV9OqztnYQ3AsmTCvdPqOeq/
# TZePhmDoiPOR7ZyKactGvcF3QmDrqmrcphQOggc8ufQsKM5nLfWIRT/jitVivD0/
# 9HRhEBTQm6QXQmQdkT+AcLJUhyB/WN2dDXajjBIWTjgHmTjPALHT76NmGdhNNhRE
# SPgvXWMucc441C9hbqQOKLBfAxH9v0an2ztgqeb3NlxKcVkBTOMvVcJOLTW7SBNK
# DGxXwc6z9kgp8BhPURKsoBQzDEZajWO6wm+6m11zuCEsuedU/zaH5RKEekjZn/xD
# 5aC7ZfuNpqtT2NGey0b59ehE6Ct6WKLR/dNfh9qgBg6/mmTixi8ozyOntGy700d3
# D2vvuetrPc1RO25Y5Yaa2KOzxq8IQMnxg5cflW+oMsA/Z13VdzC4BoIWOPnyVHOv
# pBLGpe9131iBjfneHDR9ls6WeOzo6ig2xiQ6s0iIUTI8MMnen/u+r6RBlN0IOGTz
# wV2d0/8X
# =pmiX
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu Mar 5 20:51:43 2026 GMT
# gpg: using RSA key 66B994ECA14F7F2E5ABA081F7F90540D0A1CD00F
# gpg: Good signature from "Pierrick Bouvier <pierrick.bouvier@linaro.org>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 66B9 94EC A14F 7F2E 5ABA 081F 7F90 540D 0A1C D00F
* tag 'pr-plugins-20260305' of https://gitlab.com/pbo-linaro/qemu:
tests/tcg/plugins/patch: Free read_data in patch_hwaddr()
tests/tcg/plugins/mem: Correct hash iteration code in plugin_exit()
tests/tcg/plugins/mem: Don't access unaligned memory
plugins: add missing callbacks to version history
tests/tcg/plugins: test register accesses
plugins: prohibit writing to read-only registers
plugins: add read-only property for registers
tests/tcg: add tests for qemu_plugin_set_pc API
plugins: add PC diversion API function
linux-user: make syscall emulation interruptible
plugins: add flag to specify whether PC is rw
plugins/core: clamp syscall arguments if target is 32-bit
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Fri, 6 Mar 2026 09:50:07 +0000 (09:50 +0000)]
Merge tag 'pull-aspeed-20260305' of https://github.com/legoater/qemu into staging
aspeed queue:
* Add I3C support to QEMU, add an dummy I3C device and extend the
Aspeed I3C controller
* Update test ASPEED OpenBMC SDK v11.01
* Fix DMA64 address handling in Aspeed I2C model (AST2700 SoC)
Tao Tang [Wed, 4 Mar 2026 14:23:44 +0000 (22:23 +0800)]
hw/arm/smmuv3: Fix CFGI_CD handling when stage-1 is unsupported
Add a STAGE1_SUPPORTED check in the CMD_CFGI_CD and CMD_CFGI_CD_ALL path
and return CERROR_ILL when stage-1 translation is not implemented,
matching the architecture requirement (IHI 0070G.b, page 176).
Fixes: 32cfd7f39e08 ("hw/arm/smmuv3: Cache/invalidate config data") Signed-off-by: Tao Tang <tangtao1634@phytium.com.cn> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20260304142344.3341444-4-tangtao1634@phytium.com.cn
Links: https://lore.kernel.org/qemu-devel/20260221101733.2995020-1-tangtao1634@phytium.com.cn/ Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tao Tang [Wed, 4 Mar 2026 14:23:42 +0000 (22:23 +0800)]
hw/arm/smmuv3-common: Fix incorrect reserved mask for SMMU CR0 register
The current definition of the SMMU_CR0_RESERVED mask is incorrect.
It mistakenly treats bit 10 (DPT_WALK_EN) as a reserved bit while
treating bit 9 (RES0) as an implemented bit.
According to the SMMU architecture specification, the layout for CR0 is:
| 31:11| RES0 |
| 10 | DPT_WALK_EN |
| 9 | RES0 |
| 8:6 | VMW |
| 5 | RES0 |
| 4 | ATSCHK |
| 3 | CMDQEN |
| 2 | EVENTQEN |
| 1 | PRIQEN |
| 0 | SMMUEN |
Despite GLib's documentation stating that @data_free_func is a
destructor for @test_data, this is not the case. The destructor is
supposed to be paired with a constructor, which GLib only accepts via
g_test_create_case().
Providing externally allocated data plus a destructor function only
works if the test is guaranteed to execute, otherwise the test_data is
never deallocated.
Due to how subprocessess are implemented in qos-test, each test gets
added twice and an extra test gets added per subprocess. In a regular
run, the extra subprocess will not be executed and in a single test
run (-p), none of the other tests will be executed (+1 per
subprocess), leaking 'path_vec' and 'subprocess_path'.
Fix this by storing all the path vectors in a list and freeing them
all at the end of the program (including subprocess invocations) and
moving the allocation of 'subprocess_path' into run_one_subprocess().
While here add some documentation explaining why the graph needs to be
walked twice and tests re-added.
Signed-off-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260302092225.4088227-10-peter.maydell@linaro.org
[PMM: rebased; rewrote the comment in main() a bit to account
for the if (g_test_subprocess()) block it was previously inside
no longer being present. ] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Fabiano Rosas [Fri, 6 Mar 2026 09:01:12 +0000 (09:01 +0000)]
chardev: Don't attempt to unregister yank function more than once
tcp_chr_free_connection() can be called multiple times in succession,
in which case the yank function will get as argument a NULL s->sioc
that has been cleared by the previous tcp_chr_free_connection() call.
This leads to an abort() at yank_unregister_function().
#0 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 __GI_abort () at abort.c:79
#2 qtest_check_status (s=0x513000005600) at ../tests/qtest/libqtest.c:209
#3 qtest_wait_qemu (s=0x513000005600) at ../tests/qtest/libqtest.c:273
#4 qtest_kill_qemu (s=0x513000005600) at ../tests/qtest/libqtest.c:285
#5 kill_qemu_hook_func (s=0x513000005600) at ../tests/qtest/libqtest.c:294
#6 g_hook_list_invoke (hook_list=0x55ea9cc750c0 <abrt_hooks>, may_recurse=0) at ../glib/ghook.c:534
#7 sigabrt_handler (signo=6) at ../tests/qtest/libqtest.c:299
#8 <signal handler called>
#9 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#10 __GI_abort () at abort.c:79
#11 yank_unregister_function (instance=0x7fb26f2ea9a0,
func=0x55ea9bcc0a10 <char_socket_yank_iochannel>, opaque=0x0) at
../util/yank.c:151
#12 tcp_chr_free_connection (chr=0x51300000ffc0) at ../chardev/char-socket.c:385
#13 tcp_chr_disconnect_locked (chr=0x51300000ffc0) at ../chardev/char-socket.c:477
#14 tcp_chr_disconnect (chr=0x51300000ffc0) at ../chardev/char-socket.c:495
#15 tcp_chr_hup (channel=0x514000000040, cond=G_IO_HUP, opaque=0x51300000ffc0) at ../chardev/char-socket.c:536
#16 qio_channel_fd_source_dispatch (source=0x50c0000b5fc0, callback=0x55ea9bcd6770 <tcp_chr_hup>,
user_data=0x51300000ffc0) at ../io/channel-watch.c:84
#17 g_main_dispatch (context=0x50f000000040) at ../glib/gmain.c:3381
#18 g_main_context_dispatch (context=context@entry=0x50f000000040) at ../glib/gmain.c:4099
#19 g_main_context_iterate (context=0x50f000000040, block=block@entry=1, dispatch=dispatch@entry=1,
self=<optimized out>) at ../glib/gmain.c:4175
#20 g_main_loop_run (loop=0x502000055690) at ../glib/gmain.c:4373
Commit ebae6477dc ("chardev: check if the chardev is registered for
yanking") seems to have encountered a similar issue, but checking
s->registered_yank is not a complete solution because that flag
pertains to the yank instance, not to each individual function.
Skip the yank_unregister_function() in case s->sioc is already NULL,
which indicates the last yank function was already removed.
Signed-off-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260302092225.4088227-7-peter.maydell@linaro.org
[PMM: rebased] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Fabiano Rosas [Fri, 6 Mar 2026 09:01:12 +0000 (09:01 +0000)]
chardev: Fix QIOChannel refcount
The IOWatchPoll holds a reference to the iochannel while the "child"
source (iwp->src) is removed from the context and freed. Freeing the
source leads to the iochannel being also freed at
qio_channel_fd_source_finalize().
Later, io_watch_poll_prepare() tries to create another source with the
same iochannel and hits an use after free:
==8241==ERROR: AddressSanitizer: heap-use-after-free on address 0x514000000040
READ of size 8 at 0x514000000040 thread T2
#0 0x561c2d272fcd in object_get_class ../qom/object.c:1043:17
#1 0x561c2d338f84 in QIO_CHANNEL_GET_CLASS include/io/channel.h:29:1
#2 0x561c2d33b26f in qio_channel_create_watch ../io/channel.c:388:30
#3 0x561c2d2f0993 in io_watch_poll_prepare ../chardev/char-io.c:65:20
...
0x514000000040 is located 0 bytes inside of 392-byte region [0x514000000040,0x5140000001c8)
freed by thread T2 here:
#0 0x561c2d2319a5 in free
#1 0x7fb2c0926638 in g_free
#2 0x561c2d276507 in object_finalize ../qom/object.c:734:9
#3 0x561c2d271d0d in object_unref ../qom/object.c:1231:9
#4 0x561c2d32ef1d in qio_channel_fd_source_finalize ../io/channel-watch.c:95:5
#5 0x7fb2c091d124 in g_source_unref_internal ../glib/gmain.c:2298
#6 0x561c2d2f0b6c in io_watch_poll_prepare ../chardev/char-io.c:71:9
...
previously allocated by thread T3 (connect) here:
#0 0x561c2d231c69 in malloc
#1 0x7fb2c0926518 in g_malloc
#2 0x561c2d27246e in object_new_with_type ../qom/object.c:767:15
#3 0x561c2d272530 in object_new ../qom/object.c:789:12
#4 0x561c2d320193 in qio_channel_socket_new ../io/channel-socket.c:64:31
#5 0x561c2d308013 in tcp_chr_connect_client_async ../chardev/char-socket.c:1181:12
#6 0x561c2d3002e7 in qmp_chardev_open_socket_client ../chardev/char-socket.c:1281:9
...
Fix the issue by incrementing the iochannel reference count when the
IOWatchPoll takes a reference and decrementing when it is finalized.
Signed-off-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260302092225.4088227-6-peter.maydell@linaro.org
[PMM: rebased] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Fri, 6 Mar 2026 09:01:12 +0000 (09:01 +0000)]
tests/qtest/iommu-smmuv3-test: Free QPCIDevice
The QPCIDevice we get via qpci_device_foreach() is allocated
memory, and we need to g_free() it after use.
This fixes asan leaks like this:
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x622a5f16913d in calloc (/home/pm215/qemu/build/arm-clang/tests/qtest/iommu-smmuv3-test+0x1d413d) (BuildId: bc598be1f4ad6d1a9a600c55aeef36108bdb6a04)
#1 0x73ee41c0f771 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x63771) (BuildId: 116e142b9b52c8a4dfd403e759e71ab8f95d8bb3)
#2 0x622a5f1d4cec in qpci_device_find /home/pm215/qemu/build/arm-clang/../../tests/qtest/libqos/pci.c:82:11
#3 0x622a5f1d4cec in qpci_device_foreach /home/pm215/qemu/build/arm-clang/../../tests/qtest/libqos/pci.c:34:19
#4 0x622a5f23cc73 in setup_qtest_pci_device /home/pm215/qemu/build/arm-clang/../../tests/qtest/iommu-smmuv3-test.c:45:5
#5 0x622a5f23cc73 in run_smmuv3_translation /home/pm215/qemu/build/arm-clang/../../tests/qtest/iommu-smmuv3-test.c:74:11
Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260302092225.4088227-5-peter.maydell@linaro.org
Peter Maydell [Fri, 6 Mar 2026 09:01:12 +0000 (09:01 +0000)]
hw/arm/aspeed_gpio: Don't leak string in aspeed_gpio_init()
We allocate the string for the GPIO property name, but never free it.
Use g_autofree to avoid this.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260302092225.4088227-4-peter.maydell@linaro.org
Peter Maydell [Fri, 6 Mar 2026 09:01:12 +0000 (09:01 +0000)]
scripts/lsan_suppressions.txt: Add more leaks
Running "make check" with the clang leak sanitizer reveals some
leak reports which are either not our problem or else not
a leak which is worth our time to fix. Add some suppressions
for these.
While we're touching the file, add the usual SPDX header
and a comment explaining how to use it.
Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260302092225.4088227-3-peter.maydell@linaro.org
Peter Maydell [Fri, 6 Mar 2026 09:01:12 +0000 (09:01 +0000)]
scripts: Move lsan_suppressions.txt out of oss-fuzz subdir
The oss-fuzz code uses an lsan_suppressions file to suppress certain
leak-sanitizer cases that are known issues or not our code's bug.
This is useful more widely than just for the fuzzer harness: if you
want to build QEMU with the leak sanitizer enabled and run 'make
check' then you will want to suppress some bogus leak reports.
Move the file up a directory.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Yodel Eldar <yodel.eldar@yodel.dev>
Message-id: 20260302092225.4088227-2-peter.maydell@linaro.org
Eric Auger [Fri, 6 Mar 2026 09:01:12 +0000 (09:01 +0000)]
target/arm/machine: Fix detection of unknown incoming cpregs
Currently the check of cpreg index matches fail to detect
a situation where the length of both arrays is same but
- destination has an extra register not found in the incoming stream (idx1)
- source has an extra register not found in the destination (idx2)
where idx1 < = idx2
Normally this should fail but it does not.
Fix the logic to scan all indexes.
Fixes: 721fae12536 ("target-arm: Convert TCG to using (index,value) list for cp migration") Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260304101625.1962633-8-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Eric Auger [Fri, 6 Mar 2026 09:01:12 +0000 (09:01 +0000)]
target/arm/machine: Trace all register mismatches
At the moment, cpu_post_load() exits with error on the first
catch of unexpected register in the incoming stream. Let the code
go further and trace all the issues before exiting.
Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260304101625.1962633-7-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Eric Auger [Fri, 6 Mar 2026 09:01:12 +0000 (09:01 +0000)]
target/arm/machine: Trace cpreg names which do not match on migration
Whenever there is a mismatch between cpreg indexes in the incoming
stream and cpregs exposed by the destination output the name of
the register. We use a print_register_name() wrapper helper. At the
moment we are only able to do a nice decoding of the index for
KVM regs.
Without this patch, the error would be:
qemu-system-aarch64: load of migration failed: Operation not permitted:
error while loading state for instance 0x0 of device 'cpu': post load
hook failed for: cpu, version_id: 22, minimum_version: 22, ret: -1
which is not helpful for the end user to understand the actual
issue.
This patch adds the actual information about the probme:
qemu-system-aarch64: cpu_post_load: system register
op0:3 op1:0 crn:2 crm:0 op2:3 in the incoming stream but
unknown on the destination, fail migration
Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260304101625.1962633-6-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Eric Auger [Fri, 6 Mar 2026 09:01:12 +0000 (09:01 +0000)]
target/arm/kvm: Tweak print_register_name() for arm64 system register
As opposed to other register types, arm64 system register decoding
is not introduced by any 'register' mention which can lead to
unfriendly user-facing traces. Let's add "system register"
Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260304101625.1962633-5-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Eric Auger [Fri, 6 Mar 2026 09:01:12 +0000 (09:01 +0000)]
target/arm/kvm: Export kvm_print_register_name()
We want to use kvm_print_register_name() in machine.c so
let's export the helper and implement a stub when kvm
is not enabled.
Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260304101625.1962633-4-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Eric Auger [Fri, 6 Mar 2026 09:01:12 +0000 (09:01 +0000)]
target/arm/machine: Use VMSTATE_VARRAY_INT32_ALLOC for cpreg arrays
This removes the need for explicitly allocating cpreg_vmstate arrays.
On post save we simply point to cpreg arrays and set the length
accordingly.
Remove VMSTATE_VARRAY_INT32 for cpreg_vmstate_array_len as now
the array is dynamically allocated.
Also add a trace point on post_load to trace potential mismatch
between the number of incoming cpregs versus current ones.
Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260304101625.1962633-3-eric.auger@redhat.com Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Eric Auger [Fri, 6 Mar 2026 09:01:12 +0000 (09:01 +0000)]
vmstate: Introduce VMSTATE_VARRAY_INT32_ALLOC
Already existing VMSTATE_VARRAY_INT32 requires an array to be
pre-allocated, however there are cases when the size is not known in
advance and there is no real need to enforce it.
Introduce VMSTATE_VARRAY_INT32_ALLOC as we currently have for UINT32
and UINT16.
The first user of this variant will be the target/arm/machine.c cpreg
indexes/values arrays.
Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Xu <peterx@redhat.com>
Message-id: 20260304101625.1962633-2-eric.auger@redhat.com Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The smc91c111 data frame format in memory (figure 8-1 in the
datasheet) includes a "byte count" field which is intended to be the
total size of the data frame, including not just the packet data but
also the leading and trailing information like the status word and
the byte count field itself. It is therefore possible for the guest
to set this to a value so small that the leading and trailing fields
won't fit and the packet has effectively a negative area.
We weren't checking for this, with the result that when we subtract 6
from the length to get the length of the packet proper we end up with
a negative length, which is then inconsistently handled in the
qemu_send_packet() code such that we can try to transmit a very large
amount of data and read off the end of the device's data array.
Treat excessively small length values the same way we do excessively
large values. As with the oversized case, the datasheet does not
describe what happens for this software error case, and there is no
relevant tx error condition for this, so we just log and drop the
packet.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3304 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260226175549.1319476-1-peter.maydell@linaro.org
Peter Maydell [Fri, 6 Mar 2026 09:01:12 +0000 (09:01 +0000)]
system/qtest: Support comments in input commands
Allow the qtest input to include comment lines, which start with '#'.
This allows writing an input file for qtest which includes commentary,
like this:
# set up TCR in bank 0
write 0x1001000e 2 0
# TCR TXEN
write 0x10010000 2 1
which can make hand-writing or annotating reproduce cases a bit
more convenient.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260226175700.1319767-1-peter.maydell@linaro.org
Paul Durrant [Fri, 6 Mar 2026 09:01:11 +0000 (09:01 +0000)]
MAINTAINERS: remove myself as a Xen maintainer
I am no longer actively involved in the Xen Project.
Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Message-id: 20260224112215.83355-1-paul@xen.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
hw/arm/smmuv3: Introduce a helper function for event propagation
Factor out the code that propagates event records to the guest into a
helper function. The accelerated SMMUv3 path can use this to propagate
host events in a subsequent patch.
Take the mutex inside the helper before accessing the Event Queue.
Today event propagation occurs only in the core SMMUv3 path and is
effectively serialized. A subsequent patch will also invoke this helper
from the accelerated event read path, which may run concurrently.
Therefore serialization is required here.
No functional change intended.
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
Message-id: 20260226084456.112142-5-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Nicolin Chen [Fri, 6 Mar 2026 09:01:11 +0000 (09:01 +0000)]
hw/arm/smmuv3-accel: Allocate vEVENTQ for accelerated SMMUv3 devices
When the guest enables the Event Queue and a vIOMMU is present, allocate a
vEVENTQ object so that host-side events related to the vIOMMU can be
received and propagated back to the guest.
Allocate a vEVENTQ only when both of the following conditions are met:
1) The guest SMMUv3 driver has set EVENTQEN = 1 in SMMU_CR0.
2) A vIOMMU exists (created when the first VFIO device is attached).
These two conditions may occur in any order.
In the cold-plug case, the vIOMMU already exists before the guest
driver probes. When the guest sets EVENTQEN = 1 during driver probe,
the vEVENTQ is allocated at that point.
With hot-plug, the VFIO device may be attached either before or after
the guest sets EVENTQEN. If the vIOMMU is created first, allocation is
deferred until EVENTQEN = 1. If EVENTQEN is already set, allocation
happens when the vIOMMU is created.
In all cases, allocation is triggered when the second required
condition becomes true.
Errors from command queue consumption and vEVENTQ allocation are reported
independently as the two operations are unrelated.
Event read and propagation will be added in a later patch.
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
Message-id: 20260226084456.112142-4-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Move viommu teardown into a helper function and use it from the
last device removal path.
This groups related cleanup logic in one place and improves readability.
It also makes it easier to extend the teardown in future, for example
when freeing related objects such as vEVENTQ.
No functional change.
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
Message-id: 20260226084456.112142-3-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Chisheng Chen [Fri, 6 Mar 2026 09:01:11 +0000 (09:01 +0000)]
hw/arm: Add missing dependencies for STM32F405 SoC
The STM32F405 SoC relies on STM32F2xx peripherals (ADC, SPI, TIMER,
USART) and the unimplemented device (UNIMP). However, they are not
selected in Kconfig. This added these dependencies.
Signed-off-by: Chisheng Chen <johnny1001s000602@gmail.com>
Message-id: 20260228070622.2195836-1-johnny1001s000602@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Thomas Huth [Fri, 6 Mar 2026 09:01:11 +0000 (09:01 +0000)]
hw/net: Remove the xgmac device
The xgmac device was only used by the highbank machine that just
has been removed. Being a sysbus device that cannot be instantiated
by the user, this is dead code now and thus can be removed, too.
Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Thomas Huth [Fri, 6 Mar 2026 09:01:11 +0000 (09:01 +0000)]
hw/arm: Remove the deprecated "highbank" and "midway" machines
These machines have been marked as deprecated two releases ago,
and so far nobody complained that they are still useful, so it's
time to remove these now.
Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260226090704.27699-1-thuth@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Pierrick Bouvier [Wed, 25 Feb 2026 04:19:46 +0000 (05:19 +0100)]
hw/virtio/virtio-qmp: make compilation unit common
All compile time conditionals have no impact at runtime, since they are
representing only possible features for devices present at runtime.
In case they are not present, associated features table will never be
used. In case they are present but some features are not, matching bits
will never be enabled, so those entries will be unused.
Thus, simply expose everything and call it a day.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Link: https://lore.kernel.org/qemu-devel/20260225041948.52929-6-philmd@linaro.org Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Pierrick Bouvier [Wed, 25 Feb 2026 04:19:45 +0000 (05:19 +0100)]
hw/virtio/vhost-user: make compilation unit common
PPC architectures use a custom value for VHOST_USER_MAX_RAM_SLOTS (32
instead of 512).
vhost_user struct and several functions use VHOST_USER_MAX_RAM_SLOTS to
define stack allocated buffers. To avoid changing all functions to use
heap allocated buffers, we keep this max, and simply add a
target_base_ppc() conditional for the single place where size really
matters.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Link: https://lore.kernel.org/qemu-devel/20260225041948.52929-5-philmd@linaro.org Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Pierrick Bouvier [Wed, 25 Feb 2026 04:19:43 +0000 (05:19 +0100)]
hw/virtio: Simplify virtio_access_is_big_endian()
Thanks to previous refactoring, we can see more easily it is strictly
equivalent to always call virtio_vdev_is_big_endian.
static inline bool virtio_vdev_is_big_endian(VirtIODevice *vdev)
{
if (virtio_vdev_is_legacy(vdev)) {
assert(vdev->device_endian != VIRTIO_DEVICE_ENDIAN_UNKNOWN);
return vdev->device_endian == VIRTIO_DEVICE_ENDIAN_BIG;
}
/* Devices conforming to VIRTIO 1.0 or later are always LE. */
return false;
}
The key is to understand that vdev->device_endian is initialized as
expected. It always contains cpu endianness, and not
device endianness, ignoring if device is legacy or not.
By default, it's initialized to vdev->device_endian =
virtio_default_endian(), which matches target default endianness.
Then, on virtio_reset, it will be initialized with current_cpu
endianness (if there is one current_cpu).
Now, we can see how existing virtio_access_is_big_endian is equivalent
to virtio_vdev_is_big_endian. Let's break the existing function in its 3
variants, and compare that to virtio_vdev_is_big_endian.
static inline bool virtio_access_is_big_endian(VirtIODevice *vdev)
- #if defined(LEGACY_VIRTIO_IS_BIENDIAN)
return virtio_vdev_is_big_endian(vdev);
This is the exact replacement we did, so equivalent.
- #elif TARGET_BIG_ENDIAN
if (!virtio_vdev_is_legacy(vdev)) {
return false;
}
return true;
we know target_is_big_endian(), so
vdev->device_endian == VIRTIO_DEVICE_ENDIAN_BIG.
if (virtio_vdev_is_legacy(vdev)) {
return VIRTIO_DEVICE_ENDIAN_BIG == VIRTIO_DEVICE_ENDIAN_BIG;
}
return false;
It's written in opposite style compared to existing code (if legacy vs
if modern), but it's strictly equivalent.
- #else
return false;
we know !target_is_big_endian(), so
vdev->device_endian == VIRTIO_DEVICE_ENDIAN_LITTLE.
if virtio_vdev_is_legacy(vdev) {
return VIRTIO_DEVICE_ENDIAN_LITTLE == VIRTIO_DEVICE_ENDIAN_BIG;
}
return false;
So it always return false, as expected.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Link: https://lore.kernel.org/qemu-devel/20260225041948.52929-3-philmd@linaro.org Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Peter Maydell [Thu, 5 Mar 2026 16:15:30 +0000 (16:15 +0000)]
tests/tcg/plugins/mem: Correct hash iteration code in plugin_exit()
In plugin_exit() we call g_hash_table_get_values() to get a GList
which we look at to print some information. This code has
multiple issues:
* it names the local variable for the GList "count", which
shadows the "qemu_plugin_scoreboard *count". This isn't
incorrect, but it is unnecessarily confusing
* it doesn't free the list, and the leak sanitizer complains:
Indirect leak of 2328 byte(s) in 97 object(s) allocated from:
#0 0x5589b0b72293 in malloc (/home/pm215/qemu/build/x86-tgt-san/qemu-system-i386+0x1a2f293) (BuildId: 26964cad9e3f81d35fc144d7cc88b53adf6f60c7)
#1 0x78fd8cfa1ac9 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62ac9) (BuildId: 116e142b9b52c8a4dfd403e759e71ab8f95d8bb3)
#2 0x78fd8cf96e4a in g_list_prepend (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e4a) (BuildId: 116e142b9b52c8a4dfd403e759e71ab8f95d8bb3)
#3 0x78fd8cf8b318 in g_hash_table_get_values (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4c318) (BuildId: 116e142b9b52c8a4dfd403e759e71ab8f95d8bb3)
#4 0x78fd84d1a90c in plugin_exit /home/pm215/qemu/build/x86-tgt-san/../../tests/tcg/plugins/mem.c:87:25
* in iterating through the list it updates "count", so by the
time we get to the end of the loop we no longer have a pointer
to the head of the list that we could use to free it
* it checks for the list being NULL twice (once in an if()
and once in the for() loop's "while" condition), which is
redundant
* it skips the loop if g_list_next(counts) is NULL, which means
it will wrongly skip the loop if the list has only one entry
In commit eb3f69cac62670 we removed the dependency of this mem plugin
on the QEMU headers, but in doing that we introduced undefined
behaviour when the plugin accesses unaligned memory. This shows up
if you build with the gcc or clang undefined behaviour sanitizer
(--enable-ubsan) and run 'make check-tcg', in numerous warnings like:
The additional plugin tests register accesses, specifically both for
read-only and read-write registers. Writing to a read-only register is
currently not tested, as this would trigger an assertion and fail the
test.
The opaque register handle encodes whether a register is read-only in
the lowest bit and prevents writing to the register via the plugin API
in this case.
Some registers should be marked as read-only from a plugin API
perspective, as writing to them via qemu_plugin_write_register has no
effect. This includes the program counter, and we expose this fact to
the plugins with this patch.
The test plugin intercepts execution in different contexts. Without the
plugin, any of the implemented test functions would trigger an assert
and fail. With the plugin, control flow is redirected to skip the assert
and return cleanly via the qemu_plugin_set_pc() API.
This patch adds a plugin API function that allows diverting the program
counter during execution. A potential use case for this functionality is
to skip over parts of the code, e.g., by hooking into a specific
instruction and setting the PC to the next instruction in the callback.
The syscall emulation code previously wasn't interruptible via
cpu_loop_exit(), as this construct relies on a longjmp target that is not
live anymore in the syscall handling code. Consequently, longjmp() would
operate on a (potentially overwritten) stale jump buffer. This patch adds an additional
setjmp and the necessary handling around it to make longjmp() (and by
proxy cpu_loop_exit() safe to call even within a syscall context.
In addition to the flags specifying whether general-purpose registers
are read-write (rw) during a plugin callback, we add an additional flag
explicitly stating whether the PC is writable. This is in preparation of
a patch that allows to explicitly set the PC to divert control flow from
within a plugin callback, which is currently not possible.
plugins/core: clamp syscall arguments if target is 32-bit
Syscall arguments are abi_long in user code, and plugin syscall
interface works with uint64_t only.
According to C integer promotion rules, the value is sign extended
before becoming unsigned, thus setting high bits when only 32-bit lower
ones should have a significant value.
As a result, we need to clamp values we receive from user-code
accordingly.
Peter Maydell [Thu, 5 Mar 2026 17:49:14 +0000 (17:49 +0000)]
Merge tag 'next-pr-pull-request' of https://gitlab.com/berrange/qemu into staging
* Increase pre-alloc max thread count to 32
* Fix checkpatch warning for new/removed files with --terse
* Detect more GPL boilerplate in checkpatch
* Fix lean of data in TLS/websock GSource cancellation
* Tweak CPU docs for DiamondRapids
* Unconditionally enable thread naming
* Fix race setting thread naming on Win32
* Add API docs for logging APIs
* Fix interleaved error/trace output
* Fix missing error prefixes with warn_report
* Add detailed error reporting for VNC passworrd changes
* Refactoring of error_vprintf & related funcs
* tag 'next-pr-pull-request' of https://gitlab.com/berrange/qemu: (27 commits)
util/oslib-posix: increase memprealloc thread count to 32
scripts/checkpatch: Fix MAINTAINERS update warning with --terse
util: fix interleaving of error prefixes
util: don't skip error prefixes when QMP is active
util: fix interleaving of error & trace output
monitor: move error_vprintf back to error-report.c
monitor: refactor error_vprintf()
monitor: remove redundant error_[v]printf_unless_qmp
ui: remove redundant use of error_printf_unless_qmp()
ui: add proper error reporting for password changes
util/log: add missing error reporting in qemu_log_trylock_with_err
util: avoid repeated prefix on incremental qemu_log calls
util: introduce some API docs for logging APIs
util: add API to fetch the current thread name
util: set the name for the 'main' thread on Windows
audio: make jackaudio use qemu_thread_set_name
util: expose qemu_thread_set_name
util: fix race setting thread name on Win32
system: unconditionally enable thread naming
monitor: initialize global data from a constructor
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Jamin Lin [Tue, 3 Mar 2026 01:33:28 +0000 (01:33 +0000)]
hw/i3c/core: Initialize num_sent in i3c_send_byte()
i3c_send_byte() declared num_sent without initializing it before
passing its address to i3c_send().
Although i3c_send_byte() itself ignores num_sent after the call,
i3c_send() forwards it to trace_i3c_send(). If the target send
callback does not set *num_sent, the trace may print an
uninitialized value, leading to misleading or garbage output.
Example concern from review:
trace_i3c_send(*num_sent, num_to_send, ret == 0);
If *num_sent is not written by the callback, this trace can report
an incorrect number of transmitted bytes.
Initialize num_sent to 0 to ensure deterministic and predictable
trace output, even if the callback fails to update it.
Jamin Lin [Tue, 3 Mar 2026 01:33:26 +0000 (01:33 +0000)]
hw/i3c/mock-i3c-target: Set num_sent in TX callback to fix trace reporting
mock_i3c_target_tx() did not update *num_sent before returning.
Although some callers may not directly use this value, i3c_send()
passes num_sent to trace_i3c_send(). If the target TX callback does
not initialize *num_sent, the trace output may report an incorrect
or uninitialized value, leading to confusing debugging information.
hw/i3c: Fix array bounds and storage in i3c_addr_is_rsvd()
The size of the is_rsvd lookup table in i3c_addr_is_rsvd() is 255 but
should be 256 to cover all possible uint8_t address values and avoid
potential out-of-bounds access.
The array should be static too as it's a constant lookup table.
Jamin Lin [Wed, 25 Feb 2026 02:12:40 +0000 (02:12 +0000)]
MAINTAINERS: Add I3C maintainers and reviewer
Add a new I3C section to the MAINTAINERS file.
List Joe Komlodi, Cédric Le Goater and Jamin Lin
as maintainers, and Nabih Estefan as the reviewer,
covering the I3C core and related files under hw/i3c/
and include/hw/i3c/.
Jamin Lin [Wed, 25 Feb 2026 02:12:36 +0000 (02:12 +0000)]
hw/i3c: Add hotplug support
This adds support for hotplugging in I3C.
Conceptually this can be thought of as an I3C target being physically
socketed onto a board.
It is then the target's responsibility to go through the hot-join and
DAA process so it can participate on the bus.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Patrick Venture <venture@google.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-21-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:34 +0000 (02:12 +0000)]
hw/arm/aspeed: Build with I3C_DEVICES
Allows us to attach the mock I3C target
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-20-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:33 +0000 (02:12 +0000)]
hw/i3c: Add Mock target
Adds a simple i3c device to be used for testing in lieu of a real
device.
The mock target supports the following features:
- A buffer that users can read and write to.
- CCC support for commonly used CCCs when probing devices on an I3C bus.
- IBI sending upon receiving a user-defined byte.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Titus Rwantare <titusr@google.com> Reviewed-by: Patrick Venture <venture@google.com> Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-19-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:31 +0000 (02:12 +0000)]
hw/i3c/aspeed: Add I3C bus get function
To retrieve the I3C bus object normally, the order is Aspeed I3C -> DW
I3C[n] -> bus object, so make a nice wrapper for people to use.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-18-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:29 +0000 (02:12 +0000)]
hw/i3c/dw-i3c: Add controller resets
Adds behavior to the device reset register.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Patrick Venture <venture@google.com> Reviewed-by: Stephen Longfield <slongfield@google.com> Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-17-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
Jamin Lin [Wed, 25 Feb 2026 02:12:27 +0000 (02:12 +0000)]
hw/i3c/dw-i3c: Add ctrl MMIO handling
Adds functionality to the CTRL register.
Signed-off-by: Joe Komlodi <komlodi@google.com> Reviewed-by: Titus Rwantare <titusr@google.com> Reviewed-by: Patrick Venture <venture@google.com> Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Tested-by: Jithu Joseph <jithu.joseph@oss.qualcomm.com> Link: https://lore.kernel.org/qemu-devel/20260225021158.1586584-16-jamin_lin@aspeedtech.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
projects / thirdparty / qemu.git / log
