Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751556AbdF1Ms1 (ORCPT ); Wed, 28 Jun 2017 08:48:27 -0400 Received: from mga01.intel.com ([192.55.52.88]:45968 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751501AbdF1MsV (ORCPT ); Wed, 28 Jun 2017 08:48:21 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,275,1496127600"; d="scan'208";a="986168626" From: "Zhang, Tina" To: Gerd Hoffmann , Alex Williamson CC: "Wang, Zhenyu Z" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "Chen, Xiaoguang" , Kirti Wankhede , "Lv, Zhiyuan" , "intel-gvt-dev@lists.freedesktop.org" , "Wang, Zhi A" Subject: RE: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations Thread-Topic: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations Thread-Index: AQHS6bQOm048yqQnv0S7uYOCurj/4KIzAH9QgAMz2oCAALWEgIAA1VoAgAJ/vbA= Date: Wed, 28 Jun 2017 12:48:13 +0000 Message-ID: <237F54289DF84E4997F34151298ABEBC7C575706@SHSMSX101.ccr.corp.intel.com> References: <1497513611-2814-1-git-send-email-xiaoguang.chen@intel.com> <1497513611-2814-6-git-send-email-xiaoguang.chen@intel.com> <1497542438.29252.1.camel@redhat.com> <20170615143833.7526351b@w520.home> <24c4880b-24f5-ea07-834c-c77d3e895c78@nvidia.com> <1497854312.4207.4.camel@redhat.com> <20170619085530.1f5e46dc@w520.home> <237F54289DF84E4997F34151298ABEBC7C56EBE0@SHSMSX101.ccr.corp.intel.com> <1497956256.16795.7.camel@redhat.com> <237F54289DF84E4997F34151298ABEBC7C5731B3@SHSMSX101.ccr.corp.intel.com> <1498459157.20591.6.camel@redhat.com> <20170626112857.37c2aa65@w520.home> <1498543954.15306.2.camel@redhat.com> In-Reply-To: <1498543954.15306.2.camel@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v5SCmUeZ014238 Content-Length: 2664 Lines: 59 > -----Original Message----- > From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@lists.freedesktop.org] On > Behalf Of Gerd Hoffmann > Sent: Tuesday, June 27, 2017 2:13 PM > To: Alex Williamson > Cc: Wang, Zhenyu Z ; intel- > gfx@lists.freedesktop.org; linux-kernel@vger.kernel.org; Chen, Xiaoguang > ; Zhang, Tina ; Kirti > Wankhede ; Lv, Zhiyuan ; > intel-gvt-dev@lists.freedesktop.org; Wang, Zhi A > Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf > operations > > Hi, > > > Hmm, I don't like that interface.  Can you cite examples of other > > ioctls that behave this way?  It doesn't feel like an elegant user > > interface; the user can get the dmabuf, but only after they query the > > dmabuf, even though the get-dmabuf ioctl returns the same data as the > > query-plane ioctl, but they can't get the dmabuf if the plane has > > changed in the interim, which is not something the user can know.  Are > > we causing our own problems with this model of cycling through dmabuf > > fds?  We talked previously about an enum of plane types, primary and > > cursor.  What if the user was simply able to get a dmabuf fd for each > > of those and they queried the current plane information via those fds? > > IOW, the fd is persistent and specific to a given plane type, but the > > format within it is dynamic. > > Will not work due to how dma-bufs are designed. > > But, yes, the QUERY then GET split is ugly for a number of reasons. > > Does gvt track the live cycle of all dma-bufs it has handed out? The V9 implementation does track the dma-bufs' live cycle. The original idea was that leaving the dma-bufs' live cycle management to user mode. > If so, then maybe we can let the kernel check whenever a dma-buf for the > current plane exists? And if that isn't the case hand out a dma- buf right away, > without expecting userspace explicitly asking for it? I think this is a good advice. We are going to try this idea and add some tracking logic to kernel mode. > > That will simplify the interface and remove the race condition at the expense of > some additional bookkeeping in the kernel. In this case, maybe one ioctl like QUERY_PLAN is enough. We can block it this ioctl and return it when the fd and info are ready. Thanks. Tina > > cheers, > Gerd > > _______________________________________________ > intel-gvt-dev mailing list > intel-gvt-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev