From: Cornelia Huck <cohuck@redhat•com>
To: Alex Williamson <alex.williamson@redhat•com>
Cc: Jason Gunthorpe <jgg@nvidia•com>,
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
Subject: Re: [PATCH V6 mlx5-next 10/15] vfio: Remove migration protocol v1
Date: Wed, 02 Feb 2022 12:38:07 +0100 [thread overview]
Message-ID: <875ypxxzvk.fsf@redhat.com> (raw)
In-Reply-To: <20220201160106.0760bfea.alex.williamson@redhat.com>
On Tue, Feb 01 2022, Alex Williamson <alex.williamson@redhat•com> wrote:
> On Tue, 01 Feb 2022 13:39:23 +0100
> Cornelia Huck <cohuck@redhat•com> wrote:
>
>> 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.
>
>
> Agreed that v1 migration TYPE/SUBTYPE should live in infamy as
> reserved, but I'm not sure why we need to make the rest of it a big
> complicated problem. On one hand, leaving stubs for the necessary
> structure and macros until QEMU gets updated doesn't seem so terrible.
> Nor actually does letting the next QEMU header update cause build
> breakages, which would probably frustrate the person submitting that
> update, but it's not like QEMU hasn't done selective header updates in
> the past. The former is probably the more friendly approach if we
> don't outrage someone in the kernel community in the meantime.
Leaving stubs in (while making it clear that v1 is not something you
should use) seems like a good compromise. While we have done selective
headers updates in QEMU in the past, I always found them painful, so I'd
like to avoid that.
next prev parent reply other threads:[~2022-02-02 11:38 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
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 [this message]
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=875ypxxzvk.fsf@redhat.com \
--to=cohuck@redhat$(echo .)com \
--cc=alex.williamson@redhat$(echo .)com \
--cc=bhelgaas@google$(echo .)com \
--cc=jgg@nvidia$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=kvm@vger$(echo .)kernel.org \
--cc=kwankhede@nvidia$(echo .)com \
--cc=leonro@nvidia$(echo .)com \
--cc=linux-pci@vger$(echo .)kernel.org \
--cc=maorg@nvidia$(echo .)com \
--cc=mgurtovoy@nvidia$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=saeedm@nvidia$(echo .)com \
--cc=yishaih@nvidia$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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