> From: Alex Williamson <alex.williamson@xxxxxxxxxx>
> Sent: Friday, December 8, 2023 6:43 AM
> > +
> > + 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;
>
> This looks suspicious, are we actually able to freeze the internal
> device state? It should happen here.
>
> * RUNNING_P2P -> STOP
> * STOP_COPY -> STOP
> * While in STOP the device must stop the operation of the device. The
> device
> * must not generate interrupts, DMA, or any other change to external state.
> * It must not change its internal state. When stopped the device and kernel
> * migration driver must accept and respond to interaction to support
> external
> * subsystems in the STOP state, for example PCI MSI-X and PCI config space.
> * Failure by the user to restrict device access while in STOP must not result
> * in error conditions outside the user context (ex. host system faults).
> *
> * The STOP_COPY arc will terminate a data transfer session.
>
It was discussed in v3 [1].
This device only provides a way to drain/stop outgoing traffic (for
RUNNING->RUNNING_P2P). No interface for stopping the incoming
requests.
Jason explained that RUNNING_P2P->STOP transition can be a 'nop' as long
as there is guarantee that the device state is frozen at this point.
By definition the user should request this transition only after all devices
are put in RUNNING_P2P. At that point no one is sending P2P requests to
further affect the internal state of this device. Then an explicit "stop
responder" action is not strictly required and 'nop' can still meet
above definition.
