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] [day] [month] [year] [list]
Message-ID: <20220224123929.GA6413@nvidia.com>
Date:   Thu, 24 Feb 2022 08:39:29 -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, ashok.raj@...el.com, kevin.tian@...el.com,
        shameerali.kolothum.thodi@...wei.com
Subject: Re: [PATCH V8 mlx5-next 09/15] vfio: Define device migration
 protocol v2

On Thu, Feb 24, 2022 at 11:41:44AM +0100, Cornelia Huck wrote:
> On Wed, Feb 23 2022, Jason Gunthorpe <jgg@...dia.com> wrote:
> 
> > On Wed, Feb 23, 2022 at 06:06:13PM +0100, Cornelia Huck wrote:
> >> On Sun, Feb 20 2022, Yishai Hadas <yishaih@...dia.com> wrote:
> 
> >> > +/*
> >> > + * Indicates the device can support the migration API through
> >> > + * VFIO_DEVICE_FEATURE_MIG_DEVICE_STATE. If present flags must be non-zero and
> >> > + * VFIO_DEVICE_FEATURE_MIG_DEVICE_STATE is supported. The RUNNING and
> >> 
> >> I'm having trouble parsing this. I think what it tries to say is that at
> >> least one of the flags defined below must be set?
> >> 
> >> > + * ERROR states are always supported if this GET succeeds.
> >> 
> >> What about the following instead:
> >> 
> >> "Indicates device support for the migration API through
> >> VFIO_DEVICE_FEATURE_MIG_DEVICE_STATE. If present, the RUNNING and ERROR
> >> states are always supported. Support for additional states is indicated
> >> via the flags field; at least one of the flags defined below must be
> >> set."
> >
> > Almost, 'at least VFIO_MIGRATION_STOP_COPY must be set'
> 
> It feels a bit odd to split the mandatory states between a base layer
> (RUNNING/ERROR) and the ones governed by VFIO_MIGRATION_STOP_COPY. Do we
> want to keep the possibility of a future implementation that does not
> use the semantics indicated by VFIO_MIGRATION_STOP_COPY? 

Yes we do, and when we do that the documentation can reflect that
world. Today, as is, it is mandatory.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ