Re: [PATCH V9 mlx5-next 10/15] vfio: Extend the device migration protocol with RUNNING_P2P

[Alex Williamson <alex.williamson@redhat.com>]

On Thu, 24 Feb 2022 16:21:11 +0100
Cornelia Huck <cohuck@redhat.com> wrote:

> On Thu, Feb 24 2022, Yishai Hadas <yishaih@nvidia.com> wrote:
> 
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index 22ed358c04c5..26a66f68371d 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -1011,10 +1011,16 @@ struct vfio_device_feature {
> >   *
> >   * VFIO_MIGRATION_STOP_COPY means that STOP, STOP_COPY and
> >   * RESUMING are supported.
> > + *
> > + * VFIO_MIGRATION_STOP_COPY | VFIO_MIGRATION_P2P means that RUNNING_P2P
> > + * is supported in addition to the STOP_COPY states.
> > + *
> > + * Other combinations of flags have behavior to be defined in the future.
> >   */
> >  struct vfio_device_feature_migration {
> >  	__aligned_u64 flags;
> >  #define VFIO_MIGRATION_STOP_COPY	(1 << 0)
> > +#define VFIO_MIGRATION_P2P		(1 << 1)
> >  };  
> 
> Coming back to my argument (for the previous series) that this should
> rather be "at least one of the flags below must be set". If we operate
> under the general assumption that each flag indicates that a certain
> functionality (including some states) is supported, and that flags may
> depend on other flags, we might have a future flag that defines a
> different behaviour, but does not depend on STOP_COPY, but rather
> conflicts with it. We should not create the impression that STOP_COPY
> will neccessarily be mandatory for all time.

This sounds more like an enum than a bitfield.  What happens when
VFIO_MIGRATION_FOO is defined that can be combined with either
STOP_COPY or P2P, do we then add two new enum values, one with, one
without?  Using a bitfield seems cleaner here.  Reporting P2P alone is
invalid because it doesn't provide a sufficient FSM, but we might also
later define STOP_COPYv2 and possibly it might be compatible with the
existing P2P definition.  Thanks,

Alex