On Mon, 26 Jun 2017 08:39:17 +0200 Gerd Hoffmann <kra...@redhat.com> wrote:
> 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. Hmm, I don't like that interface. Can you cite examples of other ioctls that behave this way? It doesn't feel like an elegant user interface; the user can get the dmabuf, but only after they query the dmabuf, even though the get-dmabuf ioctl returns the same data as the query-plane ioctl, but they can't get the dmabuf if the plane has changed in the interim, which is not something the user can know. Are we causing our own problems with this model of cycling through dmabuf fds? We talked previously about an enum of plane types, primary and cursor. What if the user was simply able to get a dmabuf fd for each of those and they queried the current plane information via those fds? IOW, the fd is persistent and specific to a given plane type, but the format within it is dynamic. For instance, I don't have a separate monitor on my desktop for each resolution I want to run, the monitor adapts to the signal it gets. I don't grasp the technical reasons why the user can't stop using the dmabuf fd with the previous format parameters and start using it with the new parameters. Maybe the user even has multiple dmabuf fds open, but they switch to only actively using then one(s) that match the current format. I don't know if that's viable, but there seems to be a fundamental synchronization issue if a given dmabuf fd only represents a transient state. Thanks, Alex _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
