netdev - Re: [PATCH V6 mlx5-next 10/15] vfio: Remove migration protocol v1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87k0eey8ih.fsf@redhat.com>
Date:   Tue, 01 Feb 2022 15:19:18 +0100
From:   Cornelia Huck <cohuck@...hat.com>
To:     Jason Gunthorpe <jgg@...dia.com>
Cc:     Yishai Hadas <yishaih@...dia.com>, alex.williamson@...hat.com,
        bhelgaas@...gle.com, saeedm@...dia.com, linux-pci@...r.kernel.org,
        kvm@...r.kernel.org, netdev@...r.kernel.org, kuba@...nel.org,
        leonro@...dia.com, kwankhede@...dia.com, mgurtovoy@...dia.com,
        maorg@...dia.com
Subject: Re: [PATCH V6 mlx5-next 10/15] vfio: Remove migration protocol v1

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

> On Tue, Feb 01, 2022 at 02:26:29PM +0100, Cornelia Huck wrote:
>
>> > We can certainly defer the kernels removal patch for a release if it
>> > makes qemu's life easier?
>> 
>> No, I'm only talking about the QEMU implementation (i.e. the code that
>> uses the v1 definitions and exposes x-enable-migration). Any change in
>> the headers needs to be done via a sync with upstream Linux.
>
> If we leave the v1 and v2 defs in the kernel header then qemu can sync
> and do the trivial rename and keep going as-is.
>
> Then we can come with the patches to qemu update to v2, however that
> looks.
>
> We'll clean the kernel header in the next cylce.

I'm not sure we're talking about the same things here...

My proposal is:

- remove the current QEMU implementation of vfio migration for 7.0 (it's
  experimental, and if there's anybody experimenting with that, they can
  stay on 6.2)
- continue with getting this proposal for the kernel into good shape, so
  that it can hopefully make the next merge window
(- also continue to get the documentation into good shape)
- have an RFC for QEMU that contains a provisional update of the
  relevant vfio headers so that we can discuss the QEMU side (and maybe
  shoot down any potential problems in the uapi before they are merged
  in the kernel)

I don't think a "dual version header" would really help here. If we
don't want to rip out the old QEMU implementation yet, I can certainly
also live with that. We just need to be mindful once the changes hit
Linus' tree, but it is quite likely that QEMU would be in freeze by
then. As long as updating the headers leads to an obvious failure, it's
managable (although the removal would still be my preferred approach.)

Alex, what do you think?