Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

2018-07-31 Thread Boris Ostrovsky
On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
>
> This work is in response to my previous attempt to introduce Xen/DRM
> zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
> frontends/backends. There is also an existing hyper_dmabuf approach
> available [3] which, if reworked to utilize the proposed solution,
> can greatly benefit as well.
>


Applied to for-linus-4.19.

-boris

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

2018-07-23 Thread Oleksandr Andrushchenko

On 07/23/2018 06:22 PM, Boris Ostrovsky wrote:

On 07/23/2018 09:26 AM, Oleksandr Andrushchenko wrote:

On 07/23/2018 11:38 AM, Oleksandr Andrushchenko wrote:

data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function
‘gntdev_ioctl_dmabuf_exp_from_refs’:
/data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:503:6: warning:
‘args.fd’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
    *fd = args.fd;
    ^
/data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:467:35: note:
‘args.fd’ was declared here
    struct gntdev_dmabuf_export_args args;
     ^~~~

Strangely, but my i386 build goes smooth.
Which version of gcc you use and could you please give me your
.config, so I can test the same?

Now I see this warning which seems to be a false positive.
Boris, could you please apply the following:

diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index e4c9f1f74476..0680dbcba616 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -495,6 +495,7 @@ static int dmabuf_exp_from_refs(struct gntdev_priv
*priv, int flags,
     args.dmabuf_priv = priv->dmabuf_priv;
     args.count = map->count;
     args.pages = map->pages;
+   args.fd = -1;

     ret = dmabuf_exp_from_pages();
     if (ret < 0)

or please let me know if you want me to resend with this fix?


Missed this message. Yes, this obviously fixes the problem. And it is
due to the code fragment that I mentioned in the earlier response.

Which patch is this for? I can add this when committing.
Thank you, this is for "[PATCH v5 7/8] xen/gntdev: Implement dma-buf 
export functionality"

-boris

Thank you,
Oleksandr

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

2018-07-23 Thread Boris Ostrovsky
On 07/23/2018 09:26 AM, Oleksandr Andrushchenko wrote:
> On 07/23/2018 11:38 AM, Oleksandr Andrushchenko wrote:
>>
>>> data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function
>>> ‘gntdev_ioctl_dmabuf_exp_from_refs’:
>>> /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:503:6: warning:
>>> ‘args.fd’ may be used uninitialized in this function
>>> [-Wmaybe-uninitialized]
>>>    *fd = args.fd;
>>>    ^
>>> /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:467:35: note:
>>> ‘args.fd’ was declared here
>>>    struct gntdev_dmabuf_export_args args;
>>>     ^~~~
>> Strangely, but my i386 build goes smooth.
>> Which version of gcc you use and could you please give me your
>> .config, so I can test the same?
> Now I see this warning which seems to be a false positive.
> Boris, could you please apply the following:
>
> diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
> index e4c9f1f74476..0680dbcba616 100644
> --- a/drivers/xen/gntdev-dmabuf.c
> +++ b/drivers/xen/gntdev-dmabuf.c
> @@ -495,6 +495,7 @@ static int dmabuf_exp_from_refs(struct gntdev_priv
> *priv, int flags,
>     args.dmabuf_priv = priv->dmabuf_priv;
>     args.count = map->count;
>     args.pages = map->pages;
> +   args.fd = -1;
>
>     ret = dmabuf_exp_from_pages();
>     if (ret < 0)
>
> or please let me know if you want me to resend with this fix?


Missed this message. Yes, this obviously fixes the problem. And it is
due to the code fragment that I mentioned in the earlier response.

Which patch is this for? I can add this when committing.

-boris

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

2018-07-23 Thread Oleksandr Andrushchenko

On 07/23/2018 11:38 AM, Oleksandr Andrushchenko wrote:

On 07/20/2018 05:08 PM, Boris Ostrovsky wrote:

On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends. There is also an existing hyper_dmabuf approach
available [3] which, if reworked to utilize the proposed solution,
can greatly benefit as well.


Lot of warnings on  i386 build:

In file included from
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.c:24:
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In
function ‘xen_drm_front_fb_to_cookie’:
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:129:9:
warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
   return (u64)fb;
  ^
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In
function ‘xen_drm_front_dbuf_to_cookie’:
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:134:9:
warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
   return (u64)gem_obj;
  ^
   CC [M]  net/netfilter/ipset/ip_set_hash_ipport.o
   CC  drivers/media/rc/keymaps/rc-tango.o
   CC [M]  drivers/gpu/drm/vmwgfx/vmwgfx_fifo.o
   AR  drivers/misc/built-in.a
In file included from
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front_kms.c:20:
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In
function ‘xen_drm_front_fb_to_cookie’:
   CC [M]  drivers/gpu/drm/xen/xen_drm_front_conn.o
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:129:9:
warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
   return (u64)fb;
(and more)


The above warnings already have a fix [1] which is expected in 4.19


and then

data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function
‘gntdev_ioctl_dmabuf_exp_from_refs’:
/data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:503:6: warning:
‘args.fd’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]

   *fd = args.fd;
   ^
/data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:467:35: note:
‘args.fd’ was declared here
   struct gntdev_dmabuf_export_args args;
    ^~~~

Strangely, but my i386 build goes smooth.
Which version of gcc you use and could you please give me your
.config, so I can test the same?

Now I see this warning which seems to be a false positive.
Boris, could you please apply the following:

diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index e4c9f1f74476..0680dbcba616 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -495,6 +495,7 @@ static int dmabuf_exp_from_refs(struct gntdev_priv 
*priv, int flags,

    args.dmabuf_priv = priv->dmabuf_priv;
    args.count = map->count;
    args.pages = map->pages;
+   args.fd = -1;

    ret = dmabuf_exp_from_pages();
    if (ret < 0)

or please let me know if you want me to resend with this fix?


-boris

Thank you,
Oleksandr

[1] 
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=9eece5d9c6e0316f17091e37ff3ec87331bdedf3


Thank you,
Oleksandr

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

2018-07-23 Thread Oleksandr Andrushchenko

On 07/20/2018 05:08 PM, Boris Ostrovsky wrote:

On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends. There is also an existing hyper_dmabuf approach
available [3] which, if reworked to utilize the proposed solution,
can greatly benefit as well.


Lot of warnings on  i386 build:

In file included from
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.c:24:
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In
function ‘xen_drm_front_fb_to_cookie’:
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:129:9:
warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
   return (u64)fb;
  ^
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In
function ‘xen_drm_front_dbuf_to_cookie’:
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:134:9:
warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
   return (u64)gem_obj;
  ^
   CC [M]  net/netfilter/ipset/ip_set_hash_ipport.o
   CC  drivers/media/rc/keymaps/rc-tango.o
   CC [M]  drivers/gpu/drm/vmwgfx/vmwgfx_fifo.o
   AR  drivers/misc/built-in.a
In file included from
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front_kms.c:20:
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In
function ‘xen_drm_front_fb_to_cookie’:
   CC [M]  drivers/gpu/drm/xen/xen_drm_front_conn.o
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:129:9:
warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
   return (u64)fb;
(and more)


The above warnings already have a fix [1] which is expected in 4.19


and then

data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function
‘gntdev_ioctl_dmabuf_exp_from_refs’:
/data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:503:6: warning:
‘args.fd’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   *fd = args.fd;
   ^
/data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:467:35: note:
‘args.fd’ was declared here
   struct gntdev_dmabuf_export_args args;
    ^~~~

Strangely, but my i386 build goes smooth.
Which version of gcc you use and could you please give me your
.config, so I can test the same?


-boris

Thank you,
Oleksandr

[1] 
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=9eece5d9c6e0316f17091e37ff3ec87331bdedf3


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

2018-07-20 Thread Boris Ostrovsky
On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
>
> This work is in response to my previous attempt to introduce Xen/DRM
> zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
> frontends/backends. There is also an existing hyper_dmabuf approach
> available [3] which, if reworked to utilize the proposed solution,
> can greatly benefit as well.


Lot of warnings on  i386 build:

In file included from
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.c:24:
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In
function ‘xen_drm_front_fb_to_cookie’:
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:129:9:
warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
  return (u64)fb;
 ^
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In
function ‘xen_drm_front_dbuf_to_cookie’:
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:134:9:
warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
  return (u64)gem_obj;
 ^
  CC [M]  net/netfilter/ipset/ip_set_hash_ipport.o
  CC  drivers/media/rc/keymaps/rc-tango.o
  CC [M]  drivers/gpu/drm/vmwgfx/vmwgfx_fifo.o
  AR  drivers/misc/built-in.a
In file included from
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front_kms.c:20:
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In
function ‘xen_drm_front_fb_to_cookie’:
  CC [M]  drivers/gpu/drm/xen/xen_drm_front_conn.o
/data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:129:9:
warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
  return (u64)fb;
(and more)



and then

data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function
‘gntdev_ioctl_dmabuf_exp_from_refs’:
/data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:503:6: warning:
‘args.fd’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  *fd = args.fd;
  ^
/data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:467:35: note:
‘args.fd’ was declared here
  struct gntdev_dmabuf_export_args args;
   ^~~~


-boris

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

2018-07-20 Thread Oleksandr Andrushchenko
From: Oleksandr Andrushchenko 

This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends. There is also an existing hyper_dmabuf approach
available [3] which, if reworked to utilize the proposed solution,
can greatly benefit as well.

RFC for this series was published and discussed [9], comments addressed.

The original rationale behind this work was to enable zero-copying
use-cases while working with Xen para-virtual display driver [4]:
when using Xen PV DRM frontend driver then on backend side one will
need to do copying of display buffers' contents (filled by the
frontend's user-space) into buffers allocated at the backend side.
Taking into account the size of display buffers and frames per
second it may result in unneeded huge data bus occupation and
performance loss.

The helper driver [4] allows implementing zero-copying use-cases
when using Xen para-virtualized frontend display driver by implementing
a DRM/KMS helper driver running on backend's side.
It utilizes PRIME buffers API (implemented on top of Linux dma-buf)
to share frontend's buffers with physical device drivers on
backend's side:

 - a dumb buffer created on backend's side can be shared
   with the Xen PV frontend driver, so it directly writes
   into backend's domain memory (into the buffer exported from
   DRM/KMS driver of a physical display device)
 - a dumb buffer allocated by the frontend can be imported
   into physical device DRM/KMS driver, thus allowing to
   achieve no copying as well

Finally, it was discussed and decided ([1], [5]) that it is worth
implementing such use-cases via extension of the existing Xen gntdev
driver instead of introducing new DRM specific driver.
Please note, that the support of dma-buf is Linux only,
as dma-buf is a Linux only thing.

Now to the proposed solution. The changes  to the existing Xen drivers
in the Linux kernel fall into 2 categories:
1. DMA-able memory buffer allocation and increasing/decreasing memory
   reservation of the pages of such a buffer.
   This is required if we are about to share dma-buf with the hardware
   that does require those to be allocated with dma_alloc_xxx API.
   (It is still possible to allocate a dma-buf from any system memory,
   e.g. system pages).
2. Extension of the gntdev driver to enable it to import/export dma-buf’s.

The first five patches are in preparation for Xen dma-buf support,
but I consider those usable regardless of the dma-buf use-case,
e.g. other frontend/backend kernel modules may also benefit from these
for better code reuse:
0001-xen-grant-table-Make-set-clear-page-private-code-sha.patch
0002-xen-balloon-Share-common-memory-reservation-routines.patch
0003-xen-grant-table-Allow-allocating-buffers-suitable-fo.patch
0004-xen-gntdev-Allow-mappings-for-DMA-buffers.patch
0005-xen-gntdev-Make-private-routines-structures-accessib.patch

The next three patches are Xen implementation of dma-buf as part of
the grant device:
0006-xen-gntdev-Add-initial-support-for-dma-buf-UAPI.patch
0007-xen-gntdev-Implement-dma-buf-export-functionality.patch
0008-xen-gntdev-Implement-dma-buf-import-functionality.patch

The corresponding libxengnttab changes are available at [6].

All the above was tested with display backend [7] and its accompanying
helper library [8] on Renesas ARM64 based board.
Basic balloon tests on x86.

*To all the communities*: I would like to ask you to review the proposed
solution and give feedback on it, so I can improve and send final
patches for review (this is still work in progress, but enough to start
discussing the implementation).

Thank you in advance,
Oleksandr Andrushchenko

[1] https://lists.freedesktop.org/archives/dri-devel/2018-April/173163.html
[2] 
https://elixir.bootlin.com/linux/v4.17-rc5/source/Documentation/driver-api/dma-buf.rst
[3] https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01202.html
[4] https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/xen
[5] https://patchwork.kernel.org/patch/10279681/
[6] https://github.com/andr2000/xen/tree/xen_dma_buf_v1
[7] https://github.com/andr2000/displ_be/tree/xen_dma_buf_v1
[8] https://github.com/andr2000/libxenbe/tree/xen_dma_buf_v1
[9] https://lkml.org/lkml/2018/5/17/215

Changes since v4:
*
- added r-b tags
- rebased onto v4.18-rc5

Changes since v3:
*
- added r-b tags
- minor fixes
- removed gntdev_remove_map as it can be coded directly now
- moved IOCTL code to gntdev-dmabuf.c
- removed usless wait list walks and changed some walks to use
  normal version of list iterators instead of safe ones as
  we run under a lock anyways
- cleaned up comments, descriptions, pr_debug messages

Changes since v2:
*
- fixed missed break in dmabuf_exp_wait_obj_signal
- re-worked debug and error messages, be less verbose
- removed patch for making gntdev functions available to other drivers
-