Re: [PATCH] drm/xe/display: skip FORCE_WC and vm_bound check for external dma-bufs

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

On Fri, 2026-06-26 at 10:09 +0100, Matthew Auld wrote:
> On 25/06/2026 16:35, Maarten Lankhorst wrote:
> > Hello,
> > 
> > On 6/12/26 19:05, Matthew Auld wrote:
> > > Currently, xe_display_bo_framebuffer_init() unconditionally
> > > attempts to
> > > apply XE_BO_FLAG_FORCE_WC to the buffer and rejects the FB
> > > creation with
> > > -EINVAL if the BO is already VM_BINDed.
> > > 
> > > However, for imported dma-bufs (ttm_bo_type_sg), this check
> > > doesn't seem
> > > to make much sense since CPU caching policy is entirely
> > > controlled by
> > > the exporter. Plus there is no place to set this flag, in the
> > > first
> > > place. Also this is not rejected if not yet vm_binded, but that
> > > seems
> > > arbitrary since setting or not setting FORCE_WC should a noop
> > > either
> > > way, at this stage, and whether it is currently VM_BINDed makes
> > > no
> > > difference.
> > > 
> > > Currently if we run an app and offload rendering to an external
> > > dGPU,
> > > like NV or another xe device, the dma-buf passed back to the
> > > compositor
> > > (igpu) will be an actual external import from xe pov, and it will
> > > be
> > > missing FORCE_WC, and if the compositor side did a VM_BIND before
> > > turning into it into an fb the whole thing gets rejected.
> > > 
> > > So it looks like we either need to reject outright, no matter
> > > what, or
> > > this usecase is valid and we need to loosen the restriction for
> > > sg
> > > buffers.  Proposing here to loosen the restriction.
> > > 
> > > Assisted-by: Gemini:gemini-3.1-pro-preview
> > > Link:
> > > https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7919
> > > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > Cc: Maarten Lankhorst <dev@lankhorst.se>
> > > ---
> > >   drivers/gpu/drm/xe/display/xe_display_bo.c | 3 ++-
> > >   drivers/gpu/drm/xe/display/xe_fb_pin.c     | 3 ++-
> > >   2 files changed, 4 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/xe/display/xe_display_bo.c
> > > b/drivers/gpu/drm/xe/display/xe_display_bo.c
> > > index 7fbac223b097..8953da0136dc 100644
> > > --- a/drivers/gpu/drm/xe/display/xe_display_bo.c
> > > +++ b/drivers/gpu/drm/xe/display/xe_display_bo.c
> > > @@ -48,7 +48,8 @@ static int
> > > xe_display_bo_framebuffer_init(struct drm_gem_object *obj,
> > >   	if (ret)
> > >   		goto err;
> > >   
> > > -	if (!(bo->flags & XE_BO_FLAG_FORCE_WC)) {
> > > +	if (!(bo->flags & XE_BO_FLAG_FORCE_WC) &&
> > > +	    bo->ttm.type != ttm_bo_type_sg) {
> > >   		/*
> > >   		 * XE_BO_FLAG_FORCE_WC should ideally be set at
> > > creation, or is
> > >   		 * automatically set when creating FB. We cannot
> > > change caching
> > > diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c
> > > b/drivers/gpu/drm/xe/display/xe_fb_pin.c
> > > index f93c98bec5b5..5f4a0cd8deca 100644
> > > --- a/drivers/gpu/drm/xe/display/xe_fb_pin.c
> > > +++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c
> > > @@ -331,7 +331,8 @@ static struct i915_vma
> > > *__xe_pin_fb_vma(struct drm_gem_object *obj, bool is_dpt,
> > >   	int ret = 0;
> > >   
> > >   	/* We reject creating !SCANOUT fb's, so this is weird..
> > > */
> > > -	drm_WARN_ON(bo->ttm.base.dev, !(bo->flags &
> > > XE_BO_FLAG_FORCE_WC));
> > > +	drm_WARN_ON(bo->ttm.base.dev, !(bo->flags &
> > > XE_BO_FLAG_FORCE_WC) &&
> > > +		    bo->ttm.type != ttm_bo_type_sg);
> > >   
> > >   	if (!vma)
> > >   		return ERR_PTR(-ENODEV);
> > 
> > Yeah we cannot actually set the force flag on imported bo's for
> > mmap coherency, but mmap on an imported dma-buf should be forbidden
> > anyway, so that is fine.
> > 
> > Best we can hope for is that dirtyfb is called correctly.
> > 
> > Reviewed-by: Maarten Lankhorst <dev@lankhorst.se>
> 
> Thanks!
> 
> > 
Hi,

Is there a chance an attacker could create a dma-buf on device 1,
export it to device 2, then scan out from it while the clearing still
sits in the CPU cache?

We have a forced flush for this situation in the i915 driver, right?

/Thomas