Hi Gerd, > > > > > > > dmabuf->buf.fd = res->dmabuf_fd; > > > > + dmabuf->buf.blob = true; > > > > > > Do you actually need the 'blob' field? > > > I think checking 'fd' instead should work too. > > [Kasireddy, Vivek] I want these changes to be limited to blob resources > > only as I do not > > know how they might affect other use-cases or whether they are needed there > > or not. I > > don't think I can rely on fd as vfio/display.c also populates the fd field: > > dmabuf = g_new0(VFIODMABuf, 1); > > dmabuf->dmabuf_id = plane.dmabuf_id; > > dmabuf->buf.width = plane.width; > > dmabuf->buf.height = plane.height; > > dmabuf->buf.stride = plane.stride; > > dmabuf->buf.fourcc = plane.drm_format; > > dmabuf->buf.modifier = plane.drm_format_mod; > > dmabuf->buf.fd = fd; > > > > Therefore, I need a way to identify a dmabuf that is associated with blobs > > vs others. > > And it actually is a dma-buf too (the guest display provided by i915 gvt > mdev driver). So fencing that should work, right? [Kasireddy, Vivek] Well, for virtio-gpu, as you know we are adding a dma fence to resource_flush to make it wait until it gets signalled by Qemu. We might have to do to something similar on i915 GVT side but I do not have the hardware to write a patch and test it out -- as i915 GVT is not supported for > Gen 9 platforms.
> > Even if we have to restrict it to some kinds of dma-bufs the field > should have a more descriptive name like "allow_fences". [Kasireddy, Vivek] I think limiting this to blobs makes sense at the moment. If need be, we can extend it to include dma-bufs generated by i915 GVT later. Let me send a v4 with your suggestion to change the name. Thanks, Vivek > > take care, > Gerd
