From patchwork Tue Sep 26 07:12:03 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Gerd Hoffmann X-Patchwork-Id: 9971245 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 946B8602D8 for ; Tue, 26 Sep 2017 07:12:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7C7A828EA8 for ; Tue, 26 Sep 2017 07:12:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 70C3C28EB8; Tue, 26 Sep 2017 07:12:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id D382528EA8 for ; Tue, 26 Sep 2017 07:12:09 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 873A06E3E8; Tue, 26 Sep 2017 07:12:08 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by gabe.freedesktop.org (Postfix) with ESMTPS id 28C366E3E8; Tue, 26 Sep 2017 07:12:08 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 67F5C3296; Tue, 26 Sep 2017 07:12:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 67F5C3296 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=kraxel@redhat.com Received: from sirius.home.kraxel.org (ovpn-116-102.ams2.redhat.com [10.36.116.102]) by smtp.corp.redhat.com (Postfix) with ESMTP id B1D7077ED9; Tue, 26 Sep 2017 07:12:04 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by sirius.home.kraxel.org (Postfix) with ESMTP id C4F2B66; Tue, 26 Sep 2017 09:12:03 +0200 (CEST) Message-ID: <1506409923.32072.9.camel@redhat.com> From: Gerd Hoffmann To: Tina Zhang , zhenyuw@linux.intel.com Date: Tue, 26 Sep 2017 09:12:03 +0200 In-Reply-To: <1503051696-5158-6-git-send-email-tina.zhang@intel.com> References: <1503051696-5158-1-git-send-email-tina.zhang@intel.com> <1503051696-5158-6-git-send-email-tina.zhang@intel.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 26 Sep 2017 07:12:07 +0000 (UTC) Cc: Daniel Vetter , intel-gfx@lists.freedesktop.org, intel-gvt-dev@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH v14 5/7] vfio: ABI for mdev display dma-buf operation X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP Hi, [ bringing a private discussion back to the list ] > The dma-buf's life cycle is handled by user mode and tracked by > kernel. > The returned fd in struct vfio_device_query_gfx_plane can be a new > fd or an old fd of a re-exported dma-buf. Host user mode can check > the > value of fd and to see if it needs to create new resource according > to > the new fd or just use the existed resource related to the old fd. Ok, this idea has a fundamental flaw: The life cycle of the dma-buf and the file handle are not identical. The dma-buf can exist longer than the file handle in case other references to the dma-buf exist. So when trying to use the file handle as identifier for the dma-buf you'll end up with all sorts of strange effects. So, I'd suggest to use a id instead, and add a ioctl to get a dmabuf for a given id (incremental patch): [ no changes for a region-based display ] git branch, kernel, with updated dmabuf patch: https://www.kraxel.org/cgit/linux/log/?h=gvt-dmabuf-v14 qemu branch: https://www.kraxel.org/cgit/qemu/log/?h=work/intel-vgpu cheers, Gerd --- a/include/uapi/linux/vfio.h +++ b/include/uapi/linux/vfio.h @@ -538,12 +538,22 @@ struct vfio_device_gfx_plane_info {         __u32 y_pos;    /* vertical position of cursor plane, upper left corner in lines*/         union {                 __u32 region_index;     /* region index */ -               __s32 fd;       /* dma-buf fd */ +               __u32 dmabuf_id;        /* dma-buf id */         };  };    #define VFIO_DEVICE_QUERY_GFX_PLANE _IO(VFIO_TYPE, VFIO_BASE + 14)   +struct vfio_device_gfx_dmabuf_fd { +       __u32 argsz; +       __u32 flags; +       /* in */ +       __u32 dmabuf_id; +       /* out */ +       __s32 dmabuf_fd; +}; + +#define VFIO_DEVICE_GET_GFX_DMABUF _IO(VFIO_TYPE, VFIO_BASE + 15)    /* -------- API for Type1 VFIO IOMMU -------- */