[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