From: Alex Williamson <alex@shazbot.org>
To: Yishai Hadas <yishaih@nvidia.com>
Cc: <alex.williamson@redhat.com>, <jgg@nvidia.com>,
<kvm@vger.kernel.org>, <kevin.tian@intel.com>,
<joao.m.martins@oracle.com>, <leonro@nvidia.com>,
<maorg@nvidia.com>, <avihaih@nvidia.com>,
<liulongfang@huawei.com>, <giovanni.cabiddu@intel.com>,
<kwankhede@nvidia.com>,
alex@shazbot.org
Subject: Re: [PATCH vfio 1/6] vfio: Define uAPI for re-init initial bytes during the PRE_COPY phase
Date: Fri, 27 Feb 2026 13:42:46 -0700 [thread overview]
Message-ID: <20260227134246.27ca482a@shazbot.org> (raw)
In-Reply-To: <20260224082019.25772-2-yishaih@nvidia.com>
On Tue, 24 Feb 2026 10:20:14 +0200
Yishai Hadas <yishaih@nvidia.com> wrote:
> As currently defined, initial_bytes is monotonically decreasing and
> precedes dirty_bytes when reading from the saving file descriptor.
> The transition from initial_bytes to dirty_bytes is unidirectional and
> irreversible.
>
> The initial_bytes are considered as critical data that is highly
> recommended to be transferred to the target as part of PRE_COPY, without
> this data, the PRE_COPY phase would be ineffective.
>
> We come to solve the case when a new chunk of critical data is
> introduced during the PRE_COPY phase and the driver would like to report
> an entirely new value for the initial_bytes.
>
> For that, we extend the VFIO_MIG_GET_PRECOPY_INFO ioctl with an output
> flag named VFIO_PRECOPY_INFO_REINIT to allow drivers reporting a new
> initial_bytes value during the PRE_COPY phase.
>
> Currently, existing VFIO_MIG_GET_PRECOPY_INFO implementations don't
> assign info.flags before copy_to_user(), this effectively echoes
> userspace-provided flags back as output, preventing the field from being
> used to report new reliable data from the drivers.
>
> Reliable use of the new VFIO_PRECOPY_INFO_REINIT flag requires userspace
> to explicitly opt in by enabling the
> VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 device feature.
>
> When the caller opts in, the driver may report an entirely new
> value for initial_bytes. It may be larger, it may be smaller, it may
> include the previous unread initial_bytes, it may discard the previous
> unread initial_bytes, up to the driver logic and state.
> The presence of the VFIO_PRECOPY_INFO_REINIT output flag set by the
> driver indicates that new initial data is present on the stream.
>
> Once the caller sees this flag, the initial_bytes value should be
> re-evaluated relative to the readiness state for transition to
> STOP_COPY.
>
> Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
> ---
> include/uapi/linux/vfio.h | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index bb7b89330d35..b6efda07000f 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -1266,6 +1266,17 @@ enum vfio_device_mig_state {
> * 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.
> + * The presence of the VFIO_PRECOPY_INFO_REINIT output flag indicates
> + * that new initial data is present on the stream.
> + * In that case initial_bytes may report a non-zero value irrespective of
> + * any previously reported values, which progresses towards zero as precopy
> + * data is read from the data stream. dirty_bytes is also reset
> + * to zero and represents the state change of the device relative to the new
> + * initial_bytes.
> + * VFIO_PRECOPY_INFO_REINIT can be reported only after userspace opts in to
> + * VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2. Without this opt-in, the flags field
> + * of struct vfio_precopy_info is reserved for bug-compatibility reasons.
> + *
> * It is recommended to leave PRE_COPY for STOP_COPY only after this field
> * reaches zero. Leaving PRE_COPY earlier might make things slower.
> *
> @@ -1301,6 +1312,7 @@ enum vfio_device_mig_state {
> struct vfio_precopy_info {
> __u32 argsz;
> __u32 flags;
> +#define VFIO_PRECOPY_INFO_REINIT (1 << 0) /* output - new initial data is present */
> __aligned_u64 initial_bytes;
> __aligned_u64 dirty_bytes;
> };
> @@ -1510,6 +1522,16 @@ struct vfio_device_feature_dma_buf {
> struct vfio_region_dma_range dma_ranges[] __counted_by(nr_ranges);
> };
>
> +/*
> + * Enables the migration prepcopy_info_v2 behaviour.
s/prepcopy/precopy/
Thanks,
Alex
> + *
> + * VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2.
> + *
> + * On SET, enables the v2 pre_copy_info behaviour, where the
> + * vfio_precopy_info.flags is a valid output field.
> + */
> +#define VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 12
> +
> /* -------- API for Type1 VFIO IOMMU -------- */
>
> /**
next prev parent reply other threads:[~2026-02-27 20:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-24 8:20 [PATCH vfio 0/6] Add support for PRE_COPY initial bytes re-initialization Yishai Hadas
2026-02-24 8:20 ` [PATCH vfio 1/6] vfio: Define uAPI for re-init initial bytes during the PRE_COPY phase Yishai Hadas
2026-02-27 20:42 ` Alex Williamson [this message]
2026-02-24 8:20 ` [PATCH vfio 2/6] vfio: Add support for VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 Yishai Hadas
2026-02-27 20:42 ` Alex Williamson
2026-02-28 19:51 ` Alex Williamson
2026-02-24 8:20 ` [PATCH vfio 3/6] vfio: Adapt drivers to use the core helper vfio_check_precopy_ioctl Yishai Hadas
2026-02-24 8:20 ` [PATCH vfio 4/6] net/mlx5: Add IFC bits for migration state Yishai Hadas
2026-02-24 8:20 ` [PATCH vfio 5/6] vfio/mlx5: consider inflight SAVE during PRE_COPY Yishai Hadas
2026-02-24 8:20 ` [PATCH vfio 6/6] vfio/mlx5: Add REINIT support to VFIO_MIG_GET_PRECOPY_INFO Yishai Hadas
2026-02-27 20:23 ` [PATCH vfio 0/6] Add support for PRE_COPY initial bytes re-initialization Alex Williamson
2026-02-28 6:27 ` Cédric Le Goater
2026-03-01 12:43 ` Yishai Hadas
2026-03-10 9:46 ` Yishai Hadas
2026-03-10 10:09 ` Cédric Le Goater
2026-03-10 12:44 ` Yishai Hadas
2026-03-10 16:00 ` Alex Williamson
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=20260227134246.27ca482a@shazbot.org \
--to=alex@shazbot.org \
--cc=alex.williamson@redhat.com \
--cc=avihaih@nvidia.com \
--cc=giovanni.cabiddu@intel.com \
--cc=jgg@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=leonro@nvidia.com \
--cc=liulongfang@huawei.com \
--cc=maorg@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