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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180418160115.GA20588@downor-Z87X-UD5H>
Date:   Wed, 18 Apr 2018 09:01:15 -0700
From:   Dongwon Kim <dongwon.kim@...el.com>
To:     Oleksandr Andrushchenko <andr2000@...il.com>
Cc:     Roger Pau Monné <roger.pau@...rix.com>,
        Paul Durrant <Paul.Durrant@...rix.com>,
        "jgross@...e.com" <jgross@...e.com>,
        Artem Mygaiev <Artem_Mygaiev@...m.com>,
        "airlied@...ux.ie" <airlied@...ux.ie>,
        "Oleksandr_Andrushchenko@...m.com" <Oleksandr_Andrushchenko@...m.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "Potrola, MateuszX" <mateuszx.potrola@...el.com>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        "daniel.vetter@...el.com" <daniel.vetter@...el.com>,
        "boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
        Matt Roper <matthew.d.roper@...el.com>
Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper
 DRM driver

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@...ts.xenproject.org] On Behalf
> >>>>Of Roger Pau Monné
> >>>>Sent: 18 April 2018 11:11
> >>>>To: Oleksandr Andrushchenko <andr2000@...il.com>
> >>>>Cc: jgross@...e.com; Artem Mygaiev <Artem_Mygaiev@...m.com>;
> >>>>Dongwon Kim <dongwon.kim@...el.com>; airlied@...ux.ie;
> >>>>Oleksandr_Andrushchenko@...m.com; linux-kernel@...r.kernel.org; dri-
> >>>>devel@...ts.freedesktop.org; Potrola, MateuszX
> >>>><mateuszx.potrola@...el.com>; xen-devel@...ts.xenproject.org;
> >>>>daniel.vetter@...el.com; boris.ostrovsky@...cle.com; Matt Roper
> >>>><matthew.d.roper@...el.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?

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. 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.
>