> From: Winiarski, Michal <[email protected]> > Sent: Wednesday, October 22, 2025 5:05 PM > > On Tue, Oct 21, 2025 at 08:03:28PM -0300, Jason Gunthorpe wrote: > > On Sat, Oct 11, 2025 at 09:38:47PM +0200, Michał Winiarski wrote: > > > + /* > > > + * "STOP" handling is reused for "RUNNING_P2P", as the device > doesn't have the capability to > > > + * selectively block p2p DMA transfers. > > > + * The device is not processing new workload requests when the VF is > stopped, and both > > > + * memory and MMIO communication channels are transferred to > destination (where processing > > > + * will be resumed). > > > + */ > > > + if ((cur == VFIO_DEVICE_STATE_RUNNING && new == > VFIO_DEVICE_STATE_STOP) || > > > + (cur == VFIO_DEVICE_STATE_RUNNING && new == > VFIO_DEVICE_STATE_RUNNING_P2P)) { > > > + ret = xe_sriov_vfio_stop(xe_vdev->pf, xe_vdev->vfid); > > > > This comment is not right, RUNNING_P2P means the device can still > > receive P2P activity on it's BAR. Eg a GPU will still allow read/write > > to its framebuffer. > > > > But it is not initiating any new transactions. > > /* > * "STOP" handling is reused for "RUNNING_P2P", as the device doesn't > * have the capability to selectively block outgoing p2p DMA transfers. > * While the device is allowing BAR accesses when the VF is stopped, it > * is not processing any new workload requests, effectively stopping > * any outgoing DMA transfers (not just p2p). > * Both memory and MMIO communication channels with the workload > * scheduling firmware are transferred to destination (where processing > * will be resumed). > */ > > Does this work better?
it's better to articulate that not only the device allows accessing to its MMIO regs/framebuffer but also the state of those accesses are queued/ kept and can be migrated as part of the device state later. the last sentence is somehow related to that point, but let's make it clearer.
