All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Yishai Hadas <yishaih@nvidia.com>,
	alex.williamson@redhat.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
Subject: Re: [PATCH V6 mlx5-next 10/15] vfio: Remove migration protocol v1
Date: Tue, 01 Feb 2022 13:39:23 +0100	[thread overview]
Message-ID: <87sft2yd50.fsf@redhat.com> (raw)
In-Reply-To: <20220201121325.GB1786498@nvidia.com>

On Tue, Feb 01 2022, Jason Gunthorpe <jgg@nvidia.com> wrote:

> On Tue, Feb 01, 2022 at 12:23:05PM +0100, Cornelia Huck wrote:
>> On Sun, Jan 30 2022, Yishai Hadas <yishaih@nvidia.com> wrote:
>> 
>> > From: Jason Gunthorpe <jgg@nvidia.com>
>> >
>> > v1 was never implemented and is replaced by v2.
>> >
>> > The old uAPI definitions are removed from the header file. As per Linus's
>> > past remarks we do not have a hard requirement to retain compilation
>> > compatibility in uapi headers and qemu is already following Linus's
>> > preferred model of copying the kernel headers.
>> 
>> If we are all in agreement that we will replace v1 with v2 (and I think
>> we are), we probably should remove the x-enable-migration stuff in QEMU
>> sooner rather than later, to avoid leaving a trap for the next
>> unsuspecting person trying to update the headers.
>
> Once we have agreement on the kernel patch we plan to send a QEMU
> patch making it support the v2 interface and the migration
> non-experimental. We are also working to fixing the error paths, at
> least least within the limitations of the current qemu design.

I'd argue that just ripping out the old interface first would be easier,
as it does not require us to synchronize with a headers sync (and does
not require to synchronize a headers sync with ripping it out...)

> The v1 support should remain in old releases as it is being used in
> the field "experimentally".

Of course; it would be hard to rip it out retroactively :)

But it should really be gone in QEMU 7.0.

Considering adding the v2 uapi, we might get unlucky: The Linux 5.18
merge window will likely be in mid-late March (and we cannot run a
headers sync before the patches hit Linus' tree), while QEMU 7.0 will
likely enter freeze in mid-late March as well. So there's a non-zero
chance that the new uapi will need to be deferred to 7.1.


  reply	other threads:[~2022-02-01 12:39 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-30 16:08 [PATCH V6 mlx5-next 00/15] Add mlx5 live migration driver and v2 migration protocol Yishai Hadas
2022-01-30 16:08 ` [PATCH V6 mlx5-next 01/15] PCI/IOV: Add pci_iov_vf_id() to get VF index Yishai Hadas
2022-01-30 16:08 ` [PATCH V6 mlx5-next 02/15] net/mlx5: Reuse exported virtfn index function call Yishai Hadas
2022-01-30 16:08 ` [PATCH V6 mlx5-next 03/15] net/mlx5: Disable SRIOV before PF removal Yishai Hadas
2022-01-30 16:08 ` [PATCH V6 mlx5-next 04/15] PCI/IOV: Add pci_iov_get_pf_drvdata() to allow VF reaching the drvdata of a PF Yishai Hadas
2022-01-30 16:08 ` [PATCH V6 mlx5-next 05/15] net/mlx5: Expose APIs to get/put the mlx5 core device Yishai Hadas
2022-01-30 16:08 ` [PATCH V6 mlx5-next 06/15] net/mlx5: Introduce migration bits and structures Yishai Hadas
2022-01-30 16:08 ` [PATCH V6 mlx5-next 07/15] vfio: Have the core code decode the VFIO_DEVICE_FEATURE ioctl Yishai Hadas
2022-01-31 23:41   ` Alex Williamson
2022-02-01  0:11     ` Jason Gunthorpe
2022-02-01 15:47       ` Alex Williamson
2022-02-01 15:49         ` Jason Gunthorpe
2022-01-30 16:08 ` [PATCH V6 mlx5-next 08/15] vfio: Define device migration protocol v2 Yishai Hadas
2022-01-31 23:43   ` Alex Williamson
2022-02-01  0:31     ` Jason Gunthorpe
2022-02-01 17:04       ` Alex Williamson
2022-02-01 18:36         ` Jason Gunthorpe
2022-02-01 21:49           ` Alex Williamson
2022-02-02  0:24             ` Jason Gunthorpe
2022-02-02 23:36               ` Alex Williamson
2022-02-03 14:17                 ` Jason Gunthorpe
2022-02-04 12:12                 ` Cornelia Huck
2022-02-03 15:51               ` Tarun Gupta (SW-GPU)
2022-02-01 12:06   ` Cornelia Huck
2022-02-01 12:10     ` Jason Gunthorpe
2022-02-01 12:18       ` Cornelia Huck
2022-02-01 12:27         ` Jason Gunthorpe
2022-01-30 16:08 ` [PATCH V6 mlx5-next 09/15] vfio: Extend the device migration protocol with RUNNING_P2P Yishai Hadas
2022-02-01 11:54   ` Cornelia Huck
2022-02-01 12:13     ` Jason Gunthorpe
2022-02-01 18:31   ` Alex Williamson
2022-02-01 18:53     ` Jason Gunthorpe
2022-02-01 19:13       ` Alex Williamson
2022-02-01 19:50         ` Jason Gunthorpe
2022-02-02 23:54           ` Alex Williamson
2022-02-03 14:22             ` Jason Gunthorpe
2022-01-30 16:08 ` [PATCH V6 mlx5-next 10/15] vfio: Remove migration protocol v1 Yishai Hadas
2022-02-01 11:23   ` Cornelia Huck
2022-02-01 12:13     ` Jason Gunthorpe
2022-02-01 12:39       ` Cornelia Huck [this message]
2022-02-01 12:54         ` Jason Gunthorpe
2022-02-01 13:26           ` Cornelia Huck
2022-02-01 13:52             ` Jason Gunthorpe
2022-02-01 14:19               ` Cornelia Huck
2022-02-01 14:29                 ` Jason Gunthorpe
2022-02-02 11:34                   ` Cornelia Huck
2022-02-02 12:22                     ` Jason Gunthorpe
2022-02-01 23:01         ` Alex Williamson
2022-02-02  0:28           ` Jason Gunthorpe
2022-02-02 11:38           ` Cornelia Huck
2022-01-30 16:08 ` [PATCH V6 mlx5-next 11/15] vfio/mlx5: Expose migration commands over mlx5 device Yishai Hadas
2022-01-30 16:08 ` [PATCH V6 mlx5-next 12/15] vfio/mlx5: Implement vfio_pci driver for mlx5 devices Yishai Hadas
2022-01-30 16:08 ` [PATCH V6 mlx5-next 13/15] vfio/pci: Expose vfio_pci_core_aer_err_detected() Yishai Hadas
2022-01-30 16:08 ` [PATCH V6 mlx5-next 14/15] vfio/mlx5: Use its own PCI reset_done error handler Yishai Hadas
2022-01-30 16:08 ` [PATCH V6 mlx5-next 15/15] vfio: Extend the device migration protocol with PRE_COPY 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=87sft2yd50.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=jgg@nvidia.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=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.