> -----Original Message----- > From: Gerd Hoffmann [mailto:kraxel@xxxxxxxxxx] > Sent: Friday, September 29, 2017 6:21 PM > To: Zhang, Tina <tina.zhang@xxxxxxxxx>; zhenyuw@xxxxxxxxxxxxxxx; Wang, Zhi > A <zhi.a.wang@xxxxxxxxx>; Tian, Kevin <kevin.tian@xxxxxxxxx>; Alex > Williamson <alex.williamson@xxxxxxxxxx> > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; > intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx; Lv, Zhiyuan <zhiyuan.lv@xxxxxxxxx> > Subject: Re: [PATCH v14 5/7] vfio: ABI for mdev display dma-buf operation > > 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. Yeah, that could solve the problem. But I'm not sure if it could be acceptable. Zhenyu, can you share your comments? Thanks. BR, Tina > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
