hw/s390x/s390-pci-vfio: Avoid including CONFIG_DEVICES in hw/ header
By turning the inline functions into stubs we can avoid the
use of target-specific CONFIG_DEVICES include in a hw/ header,
allowing to build the source files including it as common objects.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Farhan Ali<alifm@linux.ibm.com>
Message-Id: <20260225031658.32095-4-philmd@linaro.org>
hw/acpi: Always link QOM interfaces with system binaries
Now that acpi_interface.c only contains QOM interfaces,
unconditionally link it with system binaries, regardless
of whether CONFIG_ACPI is set or not. It is now easier to
deselect hardware models depending on ACPI.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20260225035739.42848-5-philmd@linaro.org>
hw/acpi: Move acpi_send_event() function out of acpi_interface.c
acpi_interface.c should only register QOM interfaces. Move
the acpi_send_event() function to core.c with the other
event handlers, and its declaration in 'hw/acpi/acpi.h'.
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20260225035739.42848-3-philmd@linaro.org>
meson: Include various directories providing stubs before libqemuutil
Stubs are provided by libqemuutil. We want to use the generic meson
machinery to provide stubs once, instead of per sub-directories. Move
the 'subdir' calls earlier so when these directories are processed
they can add units to the global stub_ss[] source set.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20260225035739.42848-2-philmd@linaro.org>
The hw_compat_3_0[] array was only used by the pc-q35-3.0
and pc-i440fx-3.0 machines, which got removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20260307150042.78030-5-philmd@linaro.org>
target/i386/kvm: Remove X86CPU::hyperv_synic_kvm_only field
The X86CPU::hyperv_synic_kvm_only boolean (see commit 9b4cf107b09
"hyperv: only add SynIC in compatible configurations") was only set
in the pc_compat_3_0[] array, via the 'x-hv-synic-kvm-only=on'
property. We removed all machines using that array, lets remove that
property and all the code around it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20260307150042.78030-4-philmd@linaro.org>
The pc_compat_3_0[] array was only used by the pc-q35-3.0
and pc-i440fx-3.0 machines, which got removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20260307150042.78030-3-philmd@linaro.org>
hw/i386/pc: Remove deprecated pc-q35-3.0 and pc-i440fx-3.0 machines
These machines has been supported for a period of more than 6 years.
According to our versioned machine support policy (see commit ce80c4fa6ff "docs: document special exception for machine type
deprecation & removal") they can now be removed.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20260307150042.78030-2-philmd@linaro.org>
Akihiko Odaki [Sat, 7 Mar 2026 03:22:25 +0000 (12:22 +0900)]
contrib/plugins/bbv.c: Check if file is NULL
The file pointer can be NULL when e.g., opening the file failed.
vcpu_interval_exec() already implements a NULL-pointer check, but
plugin_exit() misses it. Handle the condition by adding the missing
check to plugin_exit().
Fixes: 0d279bec0f14 ("contrib/plugins: Add a plugin to generate basic block vectors") Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Link: https://lore.kernel.org/qemu-devel/20260307-bbv-v1-1-d5757d1deac8@rsg.ci.i.u-tokyo.ac.jp Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
contrib/plugins/uftrace_symbols.py: ignore zero sized symbols
When using llvm-addr2line in replacement of addr2line, it will output
zero sized symbols, which can shadow other binaries depending on where
their location is (happens with arm-trusted-firmware and its different
binaries). Thus, ignore those symbols.
- support per-head resolution definitions
- don't disable scanouts on sdl and gtk when display refreshed
- take care not confuse virgl with switching contexts
- use dmabuf to import textures when we can
- keep virtio BH processing to main-loop
- improve error handling for fence creation
- support async fences
- add support for DRM native context
- update virtio-gpu docs
- remove superfluous memory region enabling
- validate mapping offsets
- destroy vrigl resources on reset
- support mapping hostmem blobs with map_fixed
* tag 'pull-11.0-virtio-gpu-updates-060326-1' of https://gitlab.com/stsquad/qemu:
virtio-gpu: Support mapping hostmem blobs with map_fixed
virtio-gpu: Destroy virgl resources on virtio-gpu reset
virtio-gpu: Replace finish_unmapping with mapping_state
virtio-gpu: Validate hostmem mapping offset
virtio-gpu: Remove superfluous memory_region_set_enabled()
docs/system: virtio-gpu: Document host/guest requirements
docs/system: virtio-gpu: Update Venus link
docs/system: virtio-gpu: Add link to Mesa VirGL doc
virtio-gpu: Support DRM native context
virtio-gpu: Support asynchronous fencing
virtio-gpu: Handle virgl fence creation errors
virtio-gpu: Ensure BHs are invoked only from main-loop thread
ui/sdl2: Implement dpy dmabuf functions
ui/sdl2: Restore original context after new context creation
ui/gdk: Restore original context after new context creation
ui/egl: Don't change bound GL context when creating new context
ui/sdl2: Don't disable scanout when display is refreshed
ui/gtk: Don't disable scanout when display is refreshed
virtio-gpu: Fix scanout dmabuf cleanup during resource destruction
Support per-head resolutions with virtio-gpu
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* tag 'for-upstream' of https://gitlab.com/kmwolf/qemu:
iotests/244: Add test cases for keep_data_file
iotests/common.filter: Sort keep_data_file
qcow2: Simplify size round-up in co_create_opts
qcow2: Add keep_data_file command-line option
block/nfs: Do not enter coroutine from CB
block: Never drop BLOCK_IO_ERROR with action=stop for rate limiting
block/throttle-groups: fix deadlock with iolimits and muliple iothreads
mirror: Fix missed dirty bitmap writes during startup
block/curl: fix concurrent completion handling
hmp_nbd_server_start: Don't ask for backing image data
block: Wire up 'flat' mode also for 'query-block'
block/vmdk: fix OOB read in vmdk_read_extent()
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Dmitry Osipenko [Wed, 4 Mar 2026 16:50:42 +0000 (16:50 +0000)]
virtio-gpu: Support mapping hostmem blobs with map_fixed
Support mapping virgl blobs to a fixed location of a hostmem memory
region using new virglrenderer MAP_FIXED API.
This new feature closes multiple problems for virtio-gpu on QEMU:
- Having dedicated memory region for each mapped blob works notoriously
slow due to QEMU's memory region software design built around RCU that
isn't optimized for frequent removal of the regions
- KVM isn't optimized for a frequent slot changes too
- QEMU/KVM has a limit for a total number of created memory regions,
crashing QEMU when limit is reached
This patch makes virtio-gpu-gl to pre-create a single anonymous memory
region covering whole hostmem area to which blobs will be mapped using
the MAP_FIXED API.
Not all virgl resources will support mapping at a fixed memory address. For
them, we will continue to create individual nested memory sub-regions. In
particular, vrend resources may not have MAP_FIXED capability.
Venus and DRM native contexts will largely benefit from the MAP_FIXED
feature in terms of performance and stability improvement.
Dmitry Osipenko [Wed, 4 Mar 2026 16:50:40 +0000 (16:50 +0000)]
virtio-gpu: Replace finish_unmapping with mapping_state
Allow virtio_gpu_virgl_unmap_resource_blob() to be invoked while async
unmapping is in progress. Do it in preparation to improvement of virtio-gpu
resetting that will require this change.
There is no need to explicitly enable/disable memory region when it's
added or deleted respectively. Remove superfluous set_enabled() calls
for consistency.
This attempts to tidy up the VirtIO GPU documentation to make the list
of requirements clearer. There are still a lot of moving parts and the
distros have some catching up to do before this is all handled
automatically.
Dmitry Osipenko [Wed, 4 Mar 2026 16:50:36 +0000 (16:50 +0000)]
docs/system: virtio-gpu: Update Venus link
Change virtio-gpu Venus link, pointing it at the Mesa Venus
documentation instead of the protocol. The Mesa doc provides more
information and also has a link to the protocol.
Dmitry Osipenko [Wed, 4 Mar 2026 16:50:34 +0000 (16:50 +0000)]
virtio-gpu: Support DRM native context
Add support for DRM native contexts to VirtIO-GPU. DRM context is enabled
using a new virtio-gpu-gl device option "drm_native_context=on".
Unlike Virgl and Venus contexts that operate on application API level,
DRM native contexts work on a kernel UAPI level. This lower level results
in a lightweight context implementations that yield better performance.
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> Tested-by: Yiwei Zhang <zzyiwei@gmail.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Message-ID: <20260303151422.977399-11-dmitry.osipenko@collabora.com>
Message-ID: <20260304165043.1437519-13-alex.bennee@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
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.
projects / thirdparty / qemu.git / log
