Some migration tests need to be run with shmem, the rest by default use
anonymous memory.
Introduce MemType and replace use_shmem with such a enumeration. This
prepares for a 3rd type of memory to be tested for migration.
Careful readers may also already notice that MigrateStart has another field
called memory_backend, which makes the whole "memory type" definition
convoluted. That'll be merged into MemType soon in a follow up patch.
When doing this, introduce some migrate_mem_type_*() helpers to do the
work for each memory type.
Reviewed-by: Juraj Marcin <jmarcin@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20251117223908.415965-2-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
One of two error messages show __func__. Drop it; it doesn't help
users, and developers can grep for the message. This also permits
de-duplicating the code to prepend to the error message.
Both error messages show a numeric error code. I doubt that's
helpful, but I'm leaving it alone.
Use error_append_hint() for explaining that some dirty bitmaps may be
lost. Polish the prose.
Don't faff around with g_clear_pointer(), it's not worth its keep
here.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20251115083500.2753895-4-armbru@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
migrate_set_error(s, err) stores a copy of @err in @s. The original
@err is not freed. Most callers free it immediately. Some callers
free it later, or pass it on. And some leak it. Fix those.
Perhaps migrate_set_error(s, err) should take ownership of @err. The
callers that free it immediately would become simpler, and avoid a
copy and a deallocation. The others would have to pass
error_copy(err).
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Link: https://lore.kernel.org/r/20251115083500.2753895-2-armbru@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
In migration_remove_notifier(), g_slist_remove() will search for and
potentially remove an entry from the specified list. The return value
should be used to update the potentially-changed head pointer of the
list that was just searched (migration_state_notifiers[mode]) instead
of the migration blockers list.
Fixes: dc79c7d5e1 ("migration: multi-mode notifier")
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/r/20251113213545.513453-1-mjrosato@linux.ibm.com
Signed-off-by: Peter Xu <peterx@redhat.com>
Commit 4881411136 ("migration: Always set DEVICE state") set a new DEVICE
state before completed during migration, which broke the original transition
to COLO. The migration flow for precopy has changed to:
active -> pre-switchover -> device -> completed.
This patch updates the transition state to ensure that the Pre-COLO
state corresponds to DEVICE state correctly.
Cc: qemu-stable <qemu-stable@nongnu.org>
Fixes: 4881411136 ("migration: Always set DEVICE state")
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
Reviewed-by: Zhang Chen <zhangckid@gmail.com>
Tested-by: Zhang Chen <zhangckid@gmail.com>
Link: https://lore.kernel.org/r/20251104013606.1937764-1-lizhijian@fujitsu.com
Signed-off-by: Peter Xu <peterx@redhat.com>
* mtest2make cleanups to enable per-speed dependencies
* record/replay tracepoints
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmkdftoUHHBib256aW5p
QHJlZGhhdC5jb20ACgkQv/vSX3jHroOv9Af/foJ7LXUHok8xnPrvKYEIkkVmJFpM
dt7NzLRoyVHh/zOd/MOfOJCw2+/RLGxA7o1Mm+10DCM6+hcs9VeqeIGSElIP0Uvk
NGau6/3l/pkE+oyDcziNf1zsgexQ5s258GknlF+QOddcDC1qmpud8Szw/7wHrqcN
QzxtcYcrbf8USFuekd+5z8GgzMC9CGn6f2Qr5eG40raLB4l+ZKNHIGyR7J0WtxHT
DcdSDmpHn5qyvAVg3NTkxgzlOnDYNpfnXzXNQ6B+QHb16d6ys4sdMwgxm0aAlzhO
voLmj5rY1CfQD6EqZmq3sqKwVYLtyHAHtzu4MoAiRGW/7Lhg6QWNiCceGw==
=b3oh
-----END PGP SIGNATURE-----
Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
* i386 fixes
* mtest2make cleanups to enable per-speed dependencies
* record/replay tracepoints
# -----BEGIN PGP SIGNATURE-----
#
# iQFIBAABCgAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmkdftoUHHBib256aW5p
# QHJlZGhhdC5jb20ACgkQv/vSX3jHroOv9Af/foJ7LXUHok8xnPrvKYEIkkVmJFpM
# dt7NzLRoyVHh/zOd/MOfOJCw2+/RLGxA7o1Mm+10DCM6+hcs9VeqeIGSElIP0Uvk
# NGau6/3l/pkE+oyDcziNf1zsgexQ5s258GknlF+QOddcDC1qmpud8Szw/7wHrqcN
# QzxtcYcrbf8USFuekd+5z8GgzMC9CGn6f2Qr5eG40raLB4l+ZKNHIGyR7J0WtxHT
# DcdSDmpHn5qyvAVg3NTkxgzlOnDYNpfnXzXNQ6B+QHb16d6ys4sdMwgxm0aAlzhO
# voLmj5rY1CfQD6EqZmq3sqKwVYLtyHAHtzu4MoAiRGW/7Lhg6QWNiCceGw==
# =b3oh
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 19 Nov 2025 09:24:58 AM CET
# gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg: issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [unknown]
# gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1
# Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83
* tag 'for-upstream' of https://gitlab.com/bonzini/qemu:
replay: add tracing events
mtest2make: do not repeat the same speed over and over
mtest2make: add dependencies to the "speed-qualified" suite
mtest2make: cleanup mtest-suites variables
target/i386: fix stack size when delivering real mode interrupts
target/i386: svm: fix sign extension of exit code
target/i386/tcg: validate segment registers
target/i386: Mark VPERMILPS as not valid with prefix 0
target/i386: emulate: Make sure fetch_instruction exist before calling it
ioapic: fix typo in irqfd check
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Missed a spot with isort, which now causes the python-minreqs test on
GitLab to fail. Fix it.
(Hint: the commands in python/tests/qapi-isort.sh can be run without the
"-c" parameter to automatically adjust import statements according to
our style rules. Maybe I should make a pre-submit hook that makes this
adjustment automatically. What do you think?)
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3200
Fixes: 5bd89761a4 ("qapi/command: Avoid generating unused qmp_marshal_output_T")
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20251118200657.1043688-4-jsnow@redhat.com>
Pylint 4.x wants to use a different regex for _Stub for some reason;
just silence this.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20251118200657.1043688-3-jsnow@redhat.com>
Pylint 4.x has refined checking for variable names that behave as
constants vs ones that do not; unfortunately our tricky import machinery
is perceived as these variables being re-assigned.
Add a temporary variable with an underscore and assign to the global
constants precisely once to alleviate this new nag message. Add an
ignore for this name for older versions of pylint that developers may
have installed locally.
(In other words: there is no solution that will cater to both pre- and
post- 4.x versions, so we target 4.x here and silence older versions.)
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20251118200657.1043688-2-jsnow@redhat.com>
The replay subsystem does not provide any way to see what's going on
and how the replay events interleave with other things happening in QEMU.
Add trace events to improve debuggability; to avoid having too many
events reimplement all functions in terms of (non-traced) replay_getc
and replay_putc and add a single trace event for each datum that is
extracted or written.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
There are just two of them (slow and thorough; quick is simply the
default). Avoid repeating them for as many times as there are tests.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Thorough tests may have more dependencies than faster ones.
Dependencies are now looked up based on the suites being
executed, not on the suites passed as goals to the makefile.
Therefore, it is possible to limit dependencies to the
speeds that need them.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Remove the "--suite" argument from the .*.mtest-suites variables, and
add it only when actually computing the arguments to "meson test".
This makes it possible to set ninja-cmd-goals from the set of suites,
instead of doing it via many different .ninja-goals.* variables.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- Re-enable xenpvh machine in qemu-system-arm/aarch64 binaries
- Correct Xilinx Zynq DMA Devcfg registers range size
- Correct ACCEL_KERNEL_GSI_IRQFD_POSSIBLE typo
- Allow for multiple CHR_EVENT_CLOSED events in QTest framework
- Fix ACMD41 state machine for SD cards in SPI mode
- Avoid confusing address calculation around eMMC RPMB HMAC
- Fix a pair of build failures on Solaris (guest-agent and RDMA migration)
- Correct QOM parent of LASI south bridge
- Clarify MIPS / PPC 32-bit hosts removal in documentation
- Prevent further uses of DEVICE_NATIVE_ENDIAN definition
- Fix Error uses in eBPF
- Update David Hildenbrand's email address
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmkcwjAACgkQ4+MsLN6t
wN7Wxg//UMbpEgp92clPcGUX1RFHViEYu5DDM96nwjLpOR8nNAJvLZ5+qxDfyZRQ
qfVGaE0cm5a/rXRMgFAzeJw5ptcSwLJXsUvnRuNLEpKlIAfqInqqk+JTi/r7hJSq
W8m07IrdtADwoas0OYKur0XwF+k1hqVOENQWPxiLiyViEH2tR8MFA+nrqQhZzgwo
Emu3ICc01wX+hhY2R51mf+GdVcmr8RACc07lmG7MnMtvQW8vzCkA/VJ5jWWQv6Xj
ADKBTciYEK/PKD5vbbwMadZfxaWRiH1l+unfpw0qXC46YOAMvpe3+0mRqk7VeSRc
anqdXQk9dbqw7qwJ+L+RVdUjNf1bLc9LxOePeMOgsNzd8wxlsBia9PDNxvVTRFmh
/JxLYO9bM4vRojaGOCFoppoF++JSdZzI6WM56hY465L3VCx36V1p2YESX8x/5F1B
+w/JPV0dUGeq+MFUNKg/pBy9dgRYIGJfcbcp2jwMxyEB5d0np53zXbMaZmqX/cEO
AjE/haqtpu/yAqSK7oklx1gJEI9gRE0cJp2B/7l/3RwW3fcMsN3HJB3GH8f+3vg2
VQMYDrAWBF5wA/5HQtsGNrfImlYGHa535KnLujTcNLVwS+2gZ6N6FwfwhM2fwXQh
+X7nQZbBsAVa0jDqck8zkIarVuISocC10DWfuP5k4hlKxeyg71M=
=K5DF
-----END PGP SIGNATURE-----
Merge tag 'hw-misc-20251118' of https://github.com/philmd/qemu into staging
Misc HW patches
- Re-enable xenpvh machine in qemu-system-arm/aarch64 binaries
- Correct Xilinx Zynq DMA Devcfg registers range size
- Correct ACCEL_KERNEL_GSI_IRQFD_POSSIBLE typo
- Allow for multiple CHR_EVENT_CLOSED events in QTest framework
- Fix ACMD41 state machine for SD cards in SPI mode
- Avoid confusing address calculation around eMMC RPMB HMAC
- Fix a pair of build failures on Solaris (guest-agent and RDMA migration)
- Correct QOM parent of LASI south bridge
- Clarify MIPS / PPC 32-bit hosts removal in documentation
- Prevent further uses of DEVICE_NATIVE_ENDIAN definition
- Fix Error uses in eBPF
- Update David Hildenbrand's email address
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmkcwjAACgkQ4+MsLN6t
# wN7Wxg//UMbpEgp92clPcGUX1RFHViEYu5DDM96nwjLpOR8nNAJvLZ5+qxDfyZRQ
# qfVGaE0cm5a/rXRMgFAzeJw5ptcSwLJXsUvnRuNLEpKlIAfqInqqk+JTi/r7hJSq
# W8m07IrdtADwoas0OYKur0XwF+k1hqVOENQWPxiLiyViEH2tR8MFA+nrqQhZzgwo
# Emu3ICc01wX+hhY2R51mf+GdVcmr8RACc07lmG7MnMtvQW8vzCkA/VJ5jWWQv6Xj
# ADKBTciYEK/PKD5vbbwMadZfxaWRiH1l+unfpw0qXC46YOAMvpe3+0mRqk7VeSRc
# anqdXQk9dbqw7qwJ+L+RVdUjNf1bLc9LxOePeMOgsNzd8wxlsBia9PDNxvVTRFmh
# /JxLYO9bM4vRojaGOCFoppoF++JSdZzI6WM56hY465L3VCx36V1p2YESX8x/5F1B
# +w/JPV0dUGeq+MFUNKg/pBy9dgRYIGJfcbcp2jwMxyEB5d0np53zXbMaZmqX/cEO
# AjE/haqtpu/yAqSK7oklx1gJEI9gRE0cJp2B/7l/3RwW3fcMsN3HJB3GH8f+3vg2
# VQMYDrAWBF5wA/5HQtsGNrfImlYGHa535KnLujTcNLVwS+2gZ6N6FwfwhM2fwXQh
# +X7nQZbBsAVa0jDqck8zkIarVuISocC10DWfuP5k4hlKxeyg71M=
# =K5DF
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 18 Nov 2025 08:00:00 PM CET
# gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [unknown]
# 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: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE
* tag 'hw-misc-20251118' of https://github.com/philmd/qemu:
ebpf: Make ebpf_rss_load() return value consistent with @errp
ebpf: Clean up useless error check in ebpf_rss_set_all()
ebpf: Fix stubs to set an error when they return failure
scripts/checkpatch: Check DEVICE_NATIVE_ENDIAN
docs: Mention 32-bit PPC host as removed
docs: Correct release of MIPS deprecations / removals
migration/rdma: Check ntohll() availability with meson
buildsys: Remove dead 'mips' entry in supported_cpus[] array
hw/southbridge/lasi: Correct LasiState parent
qga/commands: Include proper Solaris header for getloadavg()
hw/sd/sdcard: Avoid confusing address calculation in rpmb_calc_hmac
hw/arm: Re-enable xenpvh machine in qemu-system-arm/aarch64 binaries
hw/dma/zynq-devcfg: Fix register memory
hw/sd: Fix ACMD41 state machine in SPI mode
hw/sd: Fix incorrect idle state reporting in R1 response for SPI mode
system/qtest.c: Allow for multiple CHR_EVENT_CLOSED events
hw/intc/ioapic: Fix ACCEL_KERNEL_GSI_IRQFD_POSSIBLE typo
MAINTAINERS: Update David Hildenbrand's email address
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
- Multi-threading fixes in several block drivers
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmkcpowRHGt3b2xmQHJl
ZGhhdC5jb20ACgkQfwmycsiPL9bnrA/9HpvuLovahyZH+zke9FAzE9EcZ8eLgT4t
JM5ijkrfZ8KoyvW9zmUiT/T/BhewFY4if6FqIUvQoCVIQAN+Y3Z8Us/WcZpb3xG7
EMUr/CeiRl7Ka0SGbxZWR6H10Enuq4hoesfkRPXGV33CKuef09HvgE0184aazZLs
bfeBn562zUcYzn/HqNFcPqLh6goeHWhsnQuxfJJeu7i05HofeM/3T7WUcCmxhn3V
4Pk6o0toYONuZpfUZityieEI54ID95gVmllaE8QT5f0rBXHp6ae5P6x+fnqbj306
DA5RKBxM5nJ5Md2mo2tJtJ0eUNzbxXpAnT+wMkcDO4OQq8F6KngOTokPPKv13z1f
uUSwZW5QXV8pvU6AZouUlPStz0MFtfXSVqLZaV51BB7MrIGF79ina9vwMYoteTNJ
CGi32Ca0dl3PjLm//avmZiHYAeczpK34nPImRLZnhh78zQal/yDpdpi5No/tm4Yf
/0OAES0legGC3hTsuDh9sXqkmRn3qNvUd40IuDRyvrNYxMUuF+2IQymD5Hcm/6CO
uIf+/61OPHLHwKFYHyyK44XmcYQHCE0LxilmWVrNaULs4a3nvlRz3GTZ09R/ebAl
ddtedo9eHN6KfViTa95YWuu53iXzQRPUp3CrSC1gPB04zphpYsCy7eJ/t3kJqCpP
9CVf3PMOmZA=
=FNy0
-----END PGP SIGNATURE-----
Merge tag 'for-upstream' of https://repo.or.cz/qemu/kevin into staging
Block layer patches
- Multi-threading fixes in several block drivers
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCgAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmkcpowRHGt3b2xmQHJl
# ZGhhdC5jb20ACgkQfwmycsiPL9bnrA/9HpvuLovahyZH+zke9FAzE9EcZ8eLgT4t
# JM5ijkrfZ8KoyvW9zmUiT/T/BhewFY4if6FqIUvQoCVIQAN+Y3Z8Us/WcZpb3xG7
# EMUr/CeiRl7Ka0SGbxZWR6H10Enuq4hoesfkRPXGV33CKuef09HvgE0184aazZLs
# bfeBn562zUcYzn/HqNFcPqLh6goeHWhsnQuxfJJeu7i05HofeM/3T7WUcCmxhn3V
# 4Pk6o0toYONuZpfUZityieEI54ID95gVmllaE8QT5f0rBXHp6ae5P6x+fnqbj306
# DA5RKBxM5nJ5Md2mo2tJtJ0eUNzbxXpAnT+wMkcDO4OQq8F6KngOTokPPKv13z1f
# uUSwZW5QXV8pvU6AZouUlPStz0MFtfXSVqLZaV51BB7MrIGF79ina9vwMYoteTNJ
# CGi32Ca0dl3PjLm//avmZiHYAeczpK34nPImRLZnhh78zQal/yDpdpi5No/tm4Yf
# /0OAES0legGC3hTsuDh9sXqkmRn3qNvUd40IuDRyvrNYxMUuF+2IQymD5Hcm/6CO
# uIf+/61OPHLHwKFYHyyK44XmcYQHCE0LxilmWVrNaULs4a3nvlRz3GTZ09R/ebAl
# ddtedo9eHN6KfViTa95YWuu53iXzQRPUp3CrSC1gPB04zphpYsCy7eJ/t3kJqCpP
# 9CVf3PMOmZA=
# =FNy0
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 18 Nov 2025 06:02:04 PM CET
# gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6
# gpg: issuer "kwolf@redhat.com"
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* tag 'for-upstream' of https://repo.or.cz/qemu/kevin:
win32-aio: Run CB in original context
null-aio: Run CB in original AioContext
iscsi: Create AIO BH in original AioContext
block: Note in which AioContext AIO CBs are called
blkreplay: Run BH in coroutine’s AioContext
ssh: Run restart_coroutine in current AioContext
qcow2: Schedule cache-clean-timer in realtime
qcow2: Fix cache_clean_timer
qcow2: Re-initialize lock in invalidate_cache
block/io: Take reqs_lock for tracked_requests
nvme: Note in which AioContext some functions run
nvme: Fix coroutine waking
nvme: Kick and check completions in BDS context
gluster: Do not move coroutine into BDS context
curl: Fix coroutine waking
nfs: Run co BH CB in the coroutine’s AioContext
iscsi: Run co BH CB in the coroutine’s AioContext
rbd: Run co BH CB in the coroutine’s AioContext
block: Note on aio_co_wake use if not yet yielding
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
ebpf_rss_load() returns false for failure without setting an Error
when its @ctx argument already has an eBPF program loaded. This is
wrong. Fortunately, it is only called @ctx has a program. Replace
the incorrect error check by an assertion.
The return value is now obviously reliable. Change the caller to use
it, because it's more concise.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251118154718.3969982-4-armbru@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
ebpf_rss_set_all() is only called when the context has an eBPF program
loaded. Replace the dead error check with an assertion.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251118154718.3969982-3-armbru@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Stubs in ebpf_rss-stub.c return false for failure without setting an
Error. This is wrong. Callers may assume that the functions set an
error when they fail, and crash when they try to examine or report the
error. Callers may also check the error instead of the return value,
and misinterpret the failure as success.
ebpf_rss_load() and ebpf_rss_load() are reachable via
virtio_net_load_ebpf(). Fix them to set an error.
ebpf_rss_set_all() is unreachable: it can only be called when the
context has an eBPF program loaded, which is impossible with eBPF
support compiled out. Call abort() there to make that clear, and to
get rid of the latent bug.
Fixes: 00b69f1d86 (ebpf: add formal error reporting to all APIs)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251118154718.3969982-2-armbru@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
We removed support for 32-bit PPC hosts in commit 5c1ec5a1ee
("tcg/ppc: Remove support for 32-bit hosts").
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20251117171236.80472-3-philmd@linaro.org>
We are going to release 10.2, not 11.0 :)
Reported-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20251117171236.80472-2-philmd@linaro.org>
Commit 44ce1b5d2f ("migration/rdma: define htonll/ntohll
only if not predefined") tried to only include htonll/ntohll
replacements when their symbol is *defined*, but this doesn't
work, as they aren't:
../migration/rdma.c:242:17: error: static declaration of 'htonll' follows non-static declaration
242 | static uint64_t htonll(uint64_t v)
| ^~~~~~
In file included from /usr/include/netinet/in.h:73,
from /usr/include/sys/socket.h:32,
from /home/f4bug/qemu/include/system/os-posix.h:30,
from /home/f4bug/qemu/include/qemu/osdep.h:176,
from ../migration/rdma.c:17:
/usr/include/sys/byteorder.h:75:18: note: previous declaration of 'htonll' with type 'uint64_t(uint64_t)' {aka 'long unsigned int(long unsigned int)'}
75 | extern uint64_t htonll(uint64_t);
| ^~~~~~
../migration/rdma.c:252:17: error: static declaration of 'ntohll' follows non-static declaration
252 | static uint64_t ntohll(uint64_t v)
| ^~~~~~
/usr/include/sys/byteorder.h:76:18: note: previous declaration of 'ntohll' with type 'uint64_t(uint64_t)' {aka 'long unsigned int(long unsigned int)'}
76 | extern uint64_t ntohll(uint64_t);
| ^~~~~~
Better to check the symbol availability with meson.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20251117203834.83713-3-philmd@linaro.org>
Remove 'mips' from supported_cpus[], forgotten in commit
269ffaabc8 ("buildsys: Remove support for 32-bit MIPS hosts").
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20251117114200.60917-1-philmd@linaro.org>
TYPE_LASI_CHIP inherits from TYPE_SYS_BUS_DEVICE, not
TYPE_PCI_HOST_BRIDGE, so its parent structure is of
SysBusDevice type.
Cc: qemu-stable@nongnu.org
Fixes: 376b851909 ("hppa: Add support for LASI chip with i82596 NIC")
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Gustavo Romero <gustavo.romero@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20251117091804.56529-1-philmd@linaro.org>
Solaris declares getloadavg() in <sys/loadavg.h>:
getloadavg(3C) Standard C Library Functions getloadavg(3C)
NAME
getloadavg - get system load averages
SYNOPSIS
#include <sys/loadavg.h>
int getloadavg(double loadavg[], int nelem);
[...]
Oracle Solaris 11.4 23 Jul 2020 getloadavg(3C)
Include it in order to avoid:
../qga/commands-posix.c: In function 'qmp_guest_get_load':
../qga/commands-posix.c:1408:9: error: implicit declaration of function 'getloadavg' [-Wimplicit-function-declaration]
1408 | if (getloadavg(loadavg, G_N_ELEMENTS(loadavg)) < 0) {
| ^~~~~~~~~~
../qga/commands-posix.c:1408:9: warning: nested extern declaration of 'getloadavg' [-Wnested-externs]
../configure relevant output:
C compiler for the host machine: gcc (gcc 14.2.0 "gcc (GCC) 14.2.0")
C linker for the host machine: gcc ld.solaris 5.11-1.3315
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
Acked-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20251117203834.83713-2-philmd@linaro.org>
From the source frame, we initially need to copy out all fields after
data, thus starting from nonce on. Avoid expressing this indirectly by
pointing to the end of the data field - which also raised the attention
of Coverity (out-of-bound read /wrt data).
Resolves: CID 1642869
Reported-by: GuoHan Zhao <zhaoguohan@kylinos.cn>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <4f7e1952-ecbd-4484-b128-9d02de3a7935@siemens.com>
[PMD: Add comment before the memcpy() call]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
While registering the ARM/Aarch64 machine interfaces
in commit 38c5ab4003 ("hw/arm: Filter machine types
for qemu-system-arm/aarch64 binaries"), we missed the
XenPV machine. Correct that.
Reported-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Message-Id: <20251117091253.56009-1-philmd@linaro.org>
Registers are always 32 bit aligned. R_MAX is not the maximum
register address, it is the maximum register number. The memory
size can be determined by 4 * R_MAX.
Currently every register with an offset bigger than 0x40 will be
ignored, because the memory size is set wrong. This effects the
MCTRL register and makes it useless. This commit restores the
correct behaviour.
Cc: qemu-stable@nongnu.org
Fixes: 034c2e6902 ("dma: Add Xilinx Zynq devcfg device model")
Signed-off-by: YannickV <Y.Vossen@beckhoff.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251111102836.212535-9-corvin.koehne@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
In SPI mode, the ACMD41 argument only defines bit 30 (HCS); all other
bits are reserved. The current implementation incorrectly checks the
voltage window bits even in SPI mode, preventing the state machine
from transitioning to the READY state. As a result, the U-Boot
mmc-spi driver falls into an endless CMD55/ACMD41 loop.
Fixes: 3241a61a ("hw/sd/sdcard: Use complete SEND_OP_COND implementation in SPI mode")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2945
Reported-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251110110507.1641042-3-bmeng.cn@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Since commit b66f73a0 ("hw/sd: Add SDHC support for SD card SPI-mode"),
the CARD_POWER_UP bit in the OCR register has been set after reset.
Therefore, checking this bit against zero in sd_response_r1_make() to
determine the card’s idle state is incorrect in SPI mode. As a result,
QEMU makes the U-Boot mmc-spi driver believe the card never leaves the
reset state.
Fixes: 1585ab9f ("hw/sd/sdcard: Fill SPI response bits in card code")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2945
Reported-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251110110507.1641042-2-bmeng.cn@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
In the qtest_event() QEMUChrEvent handler, we create a timer
and log OPENED on CHR_EVENT_OPENED, and we destroy the timer and
log CLOSED on CHR_EVENT_CLOSED. However, the chardev subsystem
can send us more than one CHR_EVENT_CLOSED if we're reading from
a file chardev:
* the first one happens when we read the last data from the file
* the second one happens when the user hits ^C to exit QEMU
and the chardev is finalized: char_fd_finalize()
This causes us to call g_timer_elapsed() with a NULL timer
(which glib complains about) and print an extra CLOSED log line
with a zero timestamp:
[I +0.063829] CLOSED
qemu-system-aarch64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed
[I +0.000000] CLOSED
Avoid this by ignoring a CHR_EVENT_CLOSED if we have already
processed one.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20251107174306.1408139-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Commit 638ac1c784 introduced a regression in interrupt remapping
when running a VM configured with an intel-iommu device and an
assigned PCI VF. During boot, Linux reports repeated messages :
[ 15.416794] __common_interrupt: 2.37 No irq handler for vector
[ 15.417266] __common_interrupt: 2.37 No irq handler for vector
[ 15.417733] __common_interrupt: 2.37 No irq handler for vector
[ 15.418202] __common_interrupt: 2.37 No irq handler for vector
[ 15.418670] __common_interrupt: 2.37 No irq handler for vector
and may eventually hang.
The issue is caused by the incorrect use of the macro
ACCEL_KERNEL_GSI_IRQFD_POSSIBLE, which should instead be
ACCEL_GSI_IRQFD_POSSIBLE.
Fixes: 638ac1c784 ("hw/intc: Generalize APIC helper names from kvm_* to accel_*")
Cc: Magnus Kulke <magnuskulke@linux.microsoft.com>
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251106105148.737093-1-clg@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Switch to kernel.org email address as I will be leaving Red Hat. The
old address will remain active until end of January 2026, so performing
the change now should make sure that most mails will reach me.
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: David Hildenbrand (Red Hat) <david@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251103103947.384401-1-david@kernel.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
AIO callbacks must be called in the originally calling AioContext,
regardless of the BDS’s “main” AioContext.
Note: I tried to test this (under wine), but failed. Whenever I tried
to use multiqueue or even just an I/O thread for a virtio-blk (or
virtio-scsi) device, I/O stalled, both with and without this patch.
For what it’s worth, when not using an I/O thread, I/O continued to work
with this patch.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-20-hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
AIO callbacks must be called in the originally calling AioContext,
regardless of the BDS’s “main” AioContext.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-19-hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
AIO callbacks must be called in the original request’s AioContext,
regardless of the BDS’s “main” AioContext.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-18-hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
This doesn’t seem to be specified anywhere, but is something we probably
want to be clear. I believe it is reasonable to implicitly assume that
callbacks are run in the current thread (unless explicitly noted
otherwise), so codify that assumption.
Some implementations don’t actually fulfill this contract yet. The next
patches should rectify that.
Note: I don’t know of any user-visible bugs produced by not running AIO
callbacks in the original context. AIO functionality is generally
mapped to coroutines through the use of bdrv_co_io_em_complete(), which
can run in any AioContext, and will always wake the yielding coroutine
in its original context. The only benefit here is that running
bdrv_co_io_em_complete() in the original context will make that
aio_co_wake() most likely a simpler qemu_coroutine_enter() instead of
scheduling the wakeup through AioContext.co_schedule_bh.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-17-hreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
While it does not matter in which AioContext we run aio_co_wake() to
continue an exactly-once-yielding coroutine, making this commit not
strictly necessary, there is also no reason why the BH should run in any
context but the request’s AioContext.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-16-hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
restart_coroutine() is attached as an FD handler just to wake the
current coroutine after yielding. It makes most sense to attach it to
the current (request) AioContext instead of the BDS main context. This
way, the coroutine can be entered directly from the BH instead of having
yet another indirection through AioContext.co_schedule_bh.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-15-hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
There is no reason why the cache cleaning timer should run in virtual
time, run it in realtime instead.
Suggested-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-14-hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The cache-cleaner runs as a timer CB in the BDS AioContext. With
multiqueue, it can run concurrently to I/O requests, and because it does
not take any lock, this can break concurrent cache accesses, corrupting
the image. While the chances of this happening are low, it can be
reproduced e.g. by modifying the code to schedule the timer CB every
5 ms (instead of at most once per second) and modifying the last (inner)
while loop of qcow2_cache_clean_unused() like so:
while (i < c->size && can_clean_entry(c, i)) {
for (int j = 0; j < 1000 && can_clean_entry(c, i); j++) {
usleep(100);
}
c->entries[i].offset = 0;
c->entries[i].lru_counter = 0;
i++;
to_clean++;
}
i.e. making it wait on purpose for the point in time where the cache is
in use by something else.
The solution chosen for this in this patch is not the best solution, I
hope, but I admittedly can’t come up with anything strictly better.
We can protect from concurrent cache accesses either by taking the
existing s->lock, or we introduce a new (non-coroutine) mutex
specifically for cache accesses. I would prefer to avoid the latter so
as not to introduce additional (very slight) overhead.
Using s->lock, which is a coroutine mutex, however means that we need to
take it in a coroutine, so the timer must run in a coroutine. We can
transform it from the current timer CB style into a coroutine that
sleeps for the set interval. As a result, however, we can no longer
just deschedule the timer to instantly guarantee it won’t run anymore,
but have to await the coroutine’s exit.
(Note even before this patch there were places that may not have been so
guaranteed after all: Anything calling cache_clean_timer_del() from the
QEMU main AioContext could have been running concurrently to an existing
timer CB invocation.)
Polling to await the timer to actually settle seems very complicated for
something that’s rather a minor problem, but I can’t come up with any
better solution that doesn’t again just overlook potential problems.
(Not Cc-ing qemu-stable, as the issue is quite unlikely to be hit, and
I’m not too fond of this solution.)
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-13-hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
After clearing our state (memset()-ing it to 0), we should
re-initialize objects that need it. Specifically, that applies to
s->lock, which is originally initialized in qcow2_open().
Given qemu_co_mutex_init() is just a memset() to 0, this is functionally
a no-op, but still seems like the right thing to do.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-12-hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
bdrv_co_get_self_request() does not take a lock around iterating through
bs->tracked_requests. With multiqueue, it may thus iterate over a list
that is in the process of being modified, producing an assertion
failure:
../block/file-posix.c:3702: raw_do_pwrite_zeroes: Assertion `req' failed.
[0] abort() at /lib64/libc.so.6
[1] __assert_fail_base.cold() at /lib64/libc.so.6
[2] raw_do_pwrite_zeroes() at ../block/file-posix.c:3702
[3] bdrv_co_do_pwrite_zeroes() at ../block/io.c:1910
[4] bdrv_aligned_pwritev() at ../block/io.c:2109
[5] bdrv_co_do_zero_pwritev() at ../block/io.c:2192
[6] bdrv_co_pwritev_part() at ../block/io.c:2292
[7] bdrv_co_pwritev() at ../block/io.c:2225
[8] handle_alloc_space() at ../block/qcow2.c:2573
[9] qcow2_co_pwritev_task() at ../block/qcow2.c:2625
Fix this by taking reqs_lock.
Cc: qemu-stable@nongnu.org
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-11-hreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Sprinkle comments throughout block/nvme.c noting for some functions
(where it may not be obvious) that they require a certain AioContext, or
in which AioContext they do happen to run (for callbacks, BHs, event
notifiers).
Suggested-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-10-hreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
nvme wakes the request coroutine via qemu_coroutine_enter() from a BH
scheduled in the BDS AioContext. This may not be the same context as
the one in which the request originally ran, which would be wrong:
- It could mean we enter the coroutine before it yields,
- We would move the coroutine in to a different context.
(Can be reproduced with multiqueue by adding a usleep(100000) before the
`while (data.ret == -EINPROGRESS)` loop.)
To fix that, use aio_co_wake() to run the coroutine in its home context.
Just like in the preceding iscsi and nfs patches, we can drop the
trivial nvme_rw_cb_bh() and use aio_co_wake() directly.
With this, we can remove NVMeCoData.ctx.
Note the check of data->co == NULL to bypass the BH/yield combination in
case nvme_rw_cb() is called from nvme_submit_command(): We probably want
to keep this fast path for performance reasons, but we have to be quite
careful about it:
- We cannot overload .ret for this, but have to use a dedicated
.skip_yield field. Otherwise, if nvme_rw_cb() runs in a different
thread than the coroutine, it may see .ret set and skip the yield,
while nvme_rw_cb() will still schedule a BH for waking. Therefore,
the signal to skip the yield can only be set in nvme_rw_cb() if waking
too is skipped, which is independent from communicating the return
value.
- We can only skip the yield if nvme_rw_cb() actually runs in the
request coroutine. Otherwise (specifically if they run in different
AioContexts), the order between this function’s execution and the
coroutine yielding (or not yielding) is not reliable.
- There is no point to yielding in a loop; there are no spurious wakes,
so once we yield, we will only be re-entered once the command is done.
Replace `while` by `if`.
Cc: qemu-stable@nongnu.org
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-9-hreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
nvme_process_completion() must run in the main BDS context, so schedule
a BH for requests that aren’t there.
The context in which we kick does not matter, but let’s just keep kick
and process_completion together for simplicity’s sake.
(For what it’s worth, a quick fio bandwidth test indicates that on my
test hardware, if anything, this may be a bit better than kicking
immediately before scheduling a pure nvme_process_completion() BH. But
I wouldn’t take more from those results than that it doesn’t really seem
to matter either way.)
Cc: qemu-stable@nongnu.org
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-8-hreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The request coroutine may not run in the BDS AioContext. We should wake
it in its own context, not move it.
With that, we can remove GlusterAIOCB.aio_context.
Also add a comment why aio_co_schedule() is safe to use in this way.
**Note:** Due to a lack of a gluster set-up, I have not tested this
commit. It seemed safe enough to send anyway, just maybe not to
qemu-stable. To be clear, I don’t know of any user-visible bugs that
would arise from the state without this patch; the request coroutine is
moved into the main BDS AioContext, so guest device completion code will
run in a different context than where the request started, which can’t
be good, but I haven’t actually confirmed any bugs (due to not being
able to test it).
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-7-hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
If we wake a coroutine from a different context, we must ensure that it
will yield exactly once (now or later), awaiting that wake.
curl’s current .ret == -EINPROGRESS loop may lead to the coroutine not
yielding if the request finishes before the loop gets run. To fix it,
we must drop the loop and yield exactly once, if we need to yield.
Finding out that latter part ("if we need to yield") makes it a bit
complicated: Requests may be served from a cache internal to the curl
block driver, or fail before being submitted. In these cases, we must
not yield. However, if we find a matching but still ongoing request in
the cache, we will have to await that, i.e. still yield.
To address this, move the yield inside of the respective functions:
- Inside of curl_find_buf() when awaiting ongoing concurrent requests,
- Inside of curl_setup_preadv() when having created a new request.
Rename curl_setup_preadv() to curl_do_preadv() to reflect this.
(Can be reproduced with multiqueue by adding a usleep(100000) before the
`while (acb.ret == -EINPROGRESS)` loop.)
Also, add a comment why aio_co_wake() is safe regardless of whether the
coroutine and curl_multi_check_completion() run in the same context.
Cc: qemu-stable@nongnu.org
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20251110154854.151484-6-hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Peter Xu
Markus Armbruster
Matthew Rosato
Li Zhijian
Richard Henderson
John Snow
Paolo Bonzini
Djordje Todorovic
Philippe Mathieu-Daudé
Jan Kiszka
Yannick Voßen
Bin Meng
Peter Maydell
Cédric Le Goater
David Hildenbrand (Red Hat)
Hanna Czenczek