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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 18 May 2017 08:22:21 +0200
From:   Gerd Hoffmann <kraxel@...hat.com>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     "Chen, Xiaoguang" <xiaoguang.chen@...el.com>,
        "Tian, Kevin" <kevin.tian@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "zhenyuw@...ux.intel.com" <zhenyuw@...ux.intel.com>,
        "Lv, Zhiyuan" <zhiyuan.lv@...el.com>,
        "intel-gvt-dev@...ts.freedesktop.org" 
        <intel-gvt-dev@...ts.freedesktop.org>,
        "Wang, Zhi A" <zhi.a.wang@...el.com>
Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

  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