public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Yishai Hadas <yishaih@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>,
	Alex Williamson <alex.williamson@redhat.com>
Cc: <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: Thu, 1 Dec 2022 10:01:49 +0200	[thread overview]
Message-ID: <632ec4d4-b661-9de2-ff83-8de7acefd8a2@nvidia.com> (raw)
In-Reply-To: <Y4f6gk2JD3l47p2y@nvidia.com>

On 01/12/2022 2:51, Jason Gunthorpe wrote:
> 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

Right

I''ll rephrase as part of V2 as of below.

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.
It is recommended to leave PRE_COPY for STOP_COPY only after this field
reaches zero. Leaving PRE_COPY earlier might make things slower.

Yishai


  reply	other threads:[~2022-12-01  8:02 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
2022-12-01  8:01       ` Yishai Hadas [this message]
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=632ec4d4-b661-9de2-ff83-8de7acefd8a2@nvidia.com \
    --to=yishaih@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=avihaih@nvidia.com \
    --cc=cohuck@redhat.com \
    --cc=jgg@nvidia.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 \
    /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