From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Yishai Hadas <yishaih@nvidia.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"jgg@nvidia.com" <jgg@nvidia.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"kevin.tian@intel.com" <kevin.tian@intel.com>,
"joao.m.martins@oracle.com" <joao.m.martins@oracle.com>,
"leonro@nvidia.com" <leonro@nvidia.com>,
"shayd@nvidia.com" <shayd@nvidia.com>,
"maorg@nvidia.com" <maorg@nvidia.com>,
"avihaih@nvidia.com" <avihaih@nvidia.com>,
"cohuck@redhat.com" <cohuck@redhat.com>
Subject: RE: [PATCH V2 vfio 02/14] vfio: Extend the device migration protocol with PRE_COPY
Date: Fri, 2 Dec 2022 09:38:55 +0000 [thread overview]
Message-ID: <90968e5f85a64bc68bb3d140fd7a4045@huawei.com> (raw)
In-Reply-To: <20221201152931.47913-3-yishaih@nvidia.com>
> -----Original Message-----
> From: Yishai Hadas [mailto:yishaih@nvidia.com]
> Sent: 01 December 2022 15:29
> To: alex.williamson@redhat.com; jgg@nvidia.com
> Cc: kvm@vger.kernel.org; kevin.tian@intel.com; joao.m.martins@oracle.com;
> leonro@nvidia.com; shayd@nvidia.com; yishaih@nvidia.com;
> maorg@nvidia.com; avihaih@nvidia.com; cohuck@redhat.com
> Subject: [PATCH V2 vfio 02/14] vfio: Extend the device migration protocol
> with PRE_COPY
[...]
> +/**
> + * VFIO_MIG_GET_PRECOPY_INFO - _IO(VFIO_TYPE, VFIO_BASE + 21)
> + *
> + * This ioctl is used on the migration data FD in the precopy phase of the
> + * migration data transfer. It returns an estimate of the current data sizes
> + * remaining to be transferred. It allows the user to judge when it is
> + * appropriate to leave PRE_COPY for STOP_COPY.
> + *
> + * This ioctl is valid only in PRE_COPY states and kernel driver should
> + * return -EINVAL from any other migration state.
> + *
> + * The vfio_precopy_info data structure returned by this ioctl provides
> + * estimates of data available from the device during the PRE_COPY states.
> + * This estimate is split into two categories, initial_bytes and
> + * dirty_bytes.
> + *
> + * The initial_bytes field indicates the amount of initial precopy
> + * data available from the device. This field should have a non-zero initial
> + * value and decrease as migration data is read from the device.
> + * It is recommended to leave PRE_COPY for STOP_COPY only after this field
> + * reaches zero. Leaving PRE_COPY earlier might make things slower.
> + *
> + * The dirty_bytes field tracks device state changes relative to data
> + * previously retrieved. This field starts at zero and may increase as
> + * the internal device state is modified or decrease as that modified
> + * state is read from the device.
> + *
> + * Userspace may use the combination of these fields to estimate the
> + * potential data size available during the PRE_COPY phases, as well as
> + * trends relative to the rate the device is dirtying its internal
> + * state, but these fields are not required to have any bearing relative
> + * to the data size available during the STOP_COPY phase.
> + *
> + * Drivers have a lot of flexibility in when and what they transfer during the
> + * PRE_COPY phase, and how they report this from
> VFIO_MIG_GET_PRECOPY_INFO.
> + *
> + * During pre-copy the migration data FD has a temporary "end of stream"
> that is
> + * reached when both initial_bytes and dirty_byte are zero. For instance,
> this
> + * may indicate that the device is idle and not currently dirtying any internal
> + * state. When read() is done on this temporary end of stream the kernel
> driver
> + * should return ENOMSG from read(). Userspace can wait for more data
> (which may
> + * never come) by using poll.
> + *
> + * Once in STOP_COPY the migration data FD has a permanent end of
> stream
> + * signaled in the usual way by read() always returning 0 and poll always
> + * returning readable. ENOMSG may not be returned in STOP_COPY.
> Support
> + * for this ioctl is optional.
Isn't mandatory if the driver claims support for VFIO_MIGRATION_PRE_COPY?
Other than that looks fine to me.
Reviewed-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
next prev parent reply other threads:[~2022-12-02 9:39 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-01 15:29 [PATCH V2 vfio 00/14] Add migration PRE_COPY support for mlx5 driver Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 01/14] net/mlx5: Introduce ifc bits for pre_copy Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 02/14] vfio: Extend the device migration protocol with PRE_COPY Yishai Hadas
2022-12-01 22:43 ` Alex Williamson
2022-12-04 7:38 ` Leon Romanovsky
2022-12-02 8:48 ` Tian, Kevin
2022-12-04 8:35 ` Yishai Hadas
2022-12-02 9:38 ` Shameerali Kolothum Thodi [this message]
2022-12-05 13:54 ` Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 03/14] vfio/mlx5: Enforce a single SAVE command at a time Yishai Hadas
2022-12-02 0:51 ` Jason Gunthorpe
2022-12-04 12:07 ` Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 04/14] vfio/mlx5: Refactor PD usage Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 05/14] vfio/mlx5: Refactor MKEY usage Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 06/14] vfio/mlx5: Refactor migration file state Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 07/14] vfio/mlx5: Refactor to use queue based data chunks Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 08/14] vfio/mlx5: Introduce device transitions of PRE_COPY Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 09/14] vfio/mlx5: Introduce SW headers for migration states Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 10/14] vfio/mlx5: Introduce vfio precopy ioctl implementation Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 11/14] vfio/mlx5: Consider temporary end of stream as part of PRE_COPY Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 12/14] vfio/mlx5: Introduce multiple loads Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 13/14] vfio/mlx5: Fallback to STOP_COPY upon specific PRE_COPY error Yishai Hadas
2022-12-01 15:29 ` [PATCH V2 vfio 14/14] vfio/mlx5: Enable MIGRATION_PRE_COPY flag Yishai Hadas
2022-12-02 1:06 ` [PATCH V2 vfio 00/14] Add migration PRE_COPY support for mlx5 driver Jason Gunthorpe
2022-12-02 8:57 ` Tian, Kevin
2022-12-04 11:54 ` Yishai Hadas
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=90968e5f85a64bc68bb3d140fd7a4045@huawei.com \
--to=shameerali.kolothum.thodi@huawei.com \
--cc=alex.williamson@redhat.com \
--cc=avihaih@nvidia.com \
--cc=cohuck@redhat.com \
--cc=jgg@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=leonro@nvidia.com \
--cc=maorg@nvidia.com \
--cc=shayd@nvidia.com \
--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.