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

Gerd Hoffmann kraxel at redhat.com
Fri Sep 29 10:20:45 UTC 2017


  Hi,

> For example, if the old reused dmabuf_obj is released just after
> query ioctl return it,  the next get_fd ioctl would
> return error as the dmabuf_obj has already been closed.

My branch already grabs an extra reference when creating a new
dmabuf_obj, which will be dropped on GET_DMABUF ioctl, exactly to avoid
the dmabuf_obj disappear between QUERY_PLANE and GET_DMABUF ioctls.

Can easily be extended to handle the reuse case too.

https://www.kraxel.org/cgit/linux/commit/?h=gvt-dmabuf-v14&id=9959109ae
52cf15e119715a6b7de080fb849e3d2

While being at it also cleanup properly on close (so we don't leak
structs in case userspace never calls GET_DMABUF for a plane).

https://www.kraxel.org/cgit/linux/commit/?h=gvt-dmabuf-v14&id=c0b0c407e
33904e749dec1ef44ec01099c16d39f

> > > Do you think the fd interface is enough for all kinds of buffer
> > > exposed by Mdev?
> > 
> > What kind of buffers do you have in mind which might not be
> > covered?
> 
> I thinking about the case that would like to postpone the buffers
> releasing operation, after user space has closed all the fd.

Work fine.  qemu can import the dma-buf as opengl texture, which
creates a extra reference.  Then close the fd.  dma-buf continues to
exist as long as the texture referencing it exists.

> Later these buffers may be used to expose to other kinds of fd to
> user space.

Sorry, I don't understand that sentence.

cheers,
  Gerd



More information about the Intel-gfx mailing list