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: <237F54289DF84E4997F34151298ABEBC7C575706@SHSMSX101.ccr.corp.intel.com>
Date:   Wed, 28 Jun 2017 12:48:13 +0000
From:   "Zhang, Tina" <tina.zhang@...el.com>
To:     Gerd Hoffmann <kraxel@...hat.com>,
        Alex Williamson <alex.williamson@...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>,
        Kirti Wankhede <kwankhede@...dia.com>,
        "Lv, Zhiyuan" <zhiyuan.lv@...el.com>,
        "intel-gvt-dev@...ts.freedesktop.org" 
        <intel-gvt-dev@...ts.freedesktop.org>,
        "Wang, Zhi A" <zhi.a.wang@...el.com>
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 Gerd Hoffmann
> Sent: Tuesday, June 27, 2017 2:13 PM
> To: Alex Williamson <alex.williamson@...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>; Kirti
> Wankhede <kwankhede@...dia.com>; Lv, Zhiyuan <zhiyuan.lv@...el.com>;
> intel-gvt-dev@...ts.freedesktop.org; Wang, Zhi A <zhi.a.wang@...el.com>
> 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@...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