All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>,
	Jason Gunthorpe <jgg@nvidia.com>
Cc: Yishai Hadas <yishaih@nvidia.com>,
	bhelgaas@google.com, saeedm@nvidia.com,
	linux-pci@vger.kernel.org, kvm@vger.kernel.org,
	netdev@vger.kernel.org, kuba@kernel.org, leonro@nvidia.com,
	kwankhede@nvidia.com, mgurtovoy@nvidia.com, maorg@nvidia.com,
	ashok.raj@intel.com, kevin.tian@intel.com,
	shameerali.kolothum.thodi@huawei.com
Subject: Re: [PATCH V9 mlx5-next 10/15] vfio: Extend the device migration protocol with RUNNING_P2P
Date: Thu, 24 Feb 2022 17:53:59 +0100	[thread overview]
Message-ID: <87czjc6w9k.fsf@redhat.com> (raw)
In-Reply-To: <20220224093542.3730bb24.alex.williamson@redhat.com>

On Thu, Feb 24 2022, Alex Williamson <alex.williamson@redhat.com> wrote:

> On Thu, 24 Feb 2022 12:13:30 -0400
> Jason Gunthorpe <jgg@nvidia.com> wrote:
>
>> On Thu, Feb 24, 2022 at 08:30:42AM -0700, Alex Williamson wrote:
>> > On Thu, 24 Feb 2022 16:21:11 +0100
>> > Cornelia Huck <cohuck@redhat.com> wrote:

>> > > conflicts with it. We should not create the impression that STOP_COPY
>> > > will neccessarily be mandatory for all time.  
>> 
>> We really *should* create that impression because a userspace that
>> does not test STOP_COPY in the cases required above is *broken* and
>> must be strongly discouraged from existing.

Well yes, you need STOP_COPY with the current implementation. I'm not
arguing against that.

>> 
>> The purpose of this comment is to inform the userspace implementator,
>> not to muse about possible future expansion options for kernel
>> developers. We all agree this expansion path exists and is valid, we
>> need to keep that option open by helping userspace implement
>> correctly.
>
> Chatting with Connie offline, I think the clarification that might help
> is something alone the lines that the combination of bits must support
> migration, which currently requires the STOP_COPY and RESUMING states.
> The VFIO_MIGRATION_P2P flag alone does not provide these states.  The
> only flag in the current specification to provide these states is
> VFIO_MIGRATION_STOP_COPY.  I don't think we want to preclude that some
> future flag might provide variants of STOP_COPY and RESUMING, so it's
> not so much that VFIO_MIGRATION_STOP_COPY is mandatory, but it is
> currently the only flag which provides the base degree of migration
> support.

Indeed.

>
> How or if that translates to an actual documentation update, I'm not
> sure.  As it stands, we're not speculating about future support, we're
> only stating these two combinations are valid.  Future combinations may
> or may not include VFIO_MIGRATION_STOP_COPY.  As the existing proposed
> comment indicates, other combinations are TBD.  Connie?  Thanks,
>
> Alex

Hm... "a flag indicating support for a migration state machine such as
VFIO_MIGRATION_STOP_COPY is mandatory"?


  reply	other threads:[~2022-02-24 16:54 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-24 14:20 [PATCH V9 mlx5-next 00/15] Add mlx5 live migration driver and v2 migration protocol Yishai Hadas
2022-02-24 14:20 ` [PATCH V9 mlx5-next 01/15] PCI/IOV: Add pci_iov_vf_id() to get VF index Yishai Hadas
2022-02-24 14:20 ` [PATCH V9 mlx5-next 02/15] net/mlx5: Reuse exported virtfn index function call Yishai Hadas
2022-02-24 14:20 ` [PATCH V9 mlx5-next 03/15] net/mlx5: Disable SRIOV before PF removal Yishai Hadas
2022-02-24 14:20 ` [PATCH V9 mlx5-next 04/15] PCI/IOV: Add pci_iov_get_pf_drvdata() to allow VF reaching the drvdata of a PF Yishai Hadas
2022-02-24 14:20 ` [PATCH V9 mlx5-next 05/15] net/mlx5: Expose APIs to get/put the mlx5 core device Yishai Hadas
2022-02-24 14:20 ` [PATCH V9 mlx5-next 06/15] net/mlx5: Introduce migration bits and structures Yishai Hadas
2022-02-24 14:20 ` [PATCH V9 mlx5-next 07/15] net/mlx5: Add migration commands definitions Yishai Hadas
2022-02-24 14:20 ` [PATCH V9 mlx5-next 08/15] vfio: Have the core code decode the VFIO_DEVICE_FEATURE ioctl Yishai Hadas
2022-03-02 10:00   ` Cornelia Huck
2022-03-02 14:23     ` Jason Gunthorpe
2022-02-24 14:20 ` [PATCH V9 mlx5-next 09/15] vfio: Define device migration protocol v2 Yishai Hadas
2022-03-02 11:19   ` Cornelia Huck
2022-03-02 14:27     ` Jason Gunthorpe
2022-03-02 15:34       ` Alex Williamson
2022-03-02 16:07         ` Cornelia Huck
2022-03-02 16:34           ` Alex Williamson
2022-03-02 16:56             ` Cornelia Huck
2022-03-02 16:34           ` Jason Gunthorpe
2022-03-02 16:57   ` Cornelia Huck
2022-02-24 14:20 ` [PATCH V9 mlx5-next 10/15] vfio: Extend the device migration protocol with RUNNING_P2P Yishai Hadas
2022-02-24 15:21   ` Cornelia Huck
2022-02-24 15:30     ` Alex Williamson
2022-02-24 16:13       ` Jason Gunthorpe
2022-02-24 16:35         ` Alex Williamson
2022-02-24 16:53           ` Cornelia Huck [this message]
2022-02-24 20:46             ` Alex Williamson
2022-03-02 11:51   ` Cornelia Huck
2022-02-24 14:20 ` [PATCH V9 mlx5-next 11/15] vfio: Remove migration protocol v1 documentation Yishai Hadas
2022-03-02 10:09   ` Cornelia Huck
2022-03-02 10:09     ` Cornelia Huck
2022-02-24 14:20 ` [PATCH V9 mlx5-next 12/15] vfio/mlx5: Expose migration commands over mlx5 device Yishai Hadas
2022-02-24 14:20 ` [PATCH V9 mlx5-next 13/15] vfio/mlx5: Implement vfio_pci driver for mlx5 devices Yishai Hadas
2022-02-24 14:20 ` [PATCH V9 mlx5-next 14/15] vfio/pci: Expose vfio_pci_core_aer_err_detected() Yishai Hadas
2022-02-24 14:20 ` [PATCH V9 mlx5-next 15/15] vfio/mlx5: Use its own PCI reset_done error handler 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=87czjc6w9k.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=bhelgaas@google.com \
    --cc=jgg@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=leonro@nvidia.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=maorg@nvidia.com \
    --cc=mgurtovoy@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@nvidia.com \
    --cc=shameerali.kolothum.thodi@huawei.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.