From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Yishai Hadas <yishaih@nvidia.com>,
kvm@vger.kernel.org, kevin.tian@intel.com,
joao.m.martins@oracle.com, leonro@nvidia.com, shayd@nvidia.com,
maorg@nvidia.com, avihaih@nvidia.com, cohuck@redhat.com,
Juan Quintela <quintela@redhat.com>
Subject: Re: [PATCH V1 vfio 02/14] vfio: Extend the device migration protocol with PRE_COPY
Date: Wed, 30 Nov 2022 20:51:14 -0400 [thread overview]
Message-ID: <Y4f6gk2JD3l47p2y@nvidia.com> (raw)
In-Reply-To: <20221130152240.11a24c4d.alex.williamson@redhat.com>
On Wed, Nov 30, 2022 at 03:22:40PM -0700, Alex Williamson wrote:
> On Thu, 24 Nov 2022 19:39:20 +0200
> Yishai Hadas <yishaih@nvidia.com> wrote:
> > +/**
> > + * 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 mandatory 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 a must to leave PRE_COPY for STOP_COPY only after this field reach
> > + * zero.
>
>
> Is this actually a requirement that's compatible with current QEMU
> behavior? It's my impression that a user can force the migration to
> move to STOP_COPY at any point in time. Thanks,
I think it is a typo
It should be explaining that leaving PRE_COPY early will make things
slower, but is not a functional problem.
Jason
next prev parent reply other threads:[~2022-12-01 0:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-24 17:39 [PATCH V1 vfio 00/14] Add migration PRE_COPY support for mlx5 driver Yishai Hadas
2022-11-24 17:39 ` [PATCH V1 vfio 01/14] net/mlx5: Introduce ifc bits for pre_copy Yishai Hadas
2022-11-24 17:39 ` [PATCH V1 vfio 02/14] vfio: Extend the device migration protocol with PRE_COPY Yishai Hadas
2022-11-30 22:22 ` Alex Williamson
2022-12-01 0:51 ` Jason Gunthorpe [this message]
2022-12-01 8:01 ` Yishai Hadas
2022-11-24 17:39 ` [PATCH V1 vfio 03/14] vfio/mlx5: Enforce a single SAVE command at a time Yishai Hadas
2022-11-24 17:39 ` [PATCH V1 vfio 04/14] vfio/mlx5: Refactor PD usage Yishai Hadas
2022-11-24 17:39 ` [PATCH V1 vfio 05/14] vfio/mlx5: Refactor MKEY usage Yishai Hadas
2022-11-24 17:39 ` [PATCH V1 vfio 06/14] vfio/mlx5: Refactor migration file state Yishai Hadas
2022-11-24 17:39 ` [PATCH V1 vfio 07/14] vfio/mlx5: Refactor to use queue based data chunks Yishai Hadas
2022-11-24 17:39 ` [PATCH V1 vfio 08/14] vfio/mlx5: Introduce device transitions of PRE_COPY Yishai Hadas
2022-11-24 17:39 ` [PATCH V1 vfio 09/14] vfio/mlx5: Introduce SW headers for migration states Yishai Hadas
2022-11-30 10:10 ` Yishai Hadas
2022-11-24 17:39 ` [PATCH V1 vfio 10/14] vfio/mlx5: Introduce vfio precopy ioctl implementation Yishai Hadas
2022-11-24 17:39 ` [PATCH V1 vfio 11/14] vfio/mlx5: Consider temporary end of stream as part of PRE_COPY Yishai Hadas
2022-11-24 17:39 ` [PATCH V1 vfio 12/14] vfio/mlx5: Introduce multiple loads Yishai Hadas
2022-11-24 17:39 ` [PATCH V1 vfio 13/14] vfio/mlx5: Fallback to STOP_COPY upon specific PRE_COPY error Yishai Hadas
2022-11-24 17:39 ` [PATCH V1 vfio 14/14] vfio/mlx5: Enable MIGRATION_PRE_COPY flag Yishai Hadas
2022-11-30 10:33 ` [PATCH V1 vfio 00/14] Add migration PRE_COPY support for mlx5 driver 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=Y4f6gk2JD3l47p2y@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=avihaih@nvidia.com \
--cc=cohuck@redhat.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=quintela@redhat.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 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.