From: Avihai Horon <avihaih@nvidia.com>
To: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>,
Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>
Cc: "Alex Williamson" <alex.williamson@redhat.com>,
"Cédric Le Goater" <clg@redhat.com>,
"Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Joao Martins" <joao.m.martins@oracle.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH v5 27/36] vfio/migration: Multifd device state transfer support - load thread
Date: Sun, 2 Mar 2025 16:15:44 +0200 [thread overview]
Message-ID: <2fe12099-be41-4ca3-8ede-add04cc76b19@nvidia.com> (raw)
In-Reply-To: <9be8882ea2189c1a827bdf09835d6c65488d2ca6.1739994627.git.maciej.szmigiero@oracle.com>
On 19/02/2025 22:34, Maciej S. Szmigiero wrote:
> External email: Use caution opening links or attachments
>
>
> From: "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>
Maybe add a sentence talking about the load thread itself first? E.g.:
Add a thread which loads the VFIO device state buffers that were
received and via multifd.
Each VFIO device that has multifd device state transfer enabled has one
such thread, which is created using migration core API
qemu_loadvm_start_load_thread().
Since it's important to finish...
> Since it's important to finish loading device state transferred via the
> main migration channel (via save_live_iterate SaveVMHandler) before
> starting loading the data asynchronously transferred via multifd the thread
> doing the actual loading of the multifd transferred data is only started
> from switchover_start SaveVMHandler.
>
> switchover_start handler is called when MIG_CMD_SWITCHOVER_START
> sub-command of QEMU_VM_COMMAND is received via the main migration channel.
>
> This sub-command is only sent after all save_live_iterate data have already
> been posted so it is safe to commence loading of the multifd-transferred
> device state upon receiving it - loading of save_live_iterate data happens
> synchronously in the main migration thread (much like the processing of
> MIG_CMD_SWITCHOVER_START) so by the time MIG_CMD_SWITCHOVER_START is
> processed all the proceeding data must have already been loaded.
>
> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
> ---
> hw/vfio/migration-multifd.c | 225 ++++++++++++++++++++++++++++++++++++
> hw/vfio/migration-multifd.h | 2 +
> hw/vfio/migration.c | 12 ++
> hw/vfio/trace-events | 5 +
> 4 files changed, 244 insertions(+)
>
> diff --git a/hw/vfio/migration-multifd.c b/hw/vfio/migration-multifd.c
> index 5d5ee1393674..b3a88c062769 100644
> --- a/hw/vfio/migration-multifd.c
> +++ b/hw/vfio/migration-multifd.c
> @@ -42,8 +42,13 @@ typedef struct VFIOStateBuffer {
> } VFIOStateBuffer;
>
> typedef struct VFIOMultifd {
> + QemuThread load_bufs_thread;
This can be dropped.
> + bool load_bufs_thread_running;
> + bool load_bufs_thread_want_exit;
> +
> VFIOStateBuffers load_bufs;
> QemuCond load_bufs_buffer_ready_cond;
> + QemuCond load_bufs_thread_finished_cond;
> QemuMutex load_bufs_mutex; /* Lock order: this lock -> BQL */
> uint32_t load_buf_idx;
> uint32_t load_buf_idx_last;
> @@ -179,6 +184,175 @@ bool vfio_load_state_buffer(void *opaque, char *data, size_t data_size,
> return true;
> }
>
> +static int vfio_load_bufs_thread_load_config(VFIODevice *vbasedev)
> +{
> + return -EINVAL;
> +}
> +
> +static VFIOStateBuffer *vfio_load_state_buffer_get(VFIOMultifd *multifd)
> +{
> + VFIOStateBuffer *lb;
> + guint bufs_len;
> +
> + bufs_len = vfio_state_buffers_size_get(&multifd->load_bufs);
> + if (multifd->load_buf_idx >= bufs_len) {
> + assert(multifd->load_buf_idx == bufs_len);
> + return NULL;
> + }
> +
> + lb = vfio_state_buffers_at(&multifd->load_bufs,
> + multifd->load_buf_idx);
> + if (!lb->is_present) {
> + return NULL;
> + }
> +
> + return lb;
> +}
> +
> +static bool vfio_load_state_buffer_write(VFIODevice *vbasedev,
> + VFIOStateBuffer *lb,
> + Error **errp)
> +{
> + VFIOMigration *migration = vbasedev->migration;
> + VFIOMultifd *multifd = migration->multifd;
> + g_autofree char *buf = NULL;
> + char *buf_cur;
> + size_t buf_len;
> +
> + if (!lb->len) {
> + return true;
> + }
> +
> + trace_vfio_load_state_device_buffer_load_start(vbasedev->name,
> + multifd->load_buf_idx);
> +
> + /* lb might become re-allocated when we drop the lock */
> + buf = g_steal_pointer(&lb->data);
> + buf_cur = buf;
> + buf_len = lb->len;
> + while (buf_len > 0) {
> + ssize_t wr_ret;
> + int errno_save;
> +
> + /*
> + * Loading data to the device takes a while,
> + * drop the lock during this process.
> + */
> + qemu_mutex_unlock(&multifd->load_bufs_mutex);
> + wr_ret = write(migration->data_fd, buf_cur, buf_len);
> + errno_save = errno;
> + qemu_mutex_lock(&multifd->load_bufs_mutex);
> +
> + if (wr_ret < 0) {
> + error_setg(errp,
> + "writing state buffer %" PRIu32 " failed: %d",
> + multifd->load_buf_idx, errno_save);
Let's add vbasedev->name to the error message so we know which device
caused the error.
> + return false;
> + }
> +
> + assert(wr_ret <= buf_len);
I think this assert is redundant: we write buf_len bytes and by
definition of write() wr_ret will be <= buf_len.
> + buf_len -= wr_ret;
> + buf_cur += wr_ret;
> + }
> +
> + trace_vfio_load_state_device_buffer_load_end(vbasedev->name,
> + multifd->load_buf_idx);
> +
> + return true;
> +}
> +
> +static bool vfio_load_bufs_thread_want_exit(VFIOMultifd *multifd,
> + bool *should_quit)
> +{
> + return multifd->load_bufs_thread_want_exit || qatomic_read(should_quit);
> +}
> +
> +/*
> + * This thread is spawned by vfio_multifd_switchover_start() which gets
> + * called upon encountering the switchover point marker in main migration
> + * stream.
> + *
> + * It exits after either:
> + * * completing loading the remaining device state and device config, OR:
> + * * encountering some error while doing the above, OR:
> + * * being forcefully aborted by the migration core by it setting should_quit
> + * or by vfio_load_cleanup_load_bufs_thread() setting
> + * multifd->load_bufs_thread_want_exit.
> + */
> +static bool vfio_load_bufs_thread(void *opaque, bool *should_quit, Error **errp)
> +{
> + VFIODevice *vbasedev = opaque;
> + VFIOMigration *migration = vbasedev->migration;
> + VFIOMultifd *multifd = migration->multifd;
> + bool ret = true;
> + int config_ret;
> +
> + assert(multifd);
> + QEMU_LOCK_GUARD(&multifd->load_bufs_mutex);
> +
> + assert(multifd->load_bufs_thread_running);
> +
> + while (true) {
> + VFIOStateBuffer *lb;
> +
> + /*
> + * Always check cancellation first after the buffer_ready wait below in
> + * case that cond was signalled by vfio_load_cleanup_load_bufs_thread().
> + */
> + if (vfio_load_bufs_thread_want_exit(multifd, should_quit)) {
> + error_setg(errp, "operation cancelled");
> + ret = false;
> + goto ret_signal;
IIUC, if vfio_load_bufs_thread_want_exit() returns true, it means that
some other code part already failed and set migration error, no?
If so, shouldn't we return true here? After all, vfio_load_bufs_thread
didn't really fail, it just got signal to terminate itself.
> + }
> +
> + assert(multifd->load_buf_idx <= multifd->load_buf_idx_last);
> +
> + lb = vfio_load_state_buffer_get(multifd);
> + if (!lb) {
> + trace_vfio_load_state_device_buffer_starved(vbasedev->name,
> + multifd->load_buf_idx);
> + qemu_cond_wait(&multifd->load_bufs_buffer_ready_cond,
> + &multifd->load_bufs_mutex);
> + continue;
> + }
> +
> + if (multifd->load_buf_idx == multifd->load_buf_idx_last) {
> + break;
> + }
> +
> + if (multifd->load_buf_idx == 0) {
> + trace_vfio_load_state_device_buffer_start(vbasedev->name);
> + }
> +
> + if (!vfio_load_state_buffer_write(vbasedev, lb, errp)) {
> + ret = false;
> + goto ret_signal;
> + }
> +
> + if (multifd->load_buf_idx == multifd->load_buf_idx_last - 1) {
> + trace_vfio_load_state_device_buffer_end(vbasedev->name);
> + }
> +
> + multifd->load_buf_idx++;
> + }
> +
> + config_ret = vfio_load_bufs_thread_load_config(vbasedev);
> + if (config_ret) {
> + error_setg(errp, "load config state failed: %d", config_ret);
Let's add vbasedev->name to the error message so we know which device
caused the error.
> + ret = false;
> + }
> +
> +ret_signal:
> + /*
> + * Notify possibly waiting vfio_load_cleanup_load_bufs_thread() that
> + * this thread is exiting.
> + */
> + multifd->load_bufs_thread_running = false;
> + qemu_cond_signal(&multifd->load_bufs_thread_finished_cond);
> +
> + return ret;
> +}
> +
> VFIOMultifd *vfio_multifd_new(void)
> {
> VFIOMultifd *multifd = g_new(VFIOMultifd, 1);
> @@ -191,11 +365,42 @@ VFIOMultifd *vfio_multifd_new(void)
> multifd->load_buf_idx_last = UINT32_MAX;
> qemu_cond_init(&multifd->load_bufs_buffer_ready_cond);
>
> + multifd->load_bufs_thread_running = false;
> + multifd->load_bufs_thread_want_exit = false;
> + qemu_cond_init(&multifd->load_bufs_thread_finished_cond);
> +
> return multifd;
> }
>
> +/*
> + * Terminates vfio_load_bufs_thread by setting
> + * multifd->load_bufs_thread_want_exit and signalling all the conditions
> + * the thread could be blocked on.
> + *
> + * Waits for the thread to signal that it had finished.
> + */
> +static void vfio_load_cleanup_load_bufs_thread(VFIOMultifd *multifd)
> +{
> + /* The lock order is load_bufs_mutex -> BQL so unlock BQL here first */
> + bql_unlock();
> + WITH_QEMU_LOCK_GUARD(&multifd->load_bufs_mutex) {
> + while (multifd->load_bufs_thread_running) {
> + multifd->load_bufs_thread_want_exit = true;
> +
> + qemu_cond_signal(&multifd->load_bufs_buffer_ready_cond);
> + qemu_cond_wait(&multifd->load_bufs_thread_finished_cond,
> + &multifd->load_bufs_mutex);
> + }
> + }
> + bql_lock();
> +}
> +
> void vfio_multifd_free(VFIOMultifd *multifd)
> {
> + vfio_load_cleanup_load_bufs_thread(multifd);
> +
> + qemu_cond_destroy(&multifd->load_bufs_thread_finished_cond);
> + vfio_state_buffers_destroy(&multifd->load_bufs);
vfio_state_buffers_destroy(&multifd->load_bufs); belongs to patch #26, no?
Thanks.
> qemu_cond_destroy(&multifd->load_bufs_buffer_ready_cond);
> qemu_mutex_destroy(&multifd->load_bufs_mutex);
>
> @@ -225,3 +430,23 @@ bool vfio_multifd_transfer_setup(VFIODevice *vbasedev, Error **errp)
>
> return true;
> }
> +
> +int vfio_multifd_switchover_start(VFIODevice *vbasedev)
> +{
> + VFIOMigration *migration = vbasedev->migration;
> + VFIOMultifd *multifd = migration->multifd;
> +
> + assert(multifd);
> +
> + /* The lock order is load_bufs_mutex -> BQL so unlock BQL here first */
> + bql_unlock();
> + WITH_QEMU_LOCK_GUARD(&multifd->load_bufs_mutex) {
> + assert(!multifd->load_bufs_thread_running);
> + multifd->load_bufs_thread_running = true;
> + }
> + bql_lock();
> +
> + qemu_loadvm_start_load_thread(vfio_load_bufs_thread, vbasedev);
> +
> + return 0;
> +}
> diff --git a/hw/vfio/migration-multifd.h b/hw/vfio/migration-multifd.h
> index d5ab7d6f85f5..09cbb437d9d1 100644
> --- a/hw/vfio/migration-multifd.h
> +++ b/hw/vfio/migration-multifd.h
> @@ -25,4 +25,6 @@ bool vfio_multifd_transfer_setup(VFIODevice *vbasedev, Error **errp);
> bool vfio_load_state_buffer(void *opaque, char *data, size_t data_size,
> Error **errp);
>
> +int vfio_multifd_switchover_start(VFIODevice *vbasedev);
> +
> #endif
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index abaf4d08d4a9..85f54cb22df2 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -793,6 +793,17 @@ static bool vfio_switchover_ack_needed(void *opaque)
> return vfio_precopy_supported(vbasedev);
> }
>
> +static int vfio_switchover_start(void *opaque)
> +{
> + VFIODevice *vbasedev = opaque;
> +
> + if (vfio_multifd_transfer_enabled(vbasedev)) {
> + return vfio_multifd_switchover_start(vbasedev);
> + }
> +
> + return 0;
> +}
> +
> static const SaveVMHandlers savevm_vfio_handlers = {
> .save_prepare = vfio_save_prepare,
> .save_setup = vfio_save_setup,
> @@ -808,6 +819,7 @@ static const SaveVMHandlers savevm_vfio_handlers = {
> .load_state = vfio_load_state,
> .load_state_buffer = vfio_load_state_buffer,
> .switchover_ack_needed = vfio_switchover_ack_needed,
> + .switchover_start = vfio_switchover_start,
> };
>
> /* ---------------------------------------------------------------------- */
> diff --git a/hw/vfio/trace-events b/hw/vfio/trace-events
> index 042a3dc54a33..418b378ebd29 100644
> --- a/hw/vfio/trace-events
> +++ b/hw/vfio/trace-events
> @@ -154,6 +154,11 @@ vfio_load_device_config_state_end(const char *name) " (%s)"
> vfio_load_state(const char *name, uint64_t data) " (%s) data 0x%"PRIx64
> vfio_load_state_device_data(const char *name, uint64_t data_size, int ret) " (%s) size %"PRIu64" ret %d"
> vfio_load_state_device_buffer_incoming(const char *name, uint32_t idx) " (%s) idx %"PRIu32
> +vfio_load_state_device_buffer_start(const char *name) " (%s)"
> +vfio_load_state_device_buffer_starved(const char *name, uint32_t idx) " (%s) idx %"PRIu32
> +vfio_load_state_device_buffer_load_start(const char *name, uint32_t idx) " (%s) idx %"PRIu32
> +vfio_load_state_device_buffer_load_end(const char *name, uint32_t idx) " (%s) idx %"PRIu32
> +vfio_load_state_device_buffer_end(const char *name) " (%s)"
> vfio_migration_realize(const char *name) " (%s)"
> vfio_migration_set_device_state(const char *name, const char *state) " (%s) state %s"
> vfio_migration_set_state(const char *name, const char *new_state, const char *recover_state) " (%s) new state %s, recover state %s"
next prev parent reply other threads:[~2025-03-02 14:17 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-19 20:33 [PATCH v5 00/36] Multifd 🔀 device state transfer support with VFIO consumer Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 01/36] migration: Clarify that {load, save}_cleanup handlers can run without setup Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 02/36] thread-pool: Remove thread_pool_submit() function Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 03/36] thread-pool: Rename AIO pool functions to *_aio() and data types to *Aio Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 04/36] thread-pool: Implement generic (non-AIO) pool support Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 05/36] migration: Add MIG_CMD_SWITCHOVER_START and its load handler Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 06/36] migration: Add qemu_loadvm_load_state_buffer() and its handler Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 07/36] migration: postcopy_ram_listen_thread() should take BQL for some calls Maciej S. Szmigiero
2025-02-25 17:16 ` Peter Xu
2025-02-25 21:08 ` Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 08/36] error: define g_autoptr() cleanup function for the Error type Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 09/36] migration: Add thread pool of optional load threads Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 10/36] migration/multifd: Split packet into header and RAM data Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 11/36] migration/multifd: Device state transfer support - receive side Maciej S. Szmigiero
2025-03-02 12:42 ` Avihai Horon
2025-03-03 22:14 ` Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 12/36] migration/multifd: Make multifd_send() thread safe Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 13/36] migration/multifd: Add an explicit MultiFDSendData destructor Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 14/36] migration/multifd: Device state transfer support - send side Maciej S. Szmigiero
2025-03-02 12:46 ` Avihai Horon
2025-03-03 22:15 ` Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 15/36] migration/multifd: Make MultiFDSendData a struct Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 16/36] migration/multifd: Add multifd_device_state_supported() Maciej S. Szmigiero
2025-02-19 20:33 ` [PATCH v5 17/36] migration: Add save_live_complete_precopy_thread handler Maciej S. Szmigiero
2025-02-26 16:43 ` Peter Xu
2025-03-04 21:50 ` Maciej S. Szmigiero
2025-03-04 22:03 ` Peter Xu
2025-02-19 20:34 ` [PATCH v5 18/36] vfio/migration: Add load_device_config_state_start trace event Maciej S. Szmigiero
2025-02-19 20:34 ` [PATCH v5 19/36] vfio/migration: Convert bytes_transferred counter to atomic Maciej S. Szmigiero
2025-02-26 7:52 ` Cédric Le Goater
2025-02-26 13:55 ` Maciej S. Szmigiero
2025-02-26 15:56 ` Cédric Le Goater
2025-02-26 16:20 ` Cédric Le Goater
2025-02-19 20:34 ` [PATCH v5 20/36] vfio/migration: Add vfio_add_bytes_transferred() Maciej S. Szmigiero
2025-02-26 8:06 ` Cédric Le Goater
2025-02-26 15:45 ` Maciej S. Szmigiero
2025-02-19 20:34 ` [PATCH v5 21/36] vfio/migration: Move migration channel flags to vfio-common.h header file Maciej S. Szmigiero
2025-02-26 8:19 ` Cédric Le Goater
2025-02-19 20:34 ` [PATCH v5 22/36] vfio/migration: Multifd device state transfer support - basic types Maciej S. Szmigiero
2025-02-26 8:52 ` Cédric Le Goater
2025-02-26 16:06 ` Maciej S. Szmigiero
2025-02-19 20:34 ` [PATCH v5 23/36] vfio/migration: Multifd device state transfer support - VFIOStateBuffer(s) Maciej S. Szmigiero
2025-02-26 8:54 ` Cédric Le Goater
2025-03-02 13:00 ` Avihai Horon
2025-03-02 15:14 ` Maciej S. Szmigiero
2025-03-03 6:42 ` Cédric Le Goater
2025-03-03 22:14 ` Maciej S. Szmigiero
2025-02-19 20:34 ` [PATCH v5 24/36] vfio/migration: Multifd device state transfer - add support checking function Maciej S. Szmigiero
2025-02-26 8:54 ` Cédric Le Goater
2025-02-19 20:34 ` [PATCH v5 25/36] vfio/migration: Multifd device state transfer support - receive init/cleanup Maciej S. Szmigiero
2025-02-26 10:14 ` Cédric Le Goater
2025-02-26 17:22 ` Cédric Le Goater
2025-02-26 17:28 ` Maciej S. Szmigiero
2025-02-26 17:28 ` Cédric Le Goater
2025-02-27 22:00 ` Maciej S. Szmigiero
2025-02-26 17:46 ` Cédric Le Goater
2025-02-27 22:00 ` Maciej S. Szmigiero
2025-02-19 20:34 ` [PATCH v5 26/36] vfio/migration: Multifd device state transfer support - received buffers queuing Maciej S. Szmigiero
2025-02-26 10:43 ` Cédric Le Goater
2025-02-26 21:04 ` Maciej S. Szmigiero
2025-02-28 8:09 ` Cédric Le Goater
2025-02-28 20:47 ` Maciej S. Szmigiero
2025-03-02 13:12 ` Avihai Horon
2025-03-03 22:15 ` Maciej S. Szmigiero
2025-02-19 20:34 ` [PATCH v5 27/36] vfio/migration: Multifd device state transfer support - load thread Maciej S. Szmigiero
2025-02-26 13:49 ` Cédric Le Goater
2025-02-26 21:05 ` Maciej S. Szmigiero
2025-02-28 9:11 ` Cédric Le Goater
2025-02-28 20:48 ` Maciej S. Szmigiero
2025-03-02 14:19 ` Avihai Horon
2025-03-03 22:16 ` Maciej S. Szmigiero
2025-03-02 14:15 ` Avihai Horon [this message]
2025-03-03 22:16 ` Maciej S. Szmigiero
2025-03-04 11:21 ` Avihai Horon
2025-02-19 20:34 ` [PATCH v5 28/36] vfio/migration: Multifd device state transfer support - config loading support Maciej S. Szmigiero
2025-02-26 13:52 ` Cédric Le Goater
2025-02-26 21:05 ` Maciej S. Szmigiero
2025-03-02 14:25 ` Avihai Horon
2025-03-03 22:17 ` Maciej S. Szmigiero
2025-03-04 7:41 ` Cédric Le Goater
2025-03-04 21:50 ` Maciej S. Szmigiero
2025-02-19 20:34 ` [PATCH v5 29/36] migration/qemu-file: Define g_autoptr() cleanup function for QEMUFile Maciej S. Szmigiero
2025-02-19 20:34 ` [PATCH v5 30/36] vfio/migration: Multifd device state transfer support - send side Maciej S. Szmigiero
2025-02-26 16:43 ` Cédric Le Goater
2025-02-26 21:05 ` Maciej S. Szmigiero
2025-02-28 9:13 ` Cédric Le Goater
2025-02-28 20:49 ` Maciej S. Szmigiero
2025-03-02 14:41 ` Avihai Horon
2025-03-03 22:17 ` Maciej S. Szmigiero
2025-02-19 20:34 ` [PATCH v5 31/36] vfio/migration: Add x-migration-multifd-transfer VFIO property Maciej S. Szmigiero
2025-02-27 6:45 ` Cédric Le Goater
2025-03-02 14:48 ` Avihai Horon
2025-03-03 22:17 ` Maciej S. Szmigiero
2025-03-04 11:29 ` Avihai Horon
2025-03-04 21:50 ` Maciej S. Szmigiero
2025-02-19 20:34 ` [PATCH v5 32/36] vfio/migration: Make x-migration-multifd-transfer VFIO property mutable Maciej S. Szmigiero
2025-02-26 17:59 ` Cédric Le Goater
2025-02-26 21:05 ` Maciej S. Szmigiero
2025-02-28 8:44 ` Cédric Le Goater
2025-02-28 20:47 ` Maciej S. Szmigiero
2025-02-19 20:34 ` [PATCH v5 33/36] hw/core/machine: Add compat for x-migration-multifd-transfer VFIO property Maciej S. Szmigiero
2025-02-26 17:59 ` Cédric Le Goater
2025-02-19 20:34 ` [PATCH v5 34/36] vfio/migration: Max in-flight VFIO device state buffer count limit Maciej S. Szmigiero
2025-02-27 6:48 ` Cédric Le Goater
2025-02-27 22:01 ` Maciej S. Szmigiero
2025-02-28 8:53 ` Cédric Le Goater
2025-02-28 20:48 ` Maciej S. Szmigiero
2025-03-02 14:53 ` Avihai Horon
2025-03-02 14:54 ` Maciej S. Szmigiero
2025-03-02 14:59 ` Maciej S. Szmigiero
2025-03-02 16:28 ` Avihai Horon
2025-02-19 20:34 ` [PATCH v5 35/36] vfio/migration: Add x-migration-load-config-after-iter VFIO property Maciej S. Szmigiero
2025-02-19 20:34 ` [PATCH v5 36/36] vfio/migration: Update VFIO migration documentation Maciej S. Szmigiero
2025-02-27 6:59 ` Cédric Le Goater
2025-02-27 22:01 ` Maciej S. Szmigiero
2025-02-28 10:05 ` Cédric Le Goater
2025-02-28 20:49 ` Maciej S. Szmigiero
2025-02-28 23:38 ` Fabiano Rosas
2025-03-03 9:34 ` Cédric Le Goater
2025-03-03 22:14 ` Maciej S. Szmigiero
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2fe12099-be41-4ca3-8ede-add04cc76b19@nvidia.com \
--to=avihaih@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=clg@redhat.com \
--cc=eblake@redhat.com \
--cc=farosas@suse.de \
--cc=joao.m.martins@oracle.com \
--cc=mail@maciej.szmigiero.name \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).