Hi, On Mon, 2025-09-15 at 00:21 -0700, Vivek Kasireddy wrote: > If the P2P test (i.e, pci_p2pdma_distance()) is successful, then it > means that the importer can directly access the BO located in VRAM. > Therefore, in this specific case, do not migrate the BO to System > RAM before exporting it. > > Signed-off-by: Vivek Kasireddy <vivek.kasire...@intel.com> > --- > drivers/gpu/drm/xe/xe_dma_buf.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c > b/drivers/gpu/drm/xe/xe_dma_buf.c > index a7d67725c3ee..04082e3e4295 100644 > --- a/drivers/gpu/drm/xe/xe_dma_buf.c > +++ b/drivers/gpu/drm/xe/xe_dma_buf.c > @@ -52,7 +52,7 @@ static int xe_dma_buf_pin(struct dma_buf_attachment > *attach) > struct xe_bo *bo = gem_to_xe_bo(obj); > struct xe_device *xe = xe_bo_device(bo); > struct drm_exec *exec = XE_VALIDATION_UNSUPPORTED; > - int ret; > + int ret = 0; > > /* > * For now only support pinning in TT memory, for two > reasons: > @@ -64,7 +64,8 @@ static int xe_dma_buf_pin(struct dma_buf_attachment > *attach) > return -EINVAL; > } > > - ret = xe_bo_migrate(bo, XE_PL_TT, NULL, exec); > + if (!attach->peer2peer) > + ret = xe_bo_migrate(bo, XE_PL_TT, NULL, exec);
>From review of previous series: "Pinning in VRAM is an ongoing discussion and there are many reasons for allowing that. However we need to sort out how the accounting should be done and how regressions should avoided along the path to the final solution which is cgroups-based. So until that has been sorted out, there are no exceptions for special use-cases that don't fit in that plan." (I have an RFC patch out that if all stakeholders agree should fix this). https://patchwork.freedesktop.org/series/154593/ And also a question, can't the guest virtio-gpu KMD support move_notify() Does it really pin the imported VF fb fullscreen on the physical screen? Thanks, Thomas > if (ret) { > if (ret != -EINTR && ret != -ERESTARTSYS) > drm_dbg(&xe->drm,
