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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox