[Intel-gfx] [PATCH v14 5/7] vfio: ABI for mdev display dma-buf operation

[Gerd Hoffmann]

  Hi,

> So, there is a problem about the releasing cached dmabuf_obj. We
> cannot rely on the drm_i915_gem_object_ops.release() to release the
> cached dmabuf_obj,
> as this release operation is running in another thread, which leads
> to a racing condition and tricky to be solved without touching other
> modules.

PLANE_INFO just creates a intel_vgpu_dmabuf_obj.

GET_DMABUF creates a fresh proxy gem object and dmabuf.

proxy gem object references intel_vgpu_dmabuf_obj but not the other way
around.  Then you can simply refcount intel_vgpu_dmabuf_obj and be done
with it.

https://www.kraxel.org/cgit/linux/commit/?h=gvt-dmabuf-v14&id=350a0e834
971e6f53d7235d8b6167bed4dccf074

Note: Patch renamed intel_vgpu_dmabuf_obj to intel_vgpu_fb_obj, because
it doesn't refer to dmabufs any more.  It basically carries the guest
plane/framebuffer information and the ID associated with it.

> So, in order to solve that kind of problem, I’d like to add one more
> ioctl, which is used for user mode to close the dmabuf_obj. 

Depending on userspace notifying the kernel for that kind of cleanups
is a bad idea.  What happens in case userspace crashes?  Do you leak
dmabufs then?

cheers,
  Gerd