On 04/18/2018 07:01 PM, Dongwon Kim wrote:
On Wed, Apr 18, 2018 at 03:42:29PM +0300, Oleksandr Andrushchenko wrote:
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@xxxxxxxxxxxxxxxxxxxx] On Behalf
Of Roger Pau Monné
Sent: 18 April 2018 11:11
To: Oleksandr Andrushchenko <andr2000@xxxxxxxxx>
Cc: jgross@xxxxxxxx; Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>;
Dongwon Kim <dongwon.kim@xxxxxxxxx>; airlied@xxxxxxxx;
Oleksandr_Andrushchenko@xxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; dri-
devel@xxxxxxxxxxxxxxxxxxxxx; Potrola, MateuszX
<mateuszx.potrola@xxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx;
daniel.vetter@xxxxxxxxx; boris.ostrovsky@xxxxxxxxxx; Matt Roper
<matthew.d.roper@xxxxxxxxx>
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?
FYI,
our use-case is "surface sharing" or "graphic obj sharing" where a client
application in one guest renders and export this render target(e.g. EGL surface)
as dma-buf. This dma-buf is then exported to another guest/host via hyper_dmabuf
drv where a compositor is running. This importing domain creates a dmabuf with
shared reference then it is imported as EGL image that later can be used as
texture object via EGL api.
Mapping dmabuf to the userspace or vice versa
might be possible with modifying user space drivers/applications but it is an
unnecessary extra step from our perspective.
+1. I also feel like if it is implemented in the kernel space it
will be *much* more easier then inventing workarounds with
gntdev, user-space and helper dma-buf driver (which obviously can be
implemented). Of course, this approach is easier for Xen as we do not
touch its kernel code ;)
But there is a demand for changes as number of embedded/multimedia use-cases
is constantly growing and we have to react.
Also, we want to keep all objects
in the kernel level.
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.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
