Messages in this thread |  | | Subject | Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver | From | Oleksandr Andrushchenko <> | Date | Wed, 18 Apr 2018 15:42:29 +0300 |
| |
On 04/18/2018 01:55 PM, Roger Pau Monné wrote: > 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 <andr2000@gmail.com> >>>> Cc: jgross@suse.com; Artem Mygaiev <Artem_Mygaiev@epam.com>; >>>> Dongwon Kim <dongwon.kim@intel.com>; airlied@linux.ie; >>>> Oleksandr_Andrushchenko@epam.com; linux-kernel@vger.kernel.org; dri- >>>> devel@lists.freedesktop.org; Potrola, MateuszX >>>> <mateuszx.potrola@intel.com>; xen-devel@lists.xenproject.org; >>>> daniel.vetter@intel.com; boris.ostrovsky@oracle.com; Matt Roper >>>> <matthew.d.roper@intel.com> >>>> 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. There is a use-case I have: a display unit on my target has a DMA controller which can't do scatter-gather, e.g. it only expects a single starting address of the buffer. In order to create a dma-buf from grefs in this case I allocate memory with dma_alloc_xxx and then balloon pages of the buffer and finally map grefs onto this DMA buffer. This way I can give this shared buffer to the display unit as its bus addresses are contiguous.
With the proposed solution (gntdev + device-X) I won't be able to achieve this, as I have no control over from where gntdev/balloon drivers get the pages (even more, those can easily be out of DMA address space of the display unit).
Thus, even if implemented, I can't use this approach. > > In any case I just knew about dma-bufs this morning, there might be > things that I'm missing. > > Roger.
|  |