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 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.