RE: [PATCH 26/26] vfio/xe: Add vendor-specific vfio_pci driver for Intel graphics

Tian, Kevin
2025-10-27T07:02:21Z

> From: Winiarski, Michal <michal.winiarski@intel.com>
> 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.