[RFC] drm/i915: Allow dmabuf mmap forwarding

Christian König christian.koenig at amd.com
Wed Dec 13 14:13:48 UTC 2023


Am 13.12.23 um 12:46 schrieb Tvrtko Ursulin:
>
> Hi,
>
> On 12/12/2023 14:10, Christian König wrote:
>> Hi Tvrtko,
>>
>> Thanks for pointing this mail out once more, I've totally missed it.
>
> That's okay, if it was really urgent I would have re-raised the thread 
> earlier. :) As it stands so far it is only about acceptance test 
> suites failing and no known real use cases affected.
>
>> Am 12.12.23 um 11:37 schrieb Tvrtko Ursulin:
>>>
>>> On 25/09/2023 14:16, Tvrtko Ursulin wrote:
>>>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>>>
>>>> Allow mmap forwarding for imported buffers in order to allow 
>>>> minigbm mmap
>>>> to work on aperture-less platforms such as Meteorlake.
>>>>
>>>> So far i915 did not allow mmap on imported buffers but from minigbm
>>>> perspective that worked because of the DRM_IOCTL_I915_GEM_MMAP_GTT 
>>>> fall-
>>>> back would then be attempted, and would be successful.
>>>>
>>>> This stops working on Meteorlake since there is no aperture.
>>>>
>>>> Allow i915 to mmap imported buffers using forwarding via 
>>>> dma_buf_mmap(),
>>>> which allows the primary minigbm path of 
>>>> DRM_IOCTL_I915_GEM_MMAP_OFFSET /
>>>> I915_MMAP_OFFSET_WB to work.
>>>>
>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>>> Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
>>>> Cc: Christian König <christian.koenig at amd.com>
>>>> Cc: Matthew Auld <matthew.auld at intel.com>
>>>> Cc: Nirmoy Das <nirmoy.das at intel.com>
>>>> ---
>>>> 1)
>>>> It is unclear to me if any real userspace depends on this, but 
>>>> there are
>>>> certainly compliance suites which fail.
>>
>> Well that is actually intentional, but see below.
>>
>>>>
>>>> 2)
>>>> It is also a bit unclear to me if dma_buf_mmap() is exactly 
>>>> intended for
>>>> this kind of use. It seems that it is, but I also found some old 
>>>> mailing
>>>> list discussions suggesting there might be some unresolved questions
>>>> around VMA revocation.
>>
>> I actually solved those a few years back by introducing the 
>> vma_set_file() function which standardized the dance necessary for 
>> the dma_buf_mmap() function.
>>
>>>>
>>>> 1 + 2 = RFC for now.
>>>>
>>>> Daniel and Christian were involved in 2) in the past so comments would
>>>> be appreciated.
>>>
>>> Any comments on this one? I don't have all the historical knowledge 
>>> of when this was maybe attempted before and what problems were hit, 
>>> or something. So would there be downsides or it is fine to forward it.
>>
>> It works technically inside the kernel and Thomas Zimmerman suggested 
>> a patch set which made it possible to use for all DRM drivers.
>>
>> But IIRC this patch set was rejected with the rational that while 
>> doing an mmap() on an imported DMA-buf works when userspace actually 
>> does this then there is a bug in userspace. The UMD doesn't seems to 
>> be aware of the fact that the buffer is imported and so for example 
>> needs to call dma_buf_begin_cpu_access() and dma_buf_end_cpu_access().
>>
>> UMDs can trivially work around this by doing the mmap() on the 
>> DMA-buf file descriptor instead (potentially after re-exporting it), 
>> but the kernel really shouldn't help hide userspace bugs.
>
> Hm right, however why does drm_gem_shmem_mmap:
>
>     if (obj->import_attach) {
>         ret = dma_buf_mmap(obj->dma_buf, vma, 0);

Honestly I have absolutely no idea.

> Isn't that allowing drivers which use the helper to to forward to 
> dma_buf_mmap?

Yes, Daniel mentioned that some drivers did this before we found that 
it's actually not a good idea. It could be that this code piece was 
meant with that and we only allow it to avoid breaking UAPI.

Never the less I think we should add documentation for this.

> Maybe I am getting lost in the forest of callbacks in this area.. 
> Because it is supposed to be about shmem objects, but drivers which 
> use the helper and rely on common prime import look and also use 
> drm_gem_shmem_prime_import_sg_table can get there.

I don't fully understand it either of hand.

Regards,
Christian.

>
> Regards,
>
> Tvrtko
>
>>>>
>>>> Test-with: 20230925131539.32743-1-tvrtko.ursulin at linux.intel.com
>>>>
>>>> ---
>>>>   drivers/gpu/drm/i915/gem/i915_gem_mman.c      | 78 
>>>> +++++++++++++++----
>>>>   .../gpu/drm/i915/gem/i915_gem_object_types.h  |  1 +
>>>>   2 files changed, 65 insertions(+), 14 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
>>>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>> index aa4d842d4c5a..78c84c0a8b08 100644
>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>> @@ -5,6 +5,7 @@
>>>>    */
>>>>     #include <linux/anon_inodes.h>
>>>> +#include <linux/dma-buf.h>
>>>>   #include <linux/mman.h>
>>>>   #include <linux/pfn_t.h>
>>>>   #include <linux/sizes.h>
>>>> @@ -664,6 +665,7 @@ insert_mmo(struct drm_i915_gem_object *obj, 
>>>> struct i915_mmap_offset *mmo)
>>>>   static struct i915_mmap_offset *
>>>>   mmap_offset_attach(struct drm_i915_gem_object *obj,
>>>>              enum i915_mmap_type mmap_type,
>>>> +           bool forward_mmap,
>>>>              struct drm_file *file)
>>>>   {
>>>>       struct drm_i915_private *i915 = to_i915(obj->base.dev);
>>>> @@ -682,6 +684,7 @@ mmap_offset_attach(struct drm_i915_gem_object 
>>>> *obj,
>>>>         mmo->obj = obj;
>>>>       mmo->mmap_type = mmap_type;
>>>> +    mmo->forward_mmap = forward_mmap;
>>>>       drm_vma_node_reset(&mmo->vma_node);
>>>>         err = drm_vma_offset_add(obj->base.dev->vma_offset_manager,
>>>> @@ -714,12 +717,25 @@ mmap_offset_attach(struct drm_i915_gem_object 
>>>> *obj,
>>>>       return ERR_PTR(err);
>>>>   }
>>>>   +static bool
>>>> +should_forward_mmap(struct drm_i915_gem_object *obj,
>>>> +            enum i915_mmap_type mmap_type)
>>>> +{
>>>> +    if (!obj->base.import_attach)
>>>> +        return false;
>>>> +
>>>> +    return mmap_type == I915_MMAP_TYPE_WB ||
>>>> +           mmap_type == I915_MMAP_TYPE_WC ||
>>>> +           mmap_type == I915_MMAP_TYPE_UC;
>>>> +}
>>>> +
>>>>   static int
>>>>   __assign_mmap_offset(struct drm_i915_gem_object *obj,
>>>>                enum i915_mmap_type mmap_type,
>>>>                u64 *offset, struct drm_file *file)
>>>>   {
>>>>       struct i915_mmap_offset *mmo;
>>>> +    bool should_forward;
>>>>         if (i915_gem_object_never_mmap(obj))
>>>>           return -ENODEV;
>>>> @@ -735,12 +751,15 @@ __assign_mmap_offset(struct 
>>>> drm_i915_gem_object *obj,
>>>>       if (mmap_type == I915_MMAP_TYPE_FIXED)
>>>>           return -ENODEV;
>>>>   +    should_forward = should_forward_mmap(obj, mmap_type);
>>>> +
>>>>       if (mmap_type != I915_MMAP_TYPE_GTT &&
>>>>           !i915_gem_object_has_struct_page(obj) &&
>>>> -        !i915_gem_object_has_iomem(obj))
>>>> +        !i915_gem_object_has_iomem(obj) &&
>>>> +        !should_forward)
>>>>           return -ENODEV;
>>>>   -    mmo = mmap_offset_attach(obj, mmap_type, file);
>>>> +    mmo = mmap_offset_attach(obj, mmap_type, should_forward, file);
>>>>       if (IS_ERR(mmo))
>>>>           return PTR_ERR(mmo);
>>>>   @@ -936,6 +955,32 @@ static struct file *mmap_singleton(struct 
>>>> drm_i915_private *i915)
>>>>       return file;
>>>>   }
>>>>   +static void
>>>> +__vma_mmap_pgprot(struct vm_area_struct *vma, enum i915_mmap_type 
>>>> mmap_type)
>>>> +{
>>>> +    const pgprot_t pgprot =vm_get_page_prot(vma->vm_flags);
>>>> +
>>>> +    switch (mmap_type) {
>>>> +    case I915_MMAP_TYPE_WC:
>>>> +        vma->vm_page_prot = pgprot_writecombine(pgprot);
>>>> +        break;
>>>> +    case I915_MMAP_TYPE_FIXED:
>>>> +        GEM_WARN_ON(1);
>>>> +        fallthrough;
>>>> +    case I915_MMAP_TYPE_WB:
>>>> +        vma->vm_page_prot = pgprot;
>>>> +        break;
>>>> +    case I915_MMAP_TYPE_UC:
>>>> +        vma->vm_page_prot = pgprot_noncached(pgprot);
>>>> +        break;
>>>> +    case I915_MMAP_TYPE_GTT:
>>>> +        vma->vm_page_prot = pgprot_writecombine(pgprot);
>>>> +        break;
>>>> +    }
>>>> +
>>>> +    vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
>>>> +}
>>>> +
>>>>   static int
>>>>   i915_gem_object_mmap(struct drm_i915_gem_object *obj,
>>>>                struct i915_mmap_offset *mmo,
>>>> @@ -953,6 +998,20 @@ i915_gem_object_mmap(struct 
>>>> drm_i915_gem_object *obj,
>>>>           vm_flags_clear(vma, VM_MAYWRITE);
>>>>       }
>>>>   +    /* dma-buf import */
>>>> +    if (mmo && mmo->forward_mmap) {
>>>> +        __vma_mmap_pgprot(vma, mmo->mmap_type);
>>>> +        vm_flags_set(vma, VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP 
>>>> | VM_IO);
>>>> +
>>>> +        /*
>>>> +         * Don't have our vm_ops to drop the reference in this 
>>>> case so
>>>> +         * drop it now and if object goes away userspace will fault.
>>>> +         */
>>>> +        i915_gem_object_put(mmo->obj);
>>>> +
>>>> +        return dma_buf_mmap(obj->base.dma_buf, vma, 0);
>>>> +    }
>>>> +
>>>>       anon = mmap_singleton(to_i915(dev));
>>>>       if (IS_ERR(anon)) {
>>>>           i915_gem_object_put(obj);
>>>> @@ -982,34 +1041,25 @@ i915_gem_object_mmap(struct 
>>>> drm_i915_gem_object *obj,
>>>>         vma->vm_private_data = mmo;
>>>>   +    __vma_mmap_pgprot(vma, mmo->mmap_type);
>>>> +
>>>>       switch (mmo->mmap_type) {
>>>>       case I915_MMAP_TYPE_WC:
>>>> -        vma->vm_page_prot =
>>>> - pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
>>>>           vma->vm_ops = &vm_ops_cpu;
>>>>           break;
>>>> -
>>>>       case I915_MMAP_TYPE_FIXED:
>>>>           GEM_WARN_ON(1);
>>>>           fallthrough;
>>>>       case I915_MMAP_TYPE_WB:
>>>> -        vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>>>>           vma->vm_ops = &vm_ops_cpu;
>>>>           break;
>>>> -
>>>>       case I915_MMAP_TYPE_UC:
>>>> -        vma->vm_page_prot =
>>>> - pgprot_noncached(vm_get_page_prot(vma->vm_flags));
>>>>           vma->vm_ops = &vm_ops_cpu;
>>>>           break;
>>>> -
>>>>       case I915_MMAP_TYPE_GTT:
>>>> -        vma->vm_page_prot =
>>>> - pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
>>>>           vma->vm_ops = &vm_ops_gtt;
>>>>           break;
>>>>       }
>>>> -    vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
>>>>         return 0;
>>>>   }
>>>> @@ -1084,7 +1134,7 @@ int i915_gem_fb_mmap(struct 
>>>> drm_i915_gem_object *obj, struct vm_area_struct *vma
>>>>       } else {
>>>>           /* handle stolen and smem objects */
>>>>           mmap_type = i915_ggtt_has_aperture(ggtt) ? 
>>>> I915_MMAP_TYPE_GTT : I915_MMAP_TYPE_WC;
>>>> -        mmo = mmap_offset_attach(obj, mmap_type, NULL);
>>>> +        mmo = mmap_offset_attach(obj, mmap_type, false, NULL);
>>>>           if (IS_ERR(mmo))
>>>>               return PTR_ERR(mmo);
>>>>       }
>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
>>>> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>>>> index 0c5cdab278b6..b4f86fa020aa 100644
>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>>>> @@ -225,6 +225,7 @@ struct i915_mmap_offset {
>>>>       struct drm_vma_offset_node vma_node;
>>>>       struct drm_i915_gem_object *obj;
>>>>       enum i915_mmap_type mmap_type;
>>>> +    bool forward_mmap;
>>>>         struct rb_node offset;
>>>>   };
>>



More information about the Intel-gfx mailing list