From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754886AbdERGWb convert rfc822-to-8bit (ORCPT ); Thu, 18 May 2017 02:22:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41076 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754823AbdERGW2 (ORCPT ); Thu, 18 May 2017 02:22:28 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DDC63C056784 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kraxel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com DDC63C056784 Message-ID: <1495088541.627.9.camel@redhat.com> Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf From: Gerd Hoffmann To: Alex Williamson Cc: "Chen, Xiaoguang" , "Tian, Kevin" , "linux-kernel@vger.kernel.org" , "zhenyuw@linux.intel.com" , "Lv, Zhiyuan" , "intel-gvt-dev@lists.freedesktop.org" , "Wang, Zhi A" Date: Thu, 18 May 2017 08:22:21 +0200 In-Reply-To: <20170517154331.1b465f69@w520.home> References: <1493372130-27727-1-git-send-email-xiaoguang.chen@intel.com> <1493372130-27727-7-git-send-email-xiaoguang.chen@intel.com> <1493718658.8581.82.camel@redhat.com> <20170504100833.199bc8ba@t450s.home> <1493967331.371.53.camel@redhat.com> <20170505091115.7a680636@t450s.home> <1494509273.17970.12.camel@redhat.com> <20170511094526.164985ee@w520.home> <20170511205829.672854c3@t450s.home> <1494580325.14352.57.camel@redhat.com> <20170512103828.4a1378a1@t450s.home> <20170515114409.414d1fdb@w520.home> <20170517154331.1b465f69@w520.home> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 18 May 2017 06:22:28 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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