From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932097AbdEEGzg convert rfc822-to-8bit (ORCPT ); Fri, 5 May 2017 02:55:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20503 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755555AbdEEGzf (ORCPT ); Fri, 5 May 2017 02:55:35 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 168DC66C9F Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kraxel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 168DC66C9F Message-ID: <1493967331.371.53.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" , "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" Date: Fri, 05 May 2017 08:55:31 +0200 In-Reply-To: <20170504100833.199bc8ba@t450s.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> 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.38]); Fri, 05 May 2017 06:55:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > > >>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. What exactly did you have in mind? Put the framebuffer information (struct intel_vgpu_dmabuf) into the vfio region, then access it using read/write/mmap? > 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. Now with this patchset we have *two* kinds of separate file handles. First the anon-fd created by reading from the region. This is then used to run the intel ioctls on, which in turn create the other kind of file handle (dma-buf-fd). The dma-buf-fd really needs to be a separate fd, because it gets passed around as handle and because this is the way dma-bufs work (guess this is the discussion you are referring to). I can't see a compelling reason for the anon-fd though. I suspect this was done due to a misunderstanding ... cheers, Gerd