From: Juan Quintela <quintela@redhat.com>
To: Avihai Horon <avihaih@nvidia.com>
Cc: qemu-devel@nongnu.org,
"Alex Williamson" <alex.williamson@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Cornelia Huck" <cohuck@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Vladimir Sementsov-Ogievskiy" <vsementsov@yandex-team.ru>,
"Cédric Le Goater" <clg@redhat.com>,
"Yishai Hadas" <yishaih@nvidia.com>,
"Jason Gunthorpe" <jgg@nvidia.com>,
"Maor Gottlieb" <maorg@nvidia.com>,
"Kirti Wankhede" <kwankhede@nvidia.com>,
"Tarun Gupta" <targupta@nvidia.com>,
"Joao Martins" <joao.m.martins@oracle.com>
Subject: Re: [PATCH v10 09/12] vfio/migration: Implement VFIO migration protocol v2
Date: Wed, 15 Feb 2023 14:01:31 +0100 [thread overview]
Message-ID: <87pmab2ic4.fsf@secure.mitica> (raw)
In-Reply-To: <20230209192043.14885-10-avihaih@nvidia.com> (Avihai Horon's message of "Thu, 9 Feb 2023 21:20:40 +0200")
Avihai Horon <avihaih@nvidia.com> wrote:
> Implement the basic mandatory part of VFIO migration protocol v2.
> This includes all functionality that is necessary to support
> VFIO_MIGRATION_STOP_COPY part of the v2 protocol.
>
> The two protocols, v1 and v2, will co-exist and in the following patches
> v1 protocol code will be removed.
>
> There are several main differences between v1 and v2 protocols:
> - VFIO device state is now represented as a finite state machine instead
> of a bitmap.
>
> - Migration interface with kernel is now done using VFIO_DEVICE_FEATURE
> ioctl and normal read() and write() instead of the migration region.
>
> - Pre-copy is made optional in v2 protocol. Support for pre-copy will be
> added later on.
>
> Detailed information about VFIO migration protocol v2 and its difference
> compared to v1 protocol can be found here [1].
>
> [1]
> https://lore.kernel.org/all/20220224142024.147653-10-yishaih@nvidia.com/
>
> Signed-off-by: Avihai Horon <avihaih@nvidia.com>
> +/*
> + * Migration size of VFIO devices can be as little as a few KBs or as big as
> + * many GBs. This value should be big enough to cover the worst case.
> + */
> +#define VFIO_MIG_STOP_COPY_SIZE (100 * GiB)
Wow O:-)
> +
> +/*
> + * Only exact function is implemented and not estimate function. The reason is
> + * that during pre-copy phase of migration the estimate function is called
> + * repeatedly while pending RAM size is over the threshold, thus migration
> + * can't converge and querying the VFIO device pending data size is useless.
> + */
You can do it after this is merge, but I think you can do better than
this. Something in the lines of:
// I put it in a global variable, but it really needs to be in
VFIODevice to be // able to support several devices. You get the idea
O:-)
static uint64_t cached_size = -1;
static void vfio_state_pending_exact(void *opaque, uint64_t *res_precopy_only,
uint64_t *res_compatible,
uint64_t *res_postcopy_only)
{
VFIODevice *vbasedev = opaque;
uint64_t stop_copy_size = VFIO_MIG_STOP_COPY_SIZE;
/*
* If getting pending migration size fails, VFIO_MIG_STOP_COPY_SIZE is
* reported so downtime limit won't be violated.
*/
vfio_query_stop_copy_size(vbasedev, &stop_copy_size);
*res_precopy_only += stop_copy_size;
cached_size = stop_copy_size;
trace_vfio_state_pending_exact(vbasedev->name, *res_precopy_only,
*res_postcopy_only, *res_compatible,
stop_copy_size);
}
static void vfio_state_pending_estimate(void *opaque, uint64_t *res_precopy_only,
uint64_t *res_compatible,
uint64_t *res_postcopy_only)
{
VFIODevice *vbasedev = opaque;
uint64_t stop_copy_size = VFIO_MIG_STOP_COPY_SIZE;
if (cached_size == -1) {
uint64_t res_precopy;
uint64_t res_compatible;
uint64_t res_postcopy;
vfio_state_pending_exact(opaque, &res_precopy, &res_compatible, &res_postcopy);
}
*res_precopy_only += cached_size;
}
next prev parent reply other threads:[~2023-02-15 13:03 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-09 19:20 [PATCH v10 00/12] vfio/migration: Implement VFIO migration protocol v2 Avihai Horon
2023-02-09 19:20 ` [PATCH v10 01/12] linux-headers: Update to v6.2-rc1 Avihai Horon
2023-02-09 19:20 ` [PATCH v10 02/12] vfio/migration: Fix NULL pointer dereference bug Avihai Horon
2023-02-09 19:20 ` [PATCH v10 03/12] vfio/migration: Allow migration without VFIO IOMMU dirty tracking support Avihai Horon
2023-02-15 12:43 ` Juan Quintela
2023-02-15 17:47 ` Avihai Horon
2023-02-15 18:04 ` Juan Quintela
2023-02-15 20:14 ` Alex Williamson
2023-02-15 20:38 ` Jason Gunthorpe
2023-02-15 21:02 ` Alex Williamson
2023-02-09 19:20 ` [PATCH v10 04/12] migration/qemu-file: Add qemu_file_get_to_fd() Avihai Horon
2023-02-09 23:50 ` Alex Williamson
2023-02-15 7:33 ` Juan Quintela
2023-02-09 19:20 ` [PATCH v10 05/12] vfio/common: Change vfio_devices_all_running_and_saving() logic to equivalent one Avihai Horon
2023-02-09 19:20 ` [PATCH v10 06/12] vfio/migration: Block multiple devices migration Avihai Horon
2023-02-10 13:56 ` Cédric Le Goater
2023-02-15 12:46 ` Juan Quintela
2023-02-09 19:20 ` [PATCH v10 07/12] vfio/migration: Move migration v1 logic to vfio_migration_init() Avihai Horon
2023-02-09 19:20 ` [PATCH v10 08/12] vfio/migration: Rename functions/structs related to v1 protocol Avihai Horon
2023-02-09 19:20 ` [PATCH v10 09/12] vfio/migration: Implement VFIO migration protocol v2 Avihai Horon
2023-02-15 13:01 ` Juan Quintela [this message]
2023-02-15 18:23 ` Avihai Horon
2023-02-15 20:53 ` Alex Williamson
2023-02-16 8:15 ` Avihai Horon
2023-02-09 19:20 ` [PATCH v10 10/12] vfio/migration: Remove VFIO migration protocol v1 Avihai Horon
2023-02-15 13:02 ` Juan Quintela
2023-02-09 19:20 ` [PATCH v10 11/12] vfio: Alphabetize migration section of VFIO trace-events file Avihai Horon
2023-02-15 13:03 ` Juan Quintela
2023-02-09 19:20 ` [PATCH v10 12/12] docs/devel: Align VFIO migration docs to v2 protocol Avihai Horon
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=87pmab2ic4.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=avihaih@nvidia.com \
--cc=clg@redhat.com \
--cc=cohuck@redhat.com \
--cc=dgilbert@redhat.com \
--cc=jgg@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=kwankhede@nvidia.com \
--cc=maorg@nvidia.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=targupta@nvidia.com \
--cc=vsementsov@yandex-team.ru \
--cc=yishaih@nvidia.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.