Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Alex Williamson]

On Mon, 26 Jun 2017 08:39:17 +0200
Gerd Hoffmann <kraxel@xxxxxxxxxx> 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