NBD patches through 2026-10-08
Several fixes, including:
- Eric Blake: Update MAINTAINERS, support qemu-nbd -s -l
- Fiona Ebner: Report flush error on qemu-img convert
- Denis V. Lunev: Fix postcopy dirty bitmap migration
- Eric Farman: Several iotest improvements
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCAAdFiEEccLMIrHEYCkn0vOqp6FrSiUnQ2oFAmrSQYoACgkQp6FrSiUn
# Q2qilAf/eEx7WDxnMW9/xNQ0xwFCJFfcwF7alPfORNS/tTQk+a1CpvvXVXqWNGc1
# JIBQQtCbBteGh6QOlHE1uedZpeURgWluaOa3ZOmjWoB8xCo9iIz66lvMmV4+OaJM
# iTn1ExR/rFGFoNu73S5+Zbusc3znWrClZmYIw1XPfM3pgol8HIz68q284oqkkMQ+
# ddo1GnWbsZKd1e+90A0mZTFrqFEcUZiVaUbY+NCxo/OYFUwNGSxg/+QMIASJbv6H
# zDUrs1+oC1d0qiaM8Rg6/V4dgfSsgxd4t0k+h5r1mJIQT9spevz6/2R44bAinPso
# Mirbenl/KVOk30lvNAiQRRta8KsTVQ==
# =iDnD
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 16 Oct 2026 05:23:54 PM CEST
# gpg: using RSA key 71C2CC22B1C4602927D2F3AAA7A16B4A2527436A
# gpg: Good signature from "Eric Blake <eblake@redhat.com>" [unknown]
# gpg: aka "Eric Blake (Free Software Programmer) <ebb9@byu.net>" [unknown]
# gpg: aka "[jpeg image of size 6874]" [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: 71C2 CC22 B1C4 6029 27D2 F3AA A7A1 6B4A 2527 436A
* tag 'pull-nbd-2026-10-08-v4' of https://gitlab.com/ebblake/qemu:
iotests/iothreads-nbd-export: Skip on s390
iotests/fuse-truncate: skip if FUSE is not usable
iotests/nbd-tls-iothread: skip on non-x86 hardware
iotests/nbd-in-qcow2-chain: use default machine
iotests/migrate-bitmaps-postcopy-test: add a bitmap on a second node
migration/block-dirty-bitmap: fix postcopy abort with bitmaps on several nodes
migration: add QEMU_COUNTED_STRING_SIZE for counted string buffers
qemu-img: convert: flush target image after copying
block: report flush error during bdrv_close()
iotests.py: add filter_qemu()
iotests: add test cases for failing flush after qemu-img convert
qemu-nbd: Support -s and -l at the same time
maint: Update eblake's staging repo
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
With dirty bitmaps on more than one node, the source switches nodes
during the postcopy bulk phase and sends the node name again. The
destination reads those chunks in the postcopy listen thread, which does
not hold the BQL, and resolves the name through bdrv_lookup_bs():
qemu-system-x86_64: ../block.c:6400: bdrv_lookup_bs: Assertion
`qemu_in_main_thread()' failed.
The bdrv_find_dirty_bitmap() call right after it needs the BQL or the
dirty bitmap lock as well. Taking the BQL there would deadlock: the
listen thread holds s->lock, and dirty_bitmap_mig_before_vm_start()
takes s->lock with the BQL held.
Every node and bitmap that a non-START chunk refers to was set up by a
START chunk, and those are loaded under the BQL during setup. Record the
node alias there, and resolve all other chunks against s->bitmaps
instead of the block graph.
Bitmaps on a single node never resend the node name after setup, which
is why migrate-bitmaps-postcopy-test does not catch this.
Fixes: f791bf7f93 ("assertions for block global state API")
Signed-off-by: Denis V. Lunev <den@openvz.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Fabiano Rosas <farosas@suse.de>
Cc: Eric Blake <eblake@redhat.com>
Cc: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: qemu-stable@nongnu.org
Message-ID: <20261006170738.453977-3-den@openvz.org>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
This reverts commit eb3618e9e2.
The workaround for the GNUTLS bug was not correct and it was
decided to rely on GNUTLS being patched by distros instead,
or users manually disabling use of the problematic ciphers.
Acked-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Use the recently introduced migrate_params_free routine at
migration_instance_finalize() so that newly added pointers are already
freed by default.
Special case: The TLS options are currently the only pointers that
also have a qdev property implementation, so they will be freed by
qdev using the .release method. Update the method so that a second
invocation of qapi_free_StrOrNull doesn't assert.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Expecting every pointer member from s->parameters to be freed
individually is prone to leave some fields forgotten when the code is
eventually updated. Use a dealloc visitor to free them all at once.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Remove migrate_params_apply so the logic of setting migration
parameters is all in one spot.
Suggested-by: Prasad Pandit <ppandit@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Convert the code in migrate_params_test_apply() from an open-coded
copy of every migration parameter to a merge operation using QAPI
visitors and QDict.
The purpose of that routine is to update a temporary structure
(pre-populated with the current migration parameters), with the values
received from the user via QAPI. As a result, the temporary structure
will then contain the "to be applied" parameters and it's validated
before being used to overwrite the parameters currently in use.
The update is currently done as follows:
where 'params' is the user input from QAPI,
for each parameter:
a) check if the option is present
params->has_<name> == true
params-><name> != NULL // for strings
b) if the parameter is a pointer, free the to-be-assigned member and
allocate memory for the copy from params
c) assign the user provided value to the temporary structure.
Step (a) is the same in principle as what the QAPI visitors do at
visit_type_MigrationParameters_members().
Steps (b) and (c) are roughly the same as what the QDict
implementation does when qdict_del() and qdict_put_obj() are combined.
Therefore, replace the open-coded function with
migrate_params_merge(), which achieves the same goal, but uses
visitors and QDict. This hides the details of QAPI (has_*) from the
migration code and avoids the need to update
migrate_params_test_apply() every time a new migration parameter is
added.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Instead of setting parameters one by one, use the temporary object,
which already contains the current migration parameters plus the new
ones and was just validated by migration_params_check(). Use cloning
to overwrite it.
This avoids the need to alter this function every time a new parameter
is added.
Since parameters are not individually checked anymore, the setting of
s->has_block_bitmap_mapping moves into migrate_post_update_params().
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Prasad Pandit <pjp@fedoraproject.org>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Give the variables in qmp_migrate_set_parameters more semantic
names.
s/params/input/
this is the user input from qapi
s/tmp/new/
this is the combination of the current parameters and the input
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
The migrate_tls_opts_free function was never used outside
options.c. Make it static.
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
After the per-chunk write wait is removed, transit_bitmap is no longer
read. The remaining set and clear operations only maintain unused
state.
Remove the bitmap and simplify the block lifecycle tracepoints.
Signed-off-by: Yanfei Xu <yanfei.xu@bytedance.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Tested-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
qemu_rdma_write_one() waits for an earlier write that shares the same
registration chunk, even when the dirty ranges do not overlap. This
serializes sparse writes and leaves send queue capacity unused.
RAM round notifiers now provide the completion barrier before a newer
page version can be sent, and the obsolete unregister path no longer
requires per-chunk serialization. Remove the wait. The global nb_sent
count continues to manage CQ and send queue resources.
Signed-off-by: Yanfei Xu <yanfei.xu@bytedance.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Tested-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
rdma_registration_stop() runs after every ram_save_iterate() call, which
can stop before a complete RAM scan because of rate limiting. Draining
there ties the completion barrier to a SaveVM section rather than the
point where the scan wraps and a newer page version can be sent.
Register an RDMA RAM round notifier that drains all outstanding writes.
Keep posting the buffered tail in rdma_registration_stop() so it remains
ordered before REGISTER_FINISHED.
Signed-off-by: Yanfei Xu <yanfei.xu@bytedance.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Tested-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
find_dirty_block() directly invokes multifd's per-round synchronization
when the RAM scan wraps. Other transports need the same boundary to
order page versions.
Add a return-valued notifier for RAM round completion and register
multifd's existing synchronization through it. This keeps the current
behavior while allowing other transports to synchronize at the same
boundary.
Signed-off-by: Yanfei Xu <yanfei.xu@bytedance.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Tested-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
RAM writes and control messages share the send queue. If outstanding
writes fill it, RDMA writes drain a completion and retry, but control
sends fail the migration.
Move send posting and queue-full handling into a common helper. On
ENOMEM, drain one outstanding RDMA write and retry the failed request
once. If no write is outstanding, or the retry still fails, propagate
the error.
Signed-off-by: Yanfei Xu <yanfei.xu@bytedance.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
The source return-path thread can send READY before the destination has
posted its initial receive. Since RNR retries default to zero, the send
can fail and abort migration.
Post the initial receive before rdma_accept() to close this window.
Adding delays can easily reproduce it. For exmaple with sleep(1), error
could be found at the source side:
2026-08-20T05:55:11.471421Z qemu_rdma_exchange_get_response_start CONTROL: READY receiving...
2026-08-20T05:55:11.471422Z qemu_rdma_post_send_control CONTROL: sending QEMU FILE..
2026-08-20T05:55:11.471447Z qemu_rdma_poll_other other completion 2000 received left 0
2026-08-20T05:55:11.471589Z qemu_rdma_poll_recv completion 0 received (4000) left 0
2026-08-20T05:55:11.471592Z qemu_rdma_poll_other other completion 4000 received left 0
2026-08-20T05:55:11.471594Z qemu_rdma_exchange_get_response_start CONTROL: READY receiving...
2026-08-20T05:55:11.471596Z qemu_rdma_post_send_control CONTROL: sending QEMU FILE..
2026-08-20T05:55:11.471617Z qemu_rdma_poll_other other completion 2000 received left 0
2026-08-20T05:55:11.705561Z qemu_rdma_close
2026-08-20T05:55:11.705587Z qemu_rdma_close
2026-08-20T05:55:11.705626Z qemu-system-x86_64: rdma migration: send polling control error
2026-08-20T05:55:11.707001Z qemu-system-x86_64: warning: Early error. Sending error.
2026-08-20T05:55:11.707031Z qemu_rdma_post_send_control CONTROL: sending ERROR..
2026-08-20T05:55:11.707038Z qemu-system-x86_64: warning: rdma migration: send polling control error
2026-08-20T05:55:11.707301Z qemu_rdma_cleanup_disconnect
2026-08-20T05:55:11.710569Z qemu_rdma_cleanup_disconnect
Fixes: 55cc1b5937 ("migration: create a dedicated connection for rdma return path")
Signed-off-by: Yanfei Xu <yanfei.xu@bytedance.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
qio_channel_rdma_shutdown() reads rdmain for both the input and
output contexts. As a result, a write-side shutdown marks the input
context as errored while leaving the output context active. A shutdown
of both directions also fails to stop the output context.
Read rdmaout from the output context so each shutdown direction marks
the corresponding RDMA context as errored.
Fixes: 54db882f07 ("migration: implement the shutdown for RDMA QIOChannel")
Signed-off-by: Yanfei Xu <yanfei.xu@bytedance.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Reviewed-by: Li Zhijian <lizhijian@fujitsu.com>
Tested-by: Lukas Straub <lukasstraub2@web.de>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
pci, vhost, virtio, iommu, apci: features, fixes
new vhost-user-media device
virtio-net now supports live-TAP local migration
cxl now supports CFMW restrictions and per-window options
intel_iommu now supports concurrent page fault handling with PRI
pci now batches memory transactions around mapping updates
vhost-user-blk now allows toggling inflight-migration at runtime
virtio-rtc now supports smeared UTC clock type
intel_iommu now exposes SMPWC when SVM is enabled
new reviewer for CXL patches
Fixes, cleanups all over the place
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQFDBAABCgAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmqkXRUPHG1zdEByZWRo
# YXQuY29tAAoJECgfDbjSjVRpoWsH/jeMRFjgYu5Es05ha87JW6NJW6j/Ggw3F8e5
# kup/SsoeqX+pK1VqXkKimWRf0iXsnweTqviVR88KMmMBP9UNdwgRBM7XflplYiOv
# UOsjZGZAKjOKnyjbQyNihYY4CfaJn2VYkxJBRxweS3/OEK4JV2wmFcWEjFuZEdJT
# SXpYXAPu0e8XTPVk/+bhi6kIYHhsuu1sWhcsoRDGdw5ZrGvwTwF8cS4SWaYHrWc1
# wjvC39P3Hg+Zvw6vDkPP2Amos2s6iheEgsPI0628YYvER+YV641YD48xEXqTG44e
# FGwCihJ97rYYGQEwL+1FL4ZLKcp7HwacqxkJYg+GHbKj1Iog9OQ=
# =9H6A
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 11 Sep 2026 09:57:09 AM HST
# gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469
# gpg: issuer "mst@redhat.com"
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [unknown]
# gpg: aka "Michael S. Tsirkin <mst@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: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (74 commits)
MAINTAINERS: add Junjie Cao as CXL reviewer
vhost-user-blk: use GET_VRING_BASE_SKIP_DRAIN when inflight-migration is on
vhost-user-blk: move inflight_needed higher
vhost-user-blk: make inflight-migration prop mutable on running vm
vhost-user: use skip_drain with GET_VRING_BASE_SKIP_DRAIN message
vhost-user: add GET_VRING_BASE_SKIP_DRAIN message
vhost-user: add skip_drain param to do_vhost_virtqueue_stop
intel_iommu: Expose SMPWC when SVM is enabled
virtio-net: validate IHL in virtio_net_rsc_extract_unit4 before use
net/tap-solaris: Fix resource leaks on error paths
hw/hotplug: Constify HotplugHandler
hw/hotplug: Reduce some HotplugHandler variables scope
hw/hotplug: Mark various HotplugHandlerClass variables as const
hw/acpi: Make AcpiGedState const in build_ged_aml()
pci: load a device's config inside one memory transaction
pci: batch BAR remapping into one memory transaction
intel_iommu: Always write all the flags passed to vtd_set_flag_in_pte
intel_iommu: Only set dirty bit when PTE exposes write permission
intel_iommu: Support concurrent page fault handling with PRI
virtio-rtc: Report smeared UTC clock type
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
As documented, for "local", the migration channel must be direct UNIX
socket connection from source to target (except for CPR_EXEC mode). We
can't check for it being "direct", but let's at least check that we deal
with UNIX socket.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260819180201.1970193-13-vsementsov@yandex-team.ru>
We are going to implement local-migration feature: some devices will be
able to transfer open file descriptors through migration stream (which
must UNIX domain socket for that purpose). This allows to transfer the
whole backend state without reconnecting and restarting the backend
service. For example, virtio-net will migrate its attached TAP netdev,
together with its connected file descriptors.
In this commit we introduce a migration parameter, which enables
the feature for devices that support it (none at the moment).
We can't simply auto-detect local migration by checking whether the
migration channel is a UNIX domain socket: the UNIX socket may be only
the first part of the transfer channel to a remote target. Hence an
explicit parameter is needed. Moreover, "local" migration parameter
may be useful in cpr-exec mode, when FDs are passed through exec
instead of UNIX socket.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Acked-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260819180201.1970193-10-vsementsov@yandex-team.ru>
The JSON writer is created at migrate_init() and freed at
migration_cleanup(). The latter is not called for snapshots. Add a
call to migration_cleanup_json_writer() to make sure it doesn't leak:
Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x55ca12aabca0 in malloc
#1 0x7fd97d7e595d in g_malloc
#2 0x7fd97d7ffe38 in g_slice_alloc
#3 0x7fd97d8042e2 in g_string_sized_new
#4 0x55ca1571dd6b in json_writer_new ../qobject/json-writer.c:36:24
#5 0x55ca12e0de56 in migrate_init ../migration/migration.c:1718:21
#6 0x55ca12ec8fe6 in qemu_savevm_state ../migration/savevm.c:1921:11
#7 0x55ca12ec8b93 in save_snapshot ../migration/savevm.c:3380:11
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
During migration there are usually two references to the iochannel,
one from the channel creation itself and another from the ownership
transfer into QEMUFile.
- The reference from the QEMUFile is decremented at qemu_fclose.
- The original reference is decremented at migration_connect_outgoing()
for regular migration and not at all for snapshots.
The ide-test has recently added migration support and ASAN has
flagged:
Indirect leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x55ca12aac0b9 in realloc
#1 0x7fd97d7e5a05 in g_realloc
#3 0x7fd97d7c98c6 in g_hash_table_new_full
#4 0x55ca14e186f1 in object_initialize_with_type ../qom/object.c:506:23
#5 0x55ca14e1a590 in object_new_with_type ../qom/object.c:706:5
#6 0x55ca14e1a7e8 in object_new ../qom/object.c:722:12
#7 0x55ca12de896f in qio_channel_block_new ../migration/channel-block.c:32:29
#8 0x55ca12ec8f2d in qemu_fopen_bdrv ../migration/savevm.c:172:49
#9 0x55ca12ec8b42 in save_snapshot ../migration/savevm.c:3375:9
#10 0x55ca12ee18e3 in hmp_savevm ../migration/migration-hmp-cmds.c:497:5
Change qemu_fopen_bdrv() to drop the original reference once the
QEMUFile has taken over the object. The xen code already does the
same.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Add #ifdef CONFIG_HMP around all hmp_* function implementations and
their HMP-only helpers across subsystems.
This covers monitor_register_hmp* callers, hmp_info_* handlers, and
HMP-only helper functions like slirp_lookup.
To link succesfully, use empty cmds tables in hmp-cmds.c (to be removed
once meson build-sys is updated with !hmp support later in the series)
Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260828-qemu-no-hmp-v5-41-9227de146347@redhat.com>
Rename monitor_printf->monitor_hmp_printf, monitor_vprintf->
monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changing
the first parameter from Monitor * to MonitorHMP * to enforce type
safety. The implementation is also simplified: monitor_hmp_vprintf now
directly calls g_strdup_vprintf + monitor_puts, removing the virtual
dispatch via moncls->vprintf.
The dev_print() callbacks are temporarily using the MONITOR_HMP(mon)
cast, they are fixed in the following commits.
Early return in qemu_vprintf() if "hmp" is NULL, relying on
monitor_hmp_vprintf() handling NULL case is a bit uncommon.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260828-qemu-no-hmp-v5-37-9227de146347@redhat.com>
HMP commands are specific to the HMP monitor, so make the cmd function
pointer in HMPCommand take MonitorHMP * instead of Monitor *. This
strengthens type safety and makes the HMP-specific nature of these
handlers explicit.
Handler functions are renamed to take MonitorHMP *hmp, with a local
Monitor *mon = MONITOR(hmp) added where the body needs the base type.
Following patches will drop it, since most functions are HMP specific.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com>
Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260828-qemu-no-hmp-v5-31-9227de146347@redhat.com>
With postcopy-preempt enabled, a postcopy migration of a guest with a
vhost-user device can hang at the very end on the destination, after all
pages are transferred (query-migrate: status=postcopy-active, remaining=0).
Root cause is an add/del key mismatch on mis->page_requested:
- add: a backend fault goes through postcopy_request_shared_page() ->
postcopy_request_page() -> migrate_send_rp_req_pages(), which inserts
the request and bumps page_requested_count keyed by client_addr.
- del: qemu_ufd_copy_ioctl() removes the entry and drops the counter
keyed by this QEMU process's host address for the page.
client_addr is a VA in the external vhost-user backend's address space and
never equals QEMU's host address, so the removal misses and the counter
leaks. postcopy_ram_incoming_cleanup() then waits for it to reach zero
forever, which also stalls the source (it waits for the return path).
Racing threads:
dst: postcopy_ram_listen_thread -> postcopy_ram_incoming_cleanup ->
qemu_cond_wait_impl (waits for page_requested_count==0)
(postcopy_preempt_thread already placed/woke the pages)
src: migration_thread -> migration_completion ->
await_return_path_close_on_source -> qemu_thread_join
(source_return_path_thread blocked in recvmsg)
The leak is only triggered when the vhost-user backend faults on a page
that has not been received yet: only then does the request take the
shared-fault slow path and register an entry in page_requested. If that
page is subsequently delivered while the request is still outstanding,
its entry is never removed. (Pages already present when the backend
faults just take the wake path and never register.) So a run may leak
only a few entries (9 of ~244k requests in our repro) yet still hang.
Fix: key the request with the same host address the removal uses
(rb->host + aligned_rbo) instead of client_addr. The backend wake still
happens at placement time via postcopy_wake_shared().
Signed-off-by: hongmianquan <hongmianquan@bytedance.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Protect vmstate_size against overflow of the on-stack 64bit integer
during multiplication. The data at size_indirect.offset comes from the
migration stream.
Acked-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Harden the vmstate_handle_alloc function against overflow of the 64bit
integers it consumes and failure to allocate due to an exceedingly
large request.
Acked-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
There are a few special cases of vmstate usage:
The vmstate_msix and vmstate_scsi_device have fields that contain no
data, only a vmstate_info structure.
The VMSTATE_VALIDATE macro serves only to invoke the .field_exists
routine for validation.
Regardless whether these scenarios are valid, add a separate flag to
identify them so we can enforce common constraints for the normal
vmstates such as having a size greater than zero.
Note that n_elems is hardcoded to 1 for all vmstates, except
VMS_[V]ARRAY, so VMSTATE_VALIDATE needed to set VMS_ARRAY to be able
to force n_elems to 0. This patch now checks the flag at
vmstate_n_elems().
Acked-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Remove the VMS_VARRAY and VMS_VBUFFER flags that became redundant due
to the previous commit which stores the size of the vmstate offset
variables along with the offset itself.
Acked-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
When migrating a buffer or array, the vmstate code needs to know the
size of the buffer and the number of elements of the array. Today a
vmstate writer can choose from a number of macros that take as last
input the name of a struct member from where the size/num will be
read.
At load time, the code will access those values via an opaque pointer
to the migrated data and therefore it needs to also know the size of
the struct member at that offset.
Currently that information is communicated by means of the
VMS_VARRAY_* and VMS_VBUFFER_* flags, where each possible type is
represented by a flag.
So far, that's all fine, but since the vmstate code makes heavy use of
macros, handling several types individually (i.e. by name: int,
int32_t, etc) requires several versions of a same macro, one for each
type. E.g: VMSTATE_VBUFFER_ALLOC_UINT32
^
This creates a pattern where the vmstate writer has to match the macro
name to the data type and has resulted in the code having a tendency
of having one macro version for each type, for each type of vmstate.
There is also some cognitive load to deal with, e.g.
VMSTATE_VARRAY_INT32 doesn't hold an array of int32, it holds an array
of something else and the number of elements for the array is stored
in a variable of type int32.
We're now dealing with the scenario where the code has been expecting
int32_t at some places, but a uint64_t macro variant has been added
without the code being updated.
To address all these situations, introduce a new struct that will hold
the offset of the struct members, but also their size, so the various
extra macros can all be removed and the person writing the vmstate
doesn't need to care about type-checking. Still, keep a minimum check
that those fields are at least integers and fit into 64 bits.
What changes:
1) type checking changes from individual types to a single check for
all integers;
2) there are new ways to access the offsets;
num_offset -> num_indirect.offset
size_offset -> size_indirect.offset
[new] num_indirect.size
[new] size_indirect.size
2) reading the offsets goes from checking the VMS_VARRAY_* flags in an
if/elseif block to comparing offset.size against the hardcoded
sizes in bytes;
3) the VMS_VARRAY_* and VMS_VBUFFER_* flags become obsolete. Removed
in the next patch;
4) memory usage increases +1 byte per vmstate;
Reported-by: Seungjung Kim <seungjung0711@gmail.com>
Fixes: CVE-2026-6426
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3675
Acked-by: Peter Xu <peterx@redhat.com>
[fixed up vmstate_read_from_offset to work on BE host]
Signed-off-by: Fabiano Rosas <farosas@suse.de>
The value received on wire for head.chunks when registering new RDMA
regions is not correctly checked. Logically the value can still make
ram_chunk_start() (of ram_chunk_end()) to overflow, having a result pointer
very small, smaller than RDMALocalBlock.local_host_addr.
Add the sanity check.
Reported-by: Tristan (@TristanInSec)
Closes: https://gitlab.com/qemu-project/qemu/-/work_items/4011
Reviewed-by: Jinpu Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
RDMA header supports head.repeat on RDMA_CONTROL_REGISTER_REQUEST, which
can include >1 memory registrations. The current code did check over
head.repeat to guard against RDMA_CONTROL_MAX_COMMANDS_PER_MESSAGE, however
it didn't further check the buffer size (head.len) to make sure the
received data is large enough to include the repeated entries. Check it.
This is almost only to harden this piece of code, in reality on source side
QEMU never uses repeat>1.. However since it's a protocol, still keep it.
Check the buffer size instead.
In case it's not obvious to new RDMA readers: head.len should be the size
RDMA has last received, as qemu_rdma_exchange_get_response() checked on it
against byte_len (which was further fetched from ibv_wc.byte_len in
qemu_rdma_poll()).
Reported-by: Tristan (@TristanInSec)
Closes: https://gitlab.com/qemu-project/qemu/-/work_items/4028
Reviewed-by: Jinpu Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
This is guaranteed to be true. There seems to have support for some
dynamically allocated buffers but it was never really supported. Remove
dead code.
As a side effect, this patch closes a report by removing the buggy code
completely.
Reported-by: Tristan (@TristanInSec)
Closes: https://gitlab.com/qemu-project/qemu/-/work_items/4006
Reviewed-by: Jinpu Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
There're a bunch of RDMA tracepoints that are prefixed with "rdma_*", most
of the rest with "qemu_rdma_*". Align them up. The "qemu_" prefix isn't
helping.
Reviewed-by: Jinpu Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
The unregister code was there since the first commit RDMA migration was
merged, but it was never functioning. Remove the dead code.
Since the two control messages are the last ones, we don't even need to
worry about compatibility of legacy RDMA control commands, we can directly
remove the messages too.
As a side effect, this patch closes a report by removing the code
completely.
Reported-by: Tristan (@TristanInSec)
Closes: https://gitlab.com/qemu-project/qemu/-/work_items/4003
Reviewed-by: Jinpu Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Remove the test test_validate_caps_pair, which asserted postcopy-ram
and mapped-ram capabilities cannot be active together. The new fast
snapshot load feature is exactly this pair of capabilities active
together, with the following patches in this series, this combination
will now supported and be functional.
Remove the capability check that rejected mapped-ram and postcopy-ram
being set simultaneously, as this combination now corresponds to fast
snapshot load.
Add a capability check against setting multifd when configured for fast
snapshot load as it is not supported yet. Also add capability check
against setting postcopy-preempt as it is incompatible.
Add infrastructure to check postcopy_notifier_list being empty in
capaility checking to block vhost-user with fast snapshot load as it is
not supported.
Add a check to bail in migrate_prepare to prevent unexpected usage when
fast snapshot load is enabled.
A smoke test exercising this feature has been added further in this
series.
Signed-off-by: Aadeshveer Singh <aadeshveer07@gmail.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Richard Henderson