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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
