public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
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 -------- */
>  
>  /**


  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