Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751979AbdGDArX (ORCPT ); Mon, 3 Jul 2017 20:47:23 -0400 Received: from mga01.intel.com ([192.55.52.88]:6976 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750849AbdGDArW (ORCPT ); Mon, 3 Jul 2017 20:47:22 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,305,1496127600"; d="scan'208";a="104139541" From: "Zhang, Tina" To: Daniel Vetter , Gerd Hoffmann CC: "Wang, Zhenyu Z" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "Chen, Xiaoguang" , Alex Williamson , "Lv, Zhiyuan" , "Kirti Wankhede" , "intel-gvt-dev@lists.freedesktop.org" 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/vbCAAK0dgIAAIMoAgAfcDPA= Date: Tue, 4 Jul 2017 00:47:16 +0000 Message-ID: <237F54289DF84E4997F34151298ABEBC7C578164@SHSMSX101.ccr.corp.intel.com> References: <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> <237F54289DF84E4997F34151298ABEBC7C575706@SHSMSX101.ccr.corp.intel.com> <1498718513.31562.3.camel@redhat.com> <20170629083914.qr2gpzy3tyomrfym@phenom.ffwll.local> In-Reply-To: <20170629083914.qr2gpzy3tyomrfym@phenom.ffwll.local> 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 v640lTDo018537 Content-Length: 2340 Lines: 52 > -----Original Message----- > From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@lists.freedesktop.org] On > Behalf Of Daniel Vetter > Sent: Thursday, June 29, 2017 4:39 PM > To: Gerd Hoffmann > Cc: Wang, Zhenyu Z ; intel- > gfx@lists.freedesktop.org; linux-kernel@vger.kernel.org; Chen, Xiaoguang > ; Zhang, Tina ; Alex > Williamson ; Lv, Zhiyuan > ; Kirti Wankhede ; intel-gvt- > dev@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf > operations > > On Thu, Jun 29, 2017 at 08:41:53AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > > 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. > > > > That is still the case, user space decides which dma-bufs it'll go > > keep cached. But kernel space can see what user space is doing, so > > there is no need to explicitly tell the kernel whenever a cached > > dma-buf exists or not. > > We do the same trick in drm_prime.c, keeping a cache of exported dma-buf > around for re-exporting. Since for prime sharing the use-case is almost always > re-importing as a drm gem buffer again we can then on re-import also tell > userspace whether it already has that buffer in it's userspace buffer manager, > but that's an additional optimization. With plain dma-buf we could achieve the > same by wiring up a real stat() implementation with unique inode numbers (atm > they all share the anon_inode singleton). But thus far no one asked for that. Thanks. I'm going to submit the v10 version of ABI interface. > > btw I'm lost a bit in the discussion (was on vacation), but I think all the concerns > I've noticed with the initial rfc have been raised already, so things look good. I'll > check the next rfc once that shows up. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ > intel-gvt-dev mailing list > intel-gvt-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev