From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755068AbdEDQIk (ORCPT ); Thu, 4 May 2017 12:08:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41310 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753210AbdEDQIh (ORCPT ); Thu, 4 May 2017 12:08:37 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5915E80E7D Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=alex.williamson@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5915E80E7D Date: Thu, 4 May 2017 10:08:33 -0600 From: Alex Williamson To: "Chen, Xiaoguang" Cc: "Tian, Kevin" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "zhenyuw@linux.intel.com" , "Lv, Zhiyuan" , "intel-gvt-dev@lists.freedesktop.org" , "Wang, Zhi A" , Gerd Hoffmann Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf Message-ID: <20170504100833.199bc8ba@t450s.home> In-Reply-To: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 04 May 2017 16:08:37 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 4 May 2017 03:09:40 +0000 "Chen, Xiaoguang" wrote: > Hi Alex, do you have any comments for this interface? > > >-----Original Message----- > >From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@lists.freedesktop.org] On > >Behalf Of Chen, Xiaoguang > >Sent: Wednesday, May 03, 2017 9:39 AM > >To: Gerd Hoffmann > >Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org; linux- > >kernel@vger.kernel.org; zhenyuw@linux.intel.com; alex.williamson@redhat.com; > >Lv, Zhiyuan ; intel-gvt-dev@lists.freedesktop.org; Wang, > >Zhi A > >Subject: RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf > > > > > > > >>-----Original Message----- > >>From: Gerd Hoffmann [mailto:kraxel@redhat.com] > >>Sent: Tuesday, May 02, 2017 5:51 PM > >>To: Chen, Xiaoguang > >>Cc: alex.williamson@redhat.com; intel-gfx@lists.freedesktop.org; > >>intel-gvt- dev@lists.freedesktop.org; Wang, Zhi A > >>; zhenyuw@linux.intel.com; > >>linux-kernel@vger.kernel.org; Lv, Zhiyuan ; Tian, > >>Kevin > >>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the > >>dmabuf > >> > >>On Fr, 2017-04-28 at 17:35 +0800, Xiaoguang Chen wrote: > >>> +static size_t intel_vgpu_reg_rw_gvtg(struct intel_vgpu *vgpu, char > >>> *buf, > >>> + size_t count, loff_t *ppos, bool iswrite) { > >>> + unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) - > >>> + VFIO_PCI_NUM_REGIONS; > >>> + loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK; > >>> + int fd; > >>> + > >>> + if (pos >= vgpu->vdev.region[i].size || iswrite) { > >>> + gvt_vgpu_err("invalid op or offset for Intel vgpu fd > >>> region\n"); > >>> + return -EINVAL; > >>> + } > >>> + > >>> + fd = anon_inode_getfd("gvtg", &intel_vgpu_gvtg_ops, vgpu, > >>> + O_RDWR | O_CLOEXEC); > >>> + if (fd < 0) { > >>> + gvt_vgpu_err("create intel vgpu fd failed:%d\n", fd); > >>> + return -EINVAL; > >>> + } > >>> + > >>> + count = min(count, (size_t)(vgpu->vdev.region[i].size - pos)); > >>> + memcpy(buf, &fd, count); > >>> + > >>> + return count; > >>> +} > >> > >>Hmm, that looks like a rather strange way to return a file descriptor. > >> > >>What is the reason to not use ioctls on the vfio file handle, like > >>older version of these patches did? > >If I understood correctly that Alex prefer not to change the ioctls on the vfio file > >handle like the old version. > >So I used this way the smallest change to general vfio framework only adding a > >subregion definition. I think I was hoping we could avoid a separate file descriptor altogether and use a vfio region instead. However, it was explained previously why this really needs to be a separate fd and I agree that using a region to expose an fd is really awkward. If we're going to have a separate fd, let's use a device specific ioctl to get it. Thanks, Alex