Received: by 10.192.165.156 with SMTP id m28csp1084143imm; Wed, 18 Apr 2018 03:56:55 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/llZFz/07PUndO5TCA1PrVWRztDWu88//j9Ny3Cg3OMNsQ0xsEkftcwIfhEDYaT9yq/oSa X-Received: by 2002:a17:902:3181:: with SMTP id x1-v6mr1648054plb.198.1524049015489; Wed, 18 Apr 2018 03:56:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524049015; cv=none; d=google.com; s=arc-20160816; b=pp4vgqDrXoezsgE8eu/7eXNJCNg3qGzImFc6M75GiZ1lwceS/LdK1Fc99E8Dblh/yR 2ZeqCiid1WBsfCQn5IIldrTk6oQ4SIL6WK8MyLGogbxeksJ9BSobNFbqoQqUJVTSCg8J voATdjISuMVZNyEUcNfe6afxTRNMBC0Q2ieftd1k9L7ReQsCYWN7eQPl0qrrxWDVRneZ 54t159cuKQWO4boNNBnTn3SFt1JetZmq2qjs8uxLJE9vCvuQytEFbySt/fNddHVatY00 mEXrS0ebY6YmWswMH5NFxkWNU5HtO0WSkfKZQEMHrK9jmFU2aq75bJonwRNhyDiLZsc2 wa0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=7F4Oo0rS9gjecT9RfknjaVWFEGsPv5Db73PYJbP6a5A=; b=QM/QmHFo95DBH1VEZ8anNBWlSXR6VY51LrHg6CTaEsYWKVWjp4do6pBXEOy8d4gHj6 D97Ox5X/rFNBHY5LBxx3KRUOqZDDCgiu9CROTgu/otjT/HDTjU6hl2CEiKyIWZOG3wht nejs0KkluP/ljTC79xGL8HHhS8LVUJ4BtTX76Um6aFNkHkn5Fob3aFeIGq7SUr45oWyA +07tvf+FtQEcPtHvZG32NPj0ix8/Q3nLcHLuO2sPWxEr5qjPLebH9Il541PivRTjkKoL duXwlhoqRPVUVt4A3LRwqC72/Q/c0LUNXmpdgRYruiFFhmKQbQOYWFndldsGpn8vNZJA bnEw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k2si883208pgr.200.2018.04.18.03.56.41; Wed, 18 Apr 2018 03:56:55 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752992AbeDRKze (ORCPT + 99 others); Wed, 18 Apr 2018 06:55:34 -0400 Received: from smtp.eu.citrix.com ([185.25.65.24]:28934 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751879AbeDRKzd (ORCPT ); Wed, 18 Apr 2018 06:55:33 -0400 X-IronPort-AV: E=Sophos;i="5.48,464,1517875200"; d="scan'208";a="71739631" Date: Wed, 18 Apr 2018 11:55:26 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Oleksandr Andrushchenko CC: Paul Durrant , "jgross@suse.com" , Artem Mygaiev , Dongwon Kim , "airlied@linux.ie" , "Oleksandr_Andrushchenko@epam.com" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "Potrola, MateuszX" , "xen-devel@lists.xenproject.org" , "daniel.vetter@intel.com" , "boris.ostrovsky@oracle.com" , Matt Roper Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver Message-ID: <20180418105526.a4qtlhofrn3gubsl@MacBook-Pro-de-Roger.local> References: <5d8fec7f-956c-378f-be90-f45029385740@gmail.com> <20180416192905.GA18096@downor-Z87X-UD5H> <20180417075928.GT31310@phenom.ffwll.local> <20180417205744.GA15930@downor-Z87X-UD5H> <41487acb-a67a-8933-d0c3-702c19b0938e@gmail.com> <20180418073508.ptvntwedczpvl7bx@MacBook-Pro-de-Roger.local> <20180418101058.hyqk3gr3b2ibxswu@MacBook-Pro-de-Roger.local> <7d6710a76b9a42299139d7914358ed52@AMSPEX02CL03.citrite.net> <46489b33-e6fc-b874-6cd4-dbb94c002ef8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <46489b33-e6fc-b874-6cd4-dbb94c002ef8@gmail.com> User-Agent: NeoMutt/20180323 X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote: > On 04/18/2018 01:18 PM, Paul Durrant wrote: > > > -----Original Message----- > > > From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf > > > Of Roger Pau Monn? > > > Sent: 18 April 2018 11:11 > > > To: Oleksandr Andrushchenko > > > Cc: jgross@suse.com; Artem Mygaiev ; > > > Dongwon Kim ; airlied@linux.ie; > > > Oleksandr_Andrushchenko@epam.com; linux-kernel@vger.kernel.org; dri- > > > devel@lists.freedesktop.org; Potrola, MateuszX > > > ; xen-devel@lists.xenproject.org; > > > daniel.vetter@intel.com; boris.ostrovsky@oracle.com; Matt Roper > > > > > > Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy > > > helper DRM driver > > > > > > On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko > > > wrote: > > > > On 04/18/2018 10:35 AM, Roger Pau Monn? wrote: > > > After speaking with Oleksandr on IRC, I think the main usage of the > > > gntdev extension is to: > > > > > > 1. Create a dma-buf from a set of grant references. > > > 2. Share dma-buf and get a list of grant references. > > > > > > I think this set of operations could be broken into: > > > > > > 1.1 Map grant references into user-space using the gntdev. > > > 1.2 Create a dma-buf out of a set of user-space virtual addresses. > > > > > > 2.1 Map a dma-buf into user-space. > > > 2.2 Get grefs out of the user-space addresses where the dma-buf is > > > mapped. > > > > > > So it seems like what's actually missing is a way to: > > > > > > - Create a dma-buf from a list of user-space virtual addresses. > > > - Allow to map a dma-buf into user-space, so it can then be used with > > > the gntdev. > > > > > > I think this is generic enough that it could be implemented by a > > > device not tied to Xen. AFAICT the hyper_dma guys also wanted > > > something similar to this. > Ok, so just to summarize, xen-zcopy/hyper-dmabuf as they are now, > are no go from your POV? My opinion is that there seems to be a more generic way to implement this, and thus I would prefer that one. > Instead, we have to make all that fancy stuff > with VAs <-> device-X and have that device-X driver live out of drivers/xen > as it is not a Xen specific driver? That would be my preference if feasible, simply because it can be reused by other use-cases that need to create dma-bufs in user-space. In any case I just knew about dma-bufs this morning, there might be things that I'm missing. Roger.