linux-kernel - RE: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

Open Source and information security mailing list archives

Message-ID: <237F54289DF84E4997F34151298ABEBC7C578164@SHSMSX101.ccr.corp.intel.com>
Date:   Tue, 4 Jul 2017 00:47:16 +0000
From:   "Zhang, Tina" <tina.zhang@...el.com>
To:     Daniel Vetter <daniel@...ll.ch>, Gerd Hoffmann <kraxel@...hat.com>
CC:     "Wang, Zhenyu Z" <zhenyu.z.wang@...el.com>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Chen, Xiaoguang" <xiaoguang.chen@...el.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        "Lv, Zhiyuan" <zhiyuan.lv@...el.com>,
        "Kirti Wankhede" <kwankhede@...dia.com>,
        "intel-gvt-dev@...ts.freedesktop.org" 
        <intel-gvt-dev@...ts.freedesktop.org>
Subject: RE: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
 operations

> -----Original Message-----
> From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@...ts.freedesktop.org] On
> Behalf Of Daniel Vetter
> Sent: Thursday, June 29, 2017 4:39 PM
> To: Gerd Hoffmann <kraxel@...hat.com>
> Cc: Wang, Zhenyu Z <zhenyu.z.wang@...el.com>; intel-
> gfx@...ts.freedesktop.org; linux-kernel@...r.kernel.org; Chen, Xiaoguang
> <xiaoguang.chen@...el.com>; Zhang, Tina <tina.zhang@...el.com>; Alex
> Williamson <alex.williamson@...hat.com>; Lv, Zhiyuan
> <zhiyuan.lv@...el.com>; Kirti Wankhede <kwankhede@...dia.com>; intel-gvt-
> dev@...ts.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@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives