On Thu, 24 Feb 2022 16:21:11 +0100
Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
> On Thu, Feb 24 2022, Yishai Hadas <yishaih@xxxxxxxxxx> 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
