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: <20220201121325.GB1786498@nvidia.com>
Date:   Tue, 1 Feb 2022 08:13:25 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Cornelia Huck <cohuck@...hat.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 at 12:23:05PM +0100, Cornelia Huck wrote:
> On Sun, Jan 30 2022, Yishai Hadas <yishaih@...dia.com> wrote:
> 
> > From: Jason Gunthorpe <jgg@...dia.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.

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

> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index 9efc35535b29..70c77da5812d 100644
> > +++ b/include/uapi/linux/vfio.h
> > @@ -323,7 +323,6 @@ struct vfio_region_info_cap_type {
> >  #define VFIO_REGION_TYPE_PCI_VENDOR_MASK	(0xffff)
> >  #define VFIO_REGION_TYPE_GFX                    (1)
> >  #define VFIO_REGION_TYPE_CCW			(2)
> > -#define VFIO_REGION_TYPE_MIGRATION              (3)
> 
> Do we want to keep region type 3 reserved? Probably not really needed,
> but would put us on the safe side.

Yes, thanks, this was too zealous to drop it

Jason 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ