From: Alex Williamson <alex@shazbot.org>
To: Yishai Hadas <yishaih@nvidia.com>
Cc: <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>, <clg@redhat.com>,
<peterx@redhat.com>, <liulongfang@huawei.com>,
<giovanni.cabiddu@intel.com>, <kwankhede@nvidia.com>,
alex@shazbot.org
Subject: Re: [PATCH V2 vfio 0/6] Add support for PRE_COPY initial bytes re-initialization
Date: Fri, 20 Mar 2026 15:17:14 -0600 [thread overview]
Message-ID: <20260320151714.7642ed1e@shazbot.org> (raw)
In-Reply-To: <20260317161753.18964-1-yishaih@nvidia.com>
On Tue, 17 Mar 2026 18:17:47 +0200
Yishai Hadas <yishaih@nvidia.com> wrote:
> This series introduces support for re-initializing the initial_bytes
> value during the VFIO PRE_COPY migration phase.
>
> Background
> ==========
> 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 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.
>
> Problem Statement
> =================
> In some cases, a new chunk of critical data may appear during the
> PRE_COPY phase. The current API does not provide a mechanism for the
> driver to report an updated initial_bytes value when this occurs.
>
> Solution
> ========
> 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.
>
> However, 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. For that we introduce a new feature named
> VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2.
>
> User should opt-in to the above feature with a SET operation, no data is
> required and any supplied data is ignored.
>
> When the caller opts in:
> - We set info.flags to zero, otherwise we keep v1 behaviour as is for
> compatibility reasons.
> - The new output flag VFIO_PRECOPY_INFO_REINIT can be used reliably.
> - The VFIO_PRECOPY_INFO_REINIT output flag indicates that new initial
> data is present on the stream. The initial_bytes value should be
> re-evaluated relative to the readiness state for transition to
> STOP_COPY.
>
> The mlx5 VFIO driver is extended to support this case when the
> underlying firmware also supports the REINIT migration state.
>
> As part of this series, a core helper function is introduced to provide
> shared functionality for implementing the VFIO_MIG_GET_PRECOPY_INFO
> ioctl, and all drivers have been updated to use it.
>
> Changes from V1:
> https://patchwork.kernel.org/project/kvm/cover/20260310164006.4020-1-yishaih@nvidia.com/
>
> Patch #1:
> - Extend the uAPI documentation to refer to the source of new
> initial_bytes data.
Applied with the fix discussed in 2/ to vfio next branch for v7.1.
Thanks,
Alex
prev parent reply other threads:[~2026-03-20 21:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 16:17 [PATCH V2 vfio 0/6] Add support for PRE_COPY initial bytes re-initialization Yishai Hadas
2026-03-17 16:17 ` [PATCH V2 vfio 1/6] vfio: Define uAPI for re-init initial bytes during the PRE_COPY phase Yishai Hadas
2026-03-17 16:17 ` [PATCH V2 vfio 2/6] vfio: Add support for VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 Yishai Hadas
2026-03-18 22:03 ` Alex Williamson
2026-03-19 15:26 ` Yishai Hadas
2026-03-19 18:28 ` Alex Williamson
2026-03-17 16:17 ` [PATCH V2 vfio 3/6] vfio: Adapt drivers to use the core helper vfio_check_precopy_ioctl Yishai Hadas
2026-03-17 16:17 ` [PATCH V2 vfio 4/6] net/mlx5: Add IFC bits for migration state Yishai Hadas
2026-03-17 16:17 ` [PATCH V2 vfio 5/6] vfio/mlx5: consider inflight SAVE during PRE_COPY Yishai Hadas
2026-03-17 16:17 ` [PATCH V2 vfio 6/6] vfio/mlx5: Add REINIT support to VFIO_MIG_GET_PRECOPY_INFO Yishai Hadas
2026-03-20 21:17 ` Alex Williamson [this message]
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=20260320151714.7642ed1e@shazbot.org \
--to=alex@shazbot.org \
--cc=avihaih@nvidia.com \
--cc=clg@redhat.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=peterx@redhat.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.