| Age | Commit message (Collapse) | Author |
|---|
|
Move HMP-specific declarations to its own CONFIG_HMP guarded header.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.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-48-9227de146347@redhat.com>
|
|
Exclude all *-hmp-cmds.c files and HMP-only source files from the
build when HMP is disabled.
Also conditionalise the hmp-commands.hx header generation and the
test-hmp qtest.
Acked-by: Dr. David Alan Gilbert <dave@treblig.org>
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-45-9227de146347@redhat.com>
|
|
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>
|
|
Mostly mechanical, with a few adjustments around it.
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.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-32-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>
|
|
Add more checks for vmstate flags constraints.
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 offset/length ranges are not sanity checked in RDMA requests, add the
checks.
Reported-by: Tristan (@TristanInSec)
Closes: https://gitlab.com/qemu-project/qemu/-/work_items/4005
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>
|
|
Before registration of RDMA ranges, QEMU destination checks for validity of
current_addr no less than the target ramblock's start address. But it
didn't check for the upper bound to make sure the address is within the
size of the ramblock. Add it.
Reported-by: Tristan (@TristanInSec)
Closes: https://gitlab.com/qemu-project/qemu/-/work_items/4007
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>
|
|
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>
|
|
Not used anymore.
Reviewed-by: Jinpu Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
|
|
Not used anymore.
Reviewed-by: Jinpu Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
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>
|
|
Introduce this to say how many control messages we have. We did it because
we're going to remove the last one (RDMA_CONTROL_UNREGISTER_FINISHED) soon.
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>
|
|
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>
|
|
In fast snapshot load a thread is needed for actively loading in pages
along with the fault path so that the guest is not dependent on fault
thread indefinitely. Considering the difference from usual network
postcopy where major chunk of RAM is already loaded here entire RAM
needs to be loaded later. Existance of background pages which are not
really accessed by the guest might never be loaded and system will be
locked in migration for indefinite time. As there should be no
assumption about how guest accesses memory, the load times can be
indefinite.
Add postcopy_ram_eager_load_thread(), for the eager thread which
iterates over all non ignored blocks calling ram_block_load_eager()
on each. ram_block_load_eager then iterates to load in all pages using
postcopy_mapped_ram_load_page(), with a different channel, which takes
care of not loading in pages already loaded by fault thread. On
completion the thread schedules postcopy_incoming_complete_bh() to
destroy the incoming migration state.
Add postcopy_ram_eager_load_setup() to create the thread. Added joining
logic in postcopy_incoming_cleanup().
Add tracepoints for entry and exit to eager load thread.
When both mapped-ram and postcopy-ram are set, divert from
qemu_loadvm_state to run fast snapshot load
Initialize postcopy RAM state and register RAM Blocks with userfaultfd
via ram_postcopy_incoming_init() and postcopy_ram_incoming_setup() in
process_incoming_migration_co(). Fault thread needs to be launched
before VM to serve faults for some hardwares emulation that need to read
RAM (like vapic devices). Populate bitmaps and offset tables while
reading file in qemu_loadvm_state_main.
Add function qemu_loadvm_run_fast_snapshot_load() which starts the VM
using loadvm_postcopy_handle_run_bh() and launches eager load thread.
Skip scheduling process_incoming_migration_bh() in
process_incoming_migration_co(), for fast snapshot load as the state
cleanup is managed by eager load thread on completion.
Signed-off-by: Aadeshveer Singh <aadeshveer07@gmail.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juraj Marcin <jmarcin@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
|
|
In fast snapshot load, we would like to serve faults as soon as possible
hence loading pages directly instead of requesting a source
Add postcopy_mapped_ram_load_page() function which serves single page
fault. It uses bitmap_test_and_clear_atomic() on pending_bmap to prevent
multiple threads from loading same page. It loads a page or pages
depending on size of guest pages and host pages, loading exactly the
larger of two. If the entire page is zero postcopy_place_page_zero() is
used for efficiency and in case some part is non zero it is part by part
loaded on loop using new function postcopy_mapped_ram_load_guest_page()
which loads a single guest page in a buffer which is then placed using
postcopy_place_page(). This covers all possible cases for various page
sizes of host and guest. Because postcopy_place_page and in general
postcopy does not support larger guest pages this will not work in case
of guest pages sizes larger than host.
Update postcopy_ram_fault_thread to call postcopy_mapped_ram_load_page
instead of requesting source in case of fast snapshot load. to_src_file
check is bypassed in fast snapshot load case as there is no source.
Call try_mark_postcopy_blocktime_begin on every page fault to support
postcopy-blocktime.
Allocate another channel in postcopy_temp_pages_setup(like the preempt
case), for both the fault thread and eager thread to load pages
independently.
Signed-off-by: Aadeshveer Singh <aadeshveer07@gmail.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
|
|
Add pending_bmap field per RAMBlock which is a Bitmap to store
internal state of which pages have been read by some thread to ensure
coordination between fault thread and eager load thread.
Modify parse_ramblock_mapped_ram(), to not load the actual RAMBlocks
data in postcopy case as that will be loaded by fault thread and eager
thread after the VM starts running.
Change ram_load() to use new function ram_should_load_postcopy_pages()
to decide how to load/read RAM.
Signed-off-by: Aadeshveer Singh <aadeshveer07@gmail.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
|
|
Remove the internal QEMUFile error state modification from
qemu_get_buffer_at(). This function is called by two functions, both of
which already check for unexpected return values and handle their own
error reporting.
Removing this shared state modification makes qemu_get_buffer_at()
strictly thread-safe for concurrent disk reads, serving as a
preparatory change for the upcoming fast snapshot load feature.
Removed local error by passing errp to improve on error handling,
consequently also change caller to use error_prevent and not error_setg.
Set errp in case of f->last_error as function should set errp in case it
fails, and caller can simply use error_prepend without checking errp in
case of error.
Signed-off-by: Aadeshveer Singh <aadeshveer07@gmail.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juraj Marcin <jmarcin@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
|
|
Replace the temporary bitmap with the existing file_bmap attribute of
the RAMBlock. This acts as a preparatory change for the upcoming fast
snapshot load feature.
Reusing this bitmap allows the destination to track page types during
a postcopy load, enabling faster, direct placement of zero pages.
Since file_bmap is currently only utilized during the migration save
phase, it can be safely repurposed during the load phase without
introducing conflicts.
Signed-off-by: Aadeshveer Singh <aadeshveer07@gmail.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juraj Marcin <jmarcin@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
|
|
Rename postcopy_listen_thread_bh to postcopy_incoming_complete_bh for a
more robust naming scheme. This will allow fast snapshot load to use
this bh funciton directly to cleanup the incoming state.
Signed-off-by: Aadeshveer Singh <aadeshveer07@gmail.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juraj Marcin <jmarcin@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
|
|
Use new function try_mark_postcopy_blocktim_begin() to call
mark_postcopy_blocktime_begin if page was not received and return if it
actually marked it.
This will help in having a cleaner API to call
mark_postcopy_blocktime_begin as it requires the page to not be received
by asserting on it's existance in RAMBlock->receivedmap.
Signed-off-by: Aadeshveer Singh <aadeshveer07@gmail.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juraj Marcin <jmarcin@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
|
|
Modernize error handling in postcopy_ram_incoming_setup() and
postcopy_temp_pages_setup() by replacing error_reports and local error
handling with standard Error propagation.
Replace use of strerror() on errno with error_setg_errno() for modular
handling of errors and change return values to -1 on failure as no
caller checks the actual return value.
Signed-off-by: Aadeshveer Singh <aadeshveer07@gmail.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juraj Marcin <jmarcin@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
|
|
If err != NULL, free it.
Fixes: 11dd7be57524 ("migration/multifd: Remove p->quit from recv side")
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260727-fix2-v2-11-d0c4831ed7ea@redhat.com>
|
|
dirty_bitmap_load_start() creates an incoming migrated bitmap with
bdrv_create_dirty_bitmap() and, if the source marked it persistent,
calls bdrv_dirty_bitmap_set_persistence() without checking whether
the destination node can be written to. Same gap as
qmp_block_dirty_bitmap_add(), reached via incoming migration: a
persistent bitmap for a read-only destination (e.g. a migrated
CD-ROM-class attachment with dirty-bitmaps migration enabled) ends
up writable in memory on a node that can never store it.
Reject it the same way, with one difference from the QMP path:
every destination node is BDRV_O_INACTIVE until migration completes,
so bdrv_is_writable() would reject every incoming persistent
bitmap, not just read-only ones. Check bdrv_is_read_only() alone.
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Eric Blake <eblake@redhat.com>
CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
CC: John Snow <jsnow@redhat.com>
CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-ID: <20260716112242.3000035-3-den@openvz.org>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
|
|
migration-hmp-cmds.c uses types / methods declared in
"block/block-global-state.h". Include the latter otherwise
we get when refactoring unrelated headers:
../migration/migration-hmp-cmds.c:911:5: error: use of undeclared identifier 'BdrvNextIterator'
911 | BdrvNextIterator it;
| ^
../migration/migration-hmp-cmds.c:918:15: error: call to undeclared function 'bdrv_first'
918 | for (bs = bdrv_first(&it); bs; bs = bdrv_next(&it)) {
| ^
Signed-off-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
Message-Id: <20260812211708.92824-7-philmd@oss.qualcomm.com>
|
|
In an unlikely case, when a migration stream is attached to the destination
QEMU and only send <4 bytes to the channel as magic, it's possible that
migration_channel_read_peek() may spin forever.
Fix it by adding a manual sleep for partial read.
Since the path isn't attached to a coroutine, it means when partial read
happens, there's yet not much we can do but hang the main thread, it will
happen even for len==0 case. It means monitors can hang due to this,
either partial read or no data arrived (but connection established).
Leave this for later, the hope is this is extremely rare in production.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3889
Reported-by: Feifan Qian <bea1e@proton.me>
Cc: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Link: https://lore.kernel.org/r/20260812124327.2572363-1-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
|
|
Add an underflow check for the subtract of total RAMBlock size to make sure
it won't underflow. It should not happen in production systems but only if
the migration stream was hijacked, which is not a real concern since
migration channel is trusted. Still protect against it.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4013
Reported-by: Tristan Madani <tristan@talencesecurity.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20260728210417.1925078-6-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
|
|
QPL and UADK multifd backends use assert() to validate wire-controlled
fields like per-page compressed lengths and packet size consistency. These
asserts will stop working with -DNDEBUG builds, so may stop working.
Replace all assert() calls in the receive path with proper error_setg() so
validation failures are reported gracefully rather than crashing or
silently ignored.
While at it, touch up an assert() in qatzip recv path too.
Cc: qemu-stable <qemu-stable@nongnu.org>
Cc: Yuan Liu <yuan1.liu@intel.com>
Cc: Yichen Wang <yichen.wang@bytedance.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20260728210417.1925078-4-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
|
|
The zlib and zstd multifd compression backends read next_packet_size from
the incoming migration stream and use it directly as the read length into a
fixed-size buffer (MULTIFD_PACKET_SIZE * 2 = 1MB). A malicious migration
source can set next_packet_size bigger than allocated, causing a heap
buffer overflow write on the destination.
Add a check against zbuff_len before reading, matching what the qatzip
backend already does. Also replace the assert(in_size == 0) for empty
packets with proper error reporting, since the value is wire-controlled,
meanwhile assert() stops working with -DNDEBUG builds.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3737
Reported-by: xlabai <xlabai@tencent.com>
Reported-by: Jules Denardou <jules.denardou@datadoghq.com>
Reported-by: Tristan Madani <tristan@talencesecurity.com>
Reported-by: david korczynski (@david1766)
Reported-by: huntr bubble (@bubblehuntr)
Cc: qemu-stable <qemu-stable@nongnu.org>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20260728210417.1925078-3-peterx@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
|
|
Currently the cpr-transfer source QEMU instance cannot be driven entirely
via HMP. The source must use QMP in order to specify both the
main migration channel and the CPR channel.
Extend the HMP migrate command with an optional CPR channel URI. When the
migration mode is cpr-transfer, HMP uses this URI to build a
CPR MigrationChannel in addition to the main migration channel. The new
option is rejected unless the migration mode is cpr-transfer, so existing
HMP migrate usage is unchanged.
For example, source QEMU HMP commands can be something like below. The
"-c unix:/tmp/cpr.sock" is for CPR URI.
(qemu) migrate_set_parameter mode cpr-transfer
(qemu) migrate -c unix:/tmp/cpr.sock tcp:0:50002
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
Acked-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
Link: https://lore.kernel.org/r/20260728085903.173265-1-dongli.zhang@oracle.com
Signed-off-by: Peter Xu <peterx@redhat.com>
|
|
The function calls yield_until_fd_readable() (coroutine_fn) when in
coroutine context, and polls with qemu_poll_ns() otherwise.
Replace the migration-state proxy check with qemu_in_coroutine(),
which directly tests what matters.
Fixes: 2da776db4846 ("rdma: core logic")
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
|
|
Fixes: 394b9407e4c ("migration: mark mixed functions that can suspend")
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
|
|
Fixes: 44adb5fcc20d "target/riscv: Remove spike as default machine"
Fixes: 48814111366b "migration: Always set DEVICE state"
Fixes: 3345fb3b6d7f "migration/postcopy: Add latency distribution report for blocktime"
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
|
|
Migration pull for rc1
- Bin's cleanup on migration blocktime (partly)
- Yujun's fix on print format
# -----BEGIN PGP SIGNATURE-----
#
# iIgEABYKADAWIQS5GE3CDMRX2s990ak7X8zN86vXBgUCal43iBIccGV0ZXJ4QHJl
# ZGhhdC5jb20ACgkQO1/MzfOr1wYzkwD9H0wbDbw9KNk4Wz5bwqa3SblpniWRByEg
# OeCWcZ68th8BAOS+jwufS002GImaUCYZLlsg0oRAYnTOp45vU65z5y0B
# =VOpz
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 20 Jul 2026 10:58:16 EDT
# gpg: using EDDSA key B9184DC20CC457DACF7DD1A93B5FCCCDF3ABD706
# gpg: issuer "peterx@redhat.com"
# gpg: Good signature from "Peter Xu <xzpeter@gmail.com>" [full]
# gpg: aka "Peter Xu <peterx@redhat.com>" [full]
# Primary key fingerprint: B918 4DC2 0CC4 57DA CF7D D1A9 3B5F CCCD F3AB D706
* tag 'next-pull-request' of https://gitlab.com/peterx/qemu:
migration: clean up postcopy blocktime presentation
migration: fix ineffective overflow assert in postcopy blocktime
migration: Fix invalid %ud format and trace arg typo
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
|
|
Small cleanups for the postcopy blocktime fine-grained tracking
feature:
* Remove a redundant memset() on latency_buckets after g_new0().
* Use singular "Latency" in the HMP label for postcopy non-vCPU
latency, consistent with other single-value labels.
Signed-off-by: Bin Guo <guobin@linux.alibaba.com>
Link: https://lore.kernel.org/r/20260716101952.65329-4-guobin@linux.alibaba.com
Signed-off-by: Peter Xu <peterx@redhat.com>
|
|
vcpu_faults_current[] is uint8_t. The overflow assert was checked
after the post-increment, so 255 would wrap to 0 and the assert
would pass silently. Move the check before the increment and use
< 255.
Signed-off-by: Bin Guo <guobin@linux.alibaba.com>
Link: https://lore.kernel.org/r/20260716101952.65329-2-guobin@linux.alibaba.com
Signed-off-by: Peter Xu <peterx@redhat.com>
|
|
staging
Monitor patches for 2026-07-07
# -----BEGIN PGP SIGNATURE-----
#
# iQJGBAABCgAwFiEENUvIs9frKmtoZ05fOHC0AOuRhlMFAmpMylQSHGFybWJydUBy
# ZWRoYXQuY29tAAoJEDhwtADrkYZTZR0QALmaLG//ZC/AihLLdHHYgQFWQD+2MQiP
# l91oqTb+p40q0WhQYzCVYUc+8SMBY6pG6uuzn/qgpsP335uaFEk8c++znyXmbofy
# eABrnVETv/SokrvCxwEIZaW49B2gfER2dZ59sLKbvDQN30Dg36dbppHgchWeLO4b
# P2kP0veYHSnPx60JE4a0bcvLUO8aaEpb2dkvLOjJdaavJaF1iJURU5CP4hA979PM
# xt74cxqhEB6bASLcCJNuGumjmuUHCJGvt0bIGU7L/7a18RAXCw6kJlqfniZWjapC
# FMwN5OU8KSq2dy3SjbT6NotUQ8/fLgDqiCsd5gCRPROeAPQ8ZHHqBjyWsdPbHXOo
# A5m/XGAqDmWtqBPQkM158RpK20IeGAvTs3LrNQHoFB5f+iLm6dJf0CqbFCj6a4tc
# 0w9J7nMUPscEZrJRryjpuYKe82wLrsWTaT3/je/dj2MMDy/Rd6HvjXKhY5P9upHH
# SOa8c4L0bG7PpT0paL2cUf03NmyOhWZFx583VID+R/TOQKjyOtdc//eMpuoqpfGU
# ggiMDG6VY1+YUZ4/gZ84v/gZDeMJ/9R6rpKGiMJKCOJJUS9znPOPiKKBMI+5Vz0w
# 5IrugNKhnfMwCbYS2xFjtop9OFSOQBgLz4/7epKBYltWd4Y3h2Y61WsxxFRg85TL
# 4MnzmcrMvoK7
# =Lxcx
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 07 Jul 2026 11:43:48 CEST
# gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653
# gpg: issuer "armbru@redhat.com"
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full]
# gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full]
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653
* tag 'pull-monitor-2026-07-07' of https://repo.or.cz/qemu/armbru: (35 commits)
docs: mark '-mon' as deprecated in favour of -object
qemu-options: document new monitor-hmp and monitor-qmp objects
tests: switch from -mon to -object monitor-qmp
monitor: add support for auto-deleting monitors upon close
qom: add trace events for user creatable create/delete APIs
tests/functional: add a stress test for monitor hot unplug
tests/functional: add e2e test for dynamic QMP monitor hotplug
tests/qtest: add tests for dynamic monitor add/remove
monitor: implement support for deleting QMP objects
monitor: protect qemu_chr_fe_accept_input with monitor lock
monitor: reject attempts to delete the current monitor
monitor: convert from oneshot BH to persistent BH
monitor: implement "user creatable" interface for adding monitors
monitor: eliminate monitor_is_hmp_non_interactive method
monitor: drop unused monitor_is_qmp method
monitor: use dynamic cast in monitor_is_hmp_non_interactive
monitor: use dynamic cast in QMP commands
monitor: drop unused monitor_cur_is_qmp
util: use dynamic cast in error vreport
monitor: use dynamic cast in monitor_qmp_requests_pop_any_with_lock
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
|
|
The monitor_is_hmp_non_interactive method is used by
monitor_suspend and monitor_resume, to make them a no-op
if the HMP does not use readline.
There are only a handful of callers of suspend/resume and
they can be made to skip the call when readline is not
present.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Tested-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260706135824.2623960-23-berrange@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
|
|
"Switchover" is a noun; the verb form is "switch over". Replace all
instances where "switchover" was incorrectly used as a verb in comments
and documentation.
Signed-off-by: Avihai Horon <avihaih@nvidia.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260706085211.13905-17-avihaih@nvidia.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
|
|
migration_completion_precopy() reports its error through the Error
**errp argument, so its int return value carries no information beyond
success/failure. Convert it to return a bool, matching the common
convention.
Convert its underlying helper qemu_savevm_state_complete_precopy()
likewise, and in turn qemu_savevm_state_non_iterable(), which it calls.
Adjust all callers accordingly.
Refactor and clean migration_completion() code too, which no longer
needs to track int return values.
Signed-off-by: Avihai Horon <avihaih@nvidia.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20260706085211.13905-16-avihaih@nvidia.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
|
