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

[Matthew Auld <matthew.auld@intel.com>]

On 03/07/2026 13:45, Thomas Hellström wrote:
> 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?

Do we class this an attack? We maybe just get some display 
dirt/corruption for the hw scanout?

If this is a concern, then yeah we likely need some flushing. Happy to 
to take a look, if needed.

Note that I think you can still do this without dma-buf, so kind of 
figured this was a known limitation. I think you can just do:

gem_create(WB + system);
populate the pages; // wb pages
promote to fb; // sets FORCE_WC which does nothing
do the actual scanout; // might see cache dirt from the clear

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

Yeah, IIRC for dma-buf, there is some kind of wbinvd_on_all_cpus() when 
we collect the sg-table. But that I think that was more being worried 
about non-scanout path, like exec() bypassing the clearing. We could do 
something like that? But still needs something extra for non dma-buf.

> 
> /Thomas