netdev - Re: [PATCH V8 mlx5-next 09/15] vfio: Define device migration protocol v2

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: <87ilt47dhz.fsf@redhat.com>
Date:   Thu, 24 Feb 2022 11:41:44 +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, 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 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? If yes, it
should be "one of the flags" and the flags that require
VFIO_MIGRATION_STOP_COPY to be set as well need to note that
dependency. If not, we should explicitly tag VFIO_MIGRATION_STOP_COPY as
mandatory (so that the flag's special status is obvious.)