> From: Tian, Kevin > Sent: Friday, June 17, 2022 11:59 AM > > > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > > Sent: Friday, June 17, 2022 7:01 AM > > > > The whole mig_ops handling seems rather ad-hoc to me. What tells a > > developer when mig_ops can be set? Can they be unset? Does this > > enable a device feature callout to dynamically enable migration? Why do > > we init the device with vfio_device_ops, but then open code per driver > > setting vfio_migration_ops? > > > > A simpler fix could be treating device->migration_flags==0 as indicator > of no support of migration. w/o additional flags only RUNNING and > ERROR states are supported which cannot support migration. Failing > the related device feature ops in such case sounds clearer to me. Actually this check is anyway required given the uAPI requires STOP_COPY **must** be supported: /* * Indicates the device can support the migration API through * VFIO_DEVICE_FEATURE_MIG_DEVICE_STATE. If this GET succeeds, the RUNNING and * ERROR states are always supported. Support for additional states is * indicated via the flags field; at least VFIO_MIGRATION_STOP_COPY must be * set.
