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-boun...@lists.xenproject.org] On Behalf
Of Roger Pau Monné
Sent: 18 April 2018 11:11
To: Oleksandr Andrushchenko <andr2...@gmail.com>
Cc: jgr...@suse.com; Artem Mygaiev <artem_myga...@epam.com>;
Dongwon Kim <dongwon....@intel.com>; airl...@linux.ie;
oleksandr_andrushche...@epam.com; linux-ker...@vger.kernel.org; dri-
de...@lists.freedesktop.org; Potrola, MateuszX
<mateuszx.potr...@intel.com>; xen-devel@lists.xenproject.org;
daniel.vet...@intel.com; boris.ostrov...@oracle.com; Matt Roper
<matthew.d.ro...@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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
