Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Oleksandr Andrushchenko]

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.