Hi, > > With the generation we can also do something different: Pass in > > plane_type and > > generation, and have VFIO_DEVICE_GET_DMABUF_FD return an error in > > case > > the generation doesn't match. In that case it doesn't make much > > sense any > > more to have a separate plane_info struct, which was added so we > > don't have > > to duplicate things in query-plane and get- dmabuf ioctl structs. > > Comparing with the current patch, this would make user space a little > bit harder to > get the dmabuf by calling VFIO_DEVICE_GET_DMABUF ioctl. Is it > efficient for > user mode usage? user space has to call QUERY-PLANE first, then looks if it has a dma- buf for that, if not call GET-DMABUF. Problem is the guest could have changed the plane between the QUERY- PLANE and GET-DMABUF ioctls. Current patches (v8 series) just returns plane-info on GET-DMABUF too, so userspace can at least detect something changed. It would be easier for userspace if GET-DMABUF throws an error in case the plane changed since the last QUERY-PLANE ioctl. The generation id would be one way to handle it, but possibly it is easier if the kernel driver just keeps track internally. So GET-DMABUF would be defined to return a dmabuf for the plane returned by the previous QUERY-PLANE ioctl (on the same file handle), or return an error in case the plane has changed meanwhile. cheers, Gerd _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
