Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

[Gerd Hoffmann]

  Hi,

> > +static long intel_vgpu_dmabuf_mgr_fd_ioctl(struct file *filp,
> > +               unsigned int ioctl, unsigned long arg)
> > +{
> > +       struct intel_vgpu *vgpu = filp->private_data;
> > +       int minsz;
> > +       struct intel_vgpu_dmabuf dmabuf;
> > +       int ret;
> > +       struct fd f;
> > +       f = fdget(dmabuf.fd);
> > +       minsz = offsetofend(struct intel_vgpu_dmabuf, tiled);
> > +       if (copy_from_user(&dmabuf, (void __user *)arg, minsz))
> > +               return -EFAULT;
> > +       if (ioctl == INTEL_VGPU_QUERY_DMABUF)
> > +               ret = intel_gvt_ops->vgpu_query_dmabuf(vgpu, &dmabuf);
> > +       else if (ioctl == INTEL_VGPU_GENERATE_DMABUF)
> > +               ret = intel_gvt_ops->vgpu_generate_dmabuf(vgpu, &dmabuf);
> 
> Why do we need vendor specific ioctls here?  Aren't querying the
> current plane and getting an fd for that plane very generic concepts? 
> Is the resulting dmabuf Intel specific?

The dmabuf certainly isn't, and I think the ioctl interface can easily
be made pretty generic too.  The struct intel_vgpu_dmabuf hasn't much
intel-specific bits in there.  The only thing is the tiled bool, and I
think that can be replaced with a modifier code field (see
fourcc_mod_code() in drm/drm_fourcc.h).

Apparently the amd guys are working on vcpu support too, but using sriov
instead of mdev (saw this in the news only, have no more details).  They
can possibly support such an interface too.

cheers,
  Gerd