lkml.org 
[lkml]   [2017]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
    From
    Date
      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

    \
     
     \ /
      Last update: 2017-05-18 08:22    [W:3.414 / U:0.972 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site