> From: Jason Gunthorpe <j...@nvidia.com>
> Sent: Friday, October 13, 2023 10:08 PM
>
> On Fri, Oct 13, 2023 at 08:52:07AM +0000, Tian, Kevin wrote:
> > > From: Cao, Yahui <yahui....@intel.com>
> > > Sent: Monday, September 18, 2023 2:26 PM
> > >
> > > +static struct file *
> > > +ice_vfio_pci_step_device_state_locked(struct ice_vfio_pci_core_device
> > > *ice_vdev,
> > > + u32 new, u32 final)
> > > +{
> > > + u32 cur = ice_vdev->mig_state;
> > > + int ret;
> > > +
> > > + if (cur == VFIO_DEVICE_STATE_RUNNING && new ==
> > > VFIO_DEVICE_STATE_RUNNING_P2P) {
> > > + ice_migration_suspend_dev(ice_vdev->pf, ice_vdev->vf_id);
> > > + return NULL;
> > > + }
> > > +
> > > + if (cur == VFIO_DEVICE_STATE_RUNNING_P2P && new ==
> > > VFIO_DEVICE_STATE_STOP)
> > > + return NULL;
> > > +
> >
> > Jason, above is one open which your clarification is appreciated.
> >
> > From my talk with Yahui this device can drain/stop outgoing
> > traffic but has no interface to stop incoming request.
>
> > is it OK to do nothing for RUNNING_P2P->STOP transition like above?
>
> Yes.
>
> The purpose of RUNNING_P2P->STOP is to allow the device to do anything
> it may need to stop internal autonomous operations prior to doing a
> get_state. If the device does not have such a concept then a NOP is
> fine.
>
Thanks. this is clear then.
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
