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

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

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

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 four 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-Move-common-memory-reservation-routines-.patch
   0003-xen-grant-table-Allow-allocating-buffers-suitable-fo.patch
   0004-xen-gntdev-Allow-mappings-for-DMA-buffers.patch

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

The last patch makes it possible for in-kernel use of Xen dma-buf API:
  0008-xen-gntdev-Expose-gntdev-s-dma-buf-API-for-in-kernel.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.

*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

Oleksandr Andrushchenko (8):
  xen/grant-table: Make set/clear page private code shared
  xen/balloon: Move common memory reservation routines to a module
  xen/grant-table: Allow allocating buffers suitable for DMA
  xen/gntdev: Allow mappings for DMA buffers
  xen/gntdev: Add initial support for dma-buf UAPI
  xen/gntdev: Implement dma-buf export functionality
  xen/gntdev: Implement dma-buf import functionality
  xen/gntdev: Expose gntdev's dma-buf API for in-kernel use

 drivers/xen/Kconfig           |   23 +
 drivers/xen/Makefile          |    1 +
 drivers/xen/balloon.c         |   71 +--
 drivers/xen/gntdev.c          | 1025 ++++++++++++++++++++++++++++++++-
 drivers/xen/grant-table.c     |  176 +++++-
 drivers/xen/mem-reservation.c |  134 +++++
 include/uapi/xen/gntdev.h     |  106 ++++
 include/xen/grant_dev.h       |   37 ++
 include/xen/grant_table.h     |   28 +
 include/xen/mem_reservation.h |   29 +
 10 files changed, 1527 insertions(+), 103 deletions(-)
 create mode 100644 drivers/xen/mem-reservation.c
 create mode 100644 include/xen/grant_dev.h
 create mode 100644 include/xen/mem_reservation.h

-- 
2.17.0


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

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

[Oleksandr Andrushchenko]

On 05/31/2018 11:25 PM, Boris Ostrovsky wrote:
> On 05/31/2018 10:41 AM, Oleksandr Andrushchenko wrote:
>> On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote:
>>> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>>>>
>>>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>>>>
>>>>> Oleksandr Andrushchenko (8):
>>>>>     xen/grant-table: Make set/clear page private code shared
>>>>>     xen/balloon: Move common memory reservation routines to a module
>>>>>     xen/grant-table: Allow allocating buffers suitable for DMA
>>>>>     xen/gntdev: Allow mappings for DMA buffers
>>>>>     xen/gntdev: Add initial support for dma-buf UAPI
>>>>>     xen/gntdev: Implement dma-buf export functionality
>>>>>     xen/gntdev: Implement dma-buf import functionality
>>>>>     xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
>>>>>
>>>>>    drivers/xen/Kconfig           |   23 +
>>>>>    drivers/xen/Makefile          |    1 +
>>>>>    drivers/xen/balloon.c         |   71 +--
>>>>>    drivers/xen/gntdev.c          | 1025
>>>>> ++++++++++++++++++++++++++++++++-
>>>>
>>>> I think this calls for gntdev_dma.c.
>>> I assume you mean as a separate file (part of gntdev driver)?
>>>> I only had a quick look over gntdev changes but they very much are
>>>> concentrated in dma-specific routines.
>>>>
>>> I tried to do that, but there are some dependencies between the
>>> gntdev.c and gntdev_dma.c,
>>> so finally I decided to put it all together.
>>>> You essentially only share file_operations entry points with
>>>> original gntdev code, right?
>>>>
>>> fops + mappings done by gntdev (struct grant_map) and I need to
>>> release map on dma_buf .release
>>> callback which makes some cross-dependencies between modules which
>>> seemed to be not cute
>>> (gntdev keeps its all structs and functions inside, so I cannot
>>> easily access those w/o
>>> helpers).
>>>
>>> But I'll try one more time and move all DMA specific stuff into
>>> gntdev_dma.c
>> Could you please take a quick look at the way I re-structured the
>> sources here [1]?
>> If this is what you meant.
>
> I looked at final gntdev.c code and I think at least one of the chunks
> there ("DMA buffer export support. ") can also be moved out. It still
> have a bit too many ifdefs but it looks better to my eye than jamming
> everything into a single file (and I think more code can be moved out,
> but we can talk about it when you post the patches so that we can see
> context).
Sure, will send v2 after I re-check all the patches
and run some smoke tests again
>
> BTW, I believe it won't build with !CONFIG_XEN_GNTDEV_DMABUF ---
> gntdev_remove_map() is defined under this option and is referenced later
> without it.
Will check, thank you
>
> -boris
>
>
>> Thank you,
>> Oleksandr
>>>> -boris
>>>>
>>> Thank you,
>>> Oleksandr
>>>>>    drivers/xen/grant-table.c     |  176 +++++-
>>>>>    drivers/xen/mem-reservation.c |  134 +++++
>>>>>    include/uapi/xen/gntdev.h     |  106 ++++
>>>>>    include/xen/grant_dev.h       |   37 ++
>>>>>    include/xen/grant_table.h     |   28 +
>>>>>    include/xen/mem_reservation.h |   29 +
>>>>>    10 files changed, 1527 insertions(+), 103 deletions(-)
>>>>>    create mode 100644 drivers/xen/mem-reservation.c
>>>>>    create mode 100644 include/xen/grant_dev.h
>>>>>    create mode 100644 include/xen/mem_reservation.h
>>>>>
>> [1]
>> https://github.com/andr2000/linux/commits/xen_tip_linux_next_xen_dma_buf_v2

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

[Oleksandr Andrushchenko]

On 05/31/2018 11:25 PM, Boris Ostrovsky wrote:
> On 05/31/2018 10:41 AM, Oleksandr Andrushchenko wrote:
>> On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote:
>>> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>>>>
>>>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>>>>
>>>>> Oleksandr Andrushchenko (8):
>>>>>     xen/grant-table: Make set/clear page private code shared
>>>>>     xen/balloon: Move common memory reservation routines to a module
>>>>>     xen/grant-table: Allow allocating buffers suitable for DMA
>>>>>     xen/gntdev: Allow mappings for DMA buffers
>>>>>     xen/gntdev: Add initial support for dma-buf UAPI
>>>>>     xen/gntdev: Implement dma-buf export functionality
>>>>>     xen/gntdev: Implement dma-buf import functionality
>>>>>     xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
>>>>>
>>>>>    drivers/xen/Kconfig           |   23 +
>>>>>    drivers/xen/Makefile          |    1 +
>>>>>    drivers/xen/balloon.c         |   71 +--
>>>>>    drivers/xen/gntdev.c          | 1025
>>>>> ++++++++++++++++++++++++++++++++-
>>>>
>>>> I think this calls for gntdev_dma.c.
>>> I assume you mean as a separate file (part of gntdev driver)?
>>>> I only had a quick look over gntdev changes but they very much are
>>>> concentrated in dma-specific routines.
>>>>
>>> I tried to do that, but there are some dependencies between the
>>> gntdev.c and gntdev_dma.c,
>>> so finally I decided to put it all together.
>>>> You essentially only share file_operations entry points with
>>>> original gntdev code, right?
>>>>
>>> fops + mappings done by gntdev (struct grant_map) and I need to
>>> release map on dma_buf .release
>>> callback which makes some cross-dependencies between modules which
>>> seemed to be not cute
>>> (gntdev keeps its all structs and functions inside, so I cannot
>>> easily access those w/o
>>> helpers).
>>>
>>> But I'll try one more time and move all DMA specific stuff into
>>> gntdev_dma.c
>> Could you please take a quick look at the way I re-structured the
>> sources here [1]?
>> If this is what you meant.
>
> I looked at final gntdev.c code and I think at least one of the chunks
> there ("DMA buffer export support. ") can also be moved out. It still
> have a bit too many ifdefs but it looks better to my eye than jamming
> everything into a single file (and I think more code can be moved out,
> but we can talk about it when you post the patches so that we can see
> context).
Sure, will send v2 after I re-check all the patches
and run some smoke tests again
>
> BTW, I believe it won't build with !CONFIG_XEN_GNTDEV_DMABUF ---
> gntdev_remove_map() is defined under this option and is referenced later
> without it.
Will check, thank you
>
> -boris
>
>
>> Thank you,
>> Oleksandr
>>>> -boris
>>>>
>>> Thank you,
>>> Oleksandr
>>>>>    drivers/xen/grant-table.c     |  176 +++++-
>>>>>    drivers/xen/mem-reservation.c |  134 +++++
>>>>>    include/uapi/xen/gntdev.h     |  106 ++++
>>>>>    include/xen/grant_dev.h       |   37 ++
>>>>>    include/xen/grant_table.h     |   28 +
>>>>>    include/xen/mem_reservation.h |   29 +
>>>>>    10 files changed, 1527 insertions(+), 103 deletions(-)
>>>>>    create mode 100644 drivers/xen/mem-reservation.c
>>>>>    create mode 100644 include/xen/grant_dev.h
>>>>>    create mode 100644 include/xen/mem_reservation.h
>>>>>
>> [1]
>> https://github.com/andr2000/linux/commits/xen_tip_linux_next_xen_dma_buf_v2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Oleksandr Andrushchenko]

On 05/31/2018 11:25 PM, Boris Ostrovsky wrote:
> On 05/31/2018 10:41 AM, Oleksandr Andrushchenko wrote:
>> On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote:
>>> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>>>>
>>>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>>>>
>>>>> Oleksandr Andrushchenko (8):
>>>>>     xen/grant-table: Make set/clear page private code shared
>>>>>     xen/balloon: Move common memory reservation routines to a module
>>>>>     xen/grant-table: Allow allocating buffers suitable for DMA
>>>>>     xen/gntdev: Allow mappings for DMA buffers
>>>>>     xen/gntdev: Add initial support for dma-buf UAPI
>>>>>     xen/gntdev: Implement dma-buf export functionality
>>>>>     xen/gntdev: Implement dma-buf import functionality
>>>>>     xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
>>>>>
>>>>>    drivers/xen/Kconfig           |   23 +
>>>>>    drivers/xen/Makefile          |    1 +
>>>>>    drivers/xen/balloon.c         |   71 +--
>>>>>    drivers/xen/gntdev.c          | 1025
>>>>> ++++++++++++++++++++++++++++++++-
>>>>
>>>> I think this calls for gntdev_dma.c.
>>> I assume you mean as a separate file (part of gntdev driver)?
>>>> I only had a quick look over gntdev changes but they very much are
>>>> concentrated in dma-specific routines.
>>>>
>>> I tried to do that, but there are some dependencies between the
>>> gntdev.c and gntdev_dma.c,
>>> so finally I decided to put it all together.
>>>> You essentially only share file_operations entry points with
>>>> original gntdev code, right?
>>>>
>>> fops + mappings done by gntdev (struct grant_map) and I need to
>>> release map on dma_buf .release
>>> callback which makes some cross-dependencies between modules which
>>> seemed to be not cute
>>> (gntdev keeps its all structs and functions inside, so I cannot
>>> easily access those w/o
>>> helpers).
>>>
>>> But I'll try one more time and move all DMA specific stuff into
>>> gntdev_dma.c
>> Could you please take a quick look at the way I re-structured the
>> sources here [1]?
>> If this is what you meant.
>
> I looked at final gntdev.c code and I think at least one of the chunks
> there ("DMA buffer export support. ") can also be moved out. It still
> have a bit too many ifdefs but it looks better to my eye than jamming
> everything into a single file (and I think more code can be moved out,
> but we can talk about it when you post the patches so that we can see
> context).
Sure, will send v2 after I re-check all the patches
and run some smoke tests again
>
> BTW, I believe it won't build with !CONFIG_XEN_GNTDEV_DMABUF ---
> gntdev_remove_map() is defined under this option and is referenced later
> without it.
Will check, thank you
>
> -boris
>
>
>> Thank you,
>> Oleksandr
>>>> -boris
>>>>
>>> Thank you,
>>> Oleksandr
>>>>>    drivers/xen/grant-table.c     |  176 +++++-
>>>>>    drivers/xen/mem-reservation.c |  134 +++++
>>>>>    include/uapi/xen/gntdev.h     |  106 ++++
>>>>>    include/xen/grant_dev.h       |   37 ++
>>>>>    include/xen/grant_table.h     |   28 +
>>>>>    include/xen/mem_reservation.h |   29 +
>>>>>    10 files changed, 1527 insertions(+), 103 deletions(-)
>>>>>    create mode 100644 drivers/xen/mem-reservation.c
>>>>>    create mode 100644 include/xen/grant_dev.h
>>>>>    create mode 100644 include/xen/mem_reservation.h
>>>>>
>> [1]
>> https://github.com/andr2000/linux/commits/xen_tip_linux_next_xen_dma_buf_v2


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

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

[Boris Ostrovsky]

On 05/31/2018 10:41 AM, Oleksandr Andrushchenko wrote:
> On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote:
>> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>>>
>>>
>>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>>>
>>>>
>>>> Oleksandr Andrushchenko (8):
>>>>    xen/grant-table: Make set/clear page private code shared
>>>>    xen/balloon: Move common memory reservation routines to a module
>>>>    xen/grant-table: Allow allocating buffers suitable for DMA
>>>>    xen/gntdev: Allow mappings for DMA buffers
>>>>    xen/gntdev: Add initial support for dma-buf UAPI
>>>>    xen/gntdev: Implement dma-buf export functionality
>>>>    xen/gntdev: Implement dma-buf import functionality
>>>>    xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
>>>>
>>>>   drivers/xen/Kconfig           |   23 +
>>>>   drivers/xen/Makefile          |    1 +
>>>>   drivers/xen/balloon.c         |   71 +--
>>>>   drivers/xen/gntdev.c          | 1025
>>>> ++++++++++++++++++++++++++++++++-
>>>
>>>
>>> I think this calls for gntdev_dma.c.
>> I assume you mean as a separate file (part of gntdev driver)?
>>> I only had a quick look over gntdev changes but they very much are
>>> concentrated in dma-specific routines.
>>>
>> I tried to do that, but there are some dependencies between the
>> gntdev.c and gntdev_dma.c,
>> so finally I decided to put it all together.
>>> You essentially only share file_operations entry points with
>>> original gntdev code, right?
>>>
>> fops + mappings done by gntdev (struct grant_map) and I need to
>> release map on dma_buf .release
>> callback which makes some cross-dependencies between modules which
>> seemed to be not cute
>> (gntdev keeps its all structs and functions inside, so I cannot
>> easily access those w/o
>> helpers).
>>
>> But I'll try one more time and move all DMA specific stuff into
>> gntdev_dma.c
> Could you please take a quick look at the way I re-structured the
> sources here [1]?
> If this is what you meant.


I looked at final gntdev.c code and I think at least one of the chunks
there ("DMA buffer export support. ") can also be moved out. It still
have a bit too many ifdefs but it looks better to my eye than jamming
everything into a single file (and I think more code can be moved out,
but we can talk about it when you post the patches so that we can see
context).

BTW, I believe it won't build with !CONFIG_XEN_GNTDEV_DMABUF ---
gntdev_remove_map() is defined under this option and is referenced later
without it.


-boris


>
> Thank you,
> Oleksandr
>>> -boris
>>>
>> Thank you,
>> Oleksandr
>>>
>>>>   drivers/xen/grant-table.c     |  176 +++++-
>>>>   drivers/xen/mem-reservation.c |  134 +++++
>>>>   include/uapi/xen/gntdev.h     |  106 ++++
>>>>   include/xen/grant_dev.h       |   37 ++
>>>>   include/xen/grant_table.h     |   28 +
>>>>   include/xen/mem_reservation.h |   29 +
>>>>   10 files changed, 1527 insertions(+), 103 deletions(-)
>>>>   create mode 100644 drivers/xen/mem-reservation.c
>>>>   create mode 100644 include/xen/grant_dev.h
>>>>   create mode 100644 include/xen/mem_reservation.h
>>>>
>>
> [1]
> https://github.com/andr2000/linux/commits/xen_tip_linux_next_xen_dma_buf_v2

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

[Boris Ostrovsky]

On 05/31/2018 10:41 AM, Oleksandr Andrushchenko wrote:
> On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote:
>> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>>>
>>>
>>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>>>
>>>>
>>>> Oleksandr Andrushchenko (8):
>>>>    xen/grant-table: Make set/clear page private code shared
>>>>    xen/balloon: Move common memory reservation routines to a module
>>>>    xen/grant-table: Allow allocating buffers suitable for DMA
>>>>    xen/gntdev: Allow mappings for DMA buffers
>>>>    xen/gntdev: Add initial support for dma-buf UAPI
>>>>    xen/gntdev: Implement dma-buf export functionality
>>>>    xen/gntdev: Implement dma-buf import functionality
>>>>    xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
>>>>
>>>>   drivers/xen/Kconfig           |   23 +
>>>>   drivers/xen/Makefile          |    1 +
>>>>   drivers/xen/balloon.c         |   71 +--
>>>>   drivers/xen/gntdev.c          | 1025
>>>> ++++++++++++++++++++++++++++++++-
>>>
>>>
>>> I think this calls for gntdev_dma.c.
>> I assume you mean as a separate file (part of gntdev driver)?
>>> I only had a quick look over gntdev changes but they very much are
>>> concentrated in dma-specific routines.
>>>
>> I tried to do that, but there are some dependencies between the
>> gntdev.c and gntdev_dma.c,
>> so finally I decided to put it all together.
>>> You essentially only share file_operations entry points with
>>> original gntdev code, right?
>>>
>> fops + mappings done by gntdev (struct grant_map) and I need to
>> release map on dma_buf .release
>> callback which makes some cross-dependencies between modules which
>> seemed to be not cute
>> (gntdev keeps its all structs and functions inside, so I cannot
>> easily access those w/o
>> helpers).
>>
>> But I'll try one more time and move all DMA specific stuff into
>> gntdev_dma.c
> Could you please take a quick look at the way I re-structured the
> sources here [1]?
> If this is what you meant.


I looked at final gntdev.c code and I think at least one of the chunks
there ("DMA buffer export support. ") can also be moved out. It still
have a bit too many ifdefs but it looks better to my eye than jamming
everything into a single file (and I think more code can be moved out,
but we can talk about it when you post the patches so that we can see
context).

BTW, I believe it won't build with !CONFIG_XEN_GNTDEV_DMABUF ---
gntdev_remove_map() is defined under this option and is referenced later
without it.


-boris


>
> Thank you,
> Oleksandr
>>> -boris
>>>
>> Thank you,
>> Oleksandr
>>>
>>>>   drivers/xen/grant-table.c     |  176 +++++-
>>>>   drivers/xen/mem-reservation.c |  134 +++++
>>>>   include/uapi/xen/gntdev.h     |  106 ++++
>>>>   include/xen/grant_dev.h       |   37 ++
>>>>   include/xen/grant_table.h     |   28 +
>>>>   include/xen/mem_reservation.h |   29 +
>>>>   10 files changed, 1527 insertions(+), 103 deletions(-)
>>>>   create mode 100644 drivers/xen/mem-reservation.c
>>>>   create mode 100644 include/xen/grant_dev.h
>>>>   create mode 100644 include/xen/mem_reservation.h
>>>>
>>
> [1]
> https://github.com/andr2000/linux/commits/xen_tip_linux_next_xen_dma_buf_v2


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

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

[Boris Ostrovsky]

On 05/31/2018 01:51 AM, Oleksandr Andrushchenko wrote:
> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>>
>>
>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>>
>>>
>>> Oleksandr Andrushchenko (8):
>>>    xen/grant-table: Make set/clear page private code shared
>>>    xen/balloon: Move common memory reservation routines to a module
>>>    xen/grant-table: Allow allocating buffers suitable for DMA
>>>    xen/gntdev: Allow mappings for DMA buffers
>>>    xen/gntdev: Add initial support for dma-buf UAPI
>>>    xen/gntdev: Implement dma-buf export functionality
>>>    xen/gntdev: Implement dma-buf import functionality
>>>    xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
>>>
>>>   drivers/xen/Kconfig           |   23 +
>>>   drivers/xen/Makefile          |    1 +
>>>   drivers/xen/balloon.c         |   71 +--
>>>   drivers/xen/gntdev.c          | 1025
>>> ++++++++++++++++++++++++++++++++-
>>
>>
>> I think this calls for gntdev_dma.c.
> I assume you mean as a separate file (part of gntdev driver)?


Yes, source only. The driver stays the same.


>> I only had a quick look over gntdev changes but they very much are
>> concentrated in dma-specific routines.
>>
> I tried to do that, but there are some dependencies between the
> gntdev.c and gntdev_dma.c,
> so finally I decided to put it all together.
>> You essentially only share file_operations entry points with original
>> gntdev code, right?
>>
> fops + mappings done by gntdev (struct grant_map) and I need to
> release map on dma_buf .release
> callback which makes some cross-dependencies between modules which
> seemed to be not cute
> (gntdev keeps its all structs and functions inside, so I cannot easily
> access those w/o
> helpers).
>
> But I'll try one more time and move all DMA specific stuff into
> gntdev_dma.c


Yes, please try it. Maybe even have gntdev_common.c, gntdev_mem.c (??) 
and gntdev_dma.c.

-boris


>> -boris
>>
> Thank you,
> Oleksandr
>>
>>>   drivers/xen/grant-table.c     |  176 +++++-
>>>   drivers/xen/mem-reservation.c |  134 +++++
>>>   include/uapi/xen/gntdev.h     |  106 ++++
>>>   include/xen/grant_dev.h       |   37 ++
>>>   include/xen/grant_table.h     |   28 +
>>>   include/xen/mem_reservation.h |   29 +
>>>   10 files changed, 1527 insertions(+), 103 deletions(-)
>>>   create mode 100644 drivers/xen/mem-reservation.c
>>>   create mode 100644 include/xen/grant_dev.h
>>>   create mode 100644 include/xen/mem_reservation.h
>>>
>

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

[Boris Ostrovsky]

On 05/31/2018 01:51 AM, Oleksandr Andrushchenko wrote:
> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>>
>>
>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>>
>>>
>>> Oleksandr Andrushchenko (8):
>>>    xen/grant-table: Make set/clear page private code shared
>>>    xen/balloon: Move common memory reservation routines to a module
>>>    xen/grant-table: Allow allocating buffers suitable for DMA
>>>    xen/gntdev: Allow mappings for DMA buffers
>>>    xen/gntdev: Add initial support for dma-buf UAPI
>>>    xen/gntdev: Implement dma-buf export functionality
>>>    xen/gntdev: Implement dma-buf import functionality
>>>    xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
>>>
>>>   drivers/xen/Kconfig           |   23 +
>>>   drivers/xen/Makefile          |    1 +
>>>   drivers/xen/balloon.c         |   71 +--
>>>   drivers/xen/gntdev.c          | 1025
>>> ++++++++++++++++++++++++++++++++-
>>
>>
>> I think this calls for gntdev_dma.c.
> I assume you mean as a separate file (part of gntdev driver)?


Yes, source only. The driver stays the same.


>> I only had a quick look over gntdev changes but they very much are
>> concentrated in dma-specific routines.
>>
> I tried to do that, but there are some dependencies between the
> gntdev.c and gntdev_dma.c,
> so finally I decided to put it all together.
>> You essentially only share file_operations entry points with original
>> gntdev code, right?
>>
> fops + mappings done by gntdev (struct grant_map) and I need to
> release map on dma_buf .release
> callback which makes some cross-dependencies between modules which
> seemed to be not cute
> (gntdev keeps its all structs and functions inside, so I cannot easily
> access those w/o
> helpers).
>
> But I'll try one more time and move all DMA specific stuff into
> gntdev_dma.c


Yes, please try it. Maybe even have gntdev_common.c, gntdev_mem.c (??) 
and gntdev_dma.c.

-boris


>> -boris
>>
> Thank you,
> Oleksandr
>>
>>>   drivers/xen/grant-table.c     |  176 +++++-
>>>   drivers/xen/mem-reservation.c |  134 +++++
>>>   include/uapi/xen/gntdev.h     |  106 ++++
>>>   include/xen/grant_dev.h       |   37 ++
>>>   include/xen/grant_table.h     |   28 +
>>>   include/xen/mem_reservation.h |   29 +
>>>   10 files changed, 1527 insertions(+), 103 deletions(-)
>>>   create mode 100644 drivers/xen/mem-reservation.c
>>>   create mode 100644 include/xen/grant_dev.h
>>>   create mode 100644 include/xen/mem_reservation.h
>>>
>


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

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

[Oleksandr Andrushchenko]

On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote:
> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>>
>>
>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>>
>>>
>>> Oleksandr Andrushchenko (8):
>>>    xen/grant-table: Make set/clear page private code shared
>>>    xen/balloon: Move common memory reservation routines to a module
>>>    xen/grant-table: Allow allocating buffers suitable for DMA
>>>    xen/gntdev: Allow mappings for DMA buffers
>>>    xen/gntdev: Add initial support for dma-buf UAPI
>>>    xen/gntdev: Implement dma-buf export functionality
>>>    xen/gntdev: Implement dma-buf import functionality
>>>    xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
>>>
>>>   drivers/xen/Kconfig           |   23 +
>>>   drivers/xen/Makefile          |    1 +
>>>   drivers/xen/balloon.c         |   71 +--
>>>   drivers/xen/gntdev.c          | 1025 
>>> ++++++++++++++++++++++++++++++++-
>>
>>
>> I think this calls for gntdev_dma.c.
> I assume you mean as a separate file (part of gntdev driver)?
>> I only had a quick look over gntdev changes but they very much are 
>> concentrated in dma-specific routines.
>>
> I tried to do that, but there are some dependencies between the 
> gntdev.c and gntdev_dma.c,
> so finally I decided to put it all together.
>> You essentially only share file_operations entry points with original 
>> gntdev code, right?
>>
> fops + mappings done by gntdev (struct grant_map) and I need to 
> release map on dma_buf .release
> callback which makes some cross-dependencies between modules which 
> seemed to be not cute
> (gntdev keeps its all structs and functions inside, so I cannot easily 
> access those w/o
> helpers).
>
> But I'll try one more time and move all DMA specific stuff into 
> gntdev_dma.c
Could you please take a quick look at the way I re-structured the 
sources here [1]?
If this is what you meant.

Thank you,
Oleksandr
>> -boris
>>
> Thank you,
> Oleksandr
>>
>>>   drivers/xen/grant-table.c     |  176 +++++-
>>>   drivers/xen/mem-reservation.c |  134 +++++
>>>   include/uapi/xen/gntdev.h     |  106 ++++
>>>   include/xen/grant_dev.h       |   37 ++
>>>   include/xen/grant_table.h     |   28 +
>>>   include/xen/mem_reservation.h |   29 +
>>>   10 files changed, 1527 insertions(+), 103 deletions(-)
>>>   create mode 100644 drivers/xen/mem-reservation.c
>>>   create mode 100644 include/xen/grant_dev.h
>>>   create mode 100644 include/xen/mem_reservation.h
>>>
>
[1] 
https://github.com/andr2000/linux/commits/xen_tip_linux_next_xen_dma_buf_v2

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

[Oleksandr Andrushchenko]

On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote:
> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>>
>>
>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>>
>>>
>>> Oleksandr Andrushchenko (8):
>>>    xen/grant-table: Make set/clear page private code shared
>>>    xen/balloon: Move common memory reservation routines to a module
>>>    xen/grant-table: Allow allocating buffers suitable for DMA
>>>    xen/gntdev: Allow mappings for DMA buffers
>>>    xen/gntdev: Add initial support for dma-buf UAPI
>>>    xen/gntdev: Implement dma-buf export functionality
>>>    xen/gntdev: Implement dma-buf import functionality
>>>    xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
>>>
>>>   drivers/xen/Kconfig           |   23 +
>>>   drivers/xen/Makefile          |    1 +
>>>   drivers/xen/balloon.c         |   71 +--
>>>   drivers/xen/gntdev.c          | 1025 
>>> ++++++++++++++++++++++++++++++++-
>>
>>
>> I think this calls for gntdev_dma.c.
> I assume you mean as a separate file (part of gntdev driver)?
>> I only had a quick look over gntdev changes but they very much are 
>> concentrated in dma-specific routines.
>>
> I tried to do that, but there are some dependencies between the 
> gntdev.c and gntdev_dma.c,
> so finally I decided to put it all together.
>> You essentially only share file_operations entry points with original 
>> gntdev code, right?
>>
> fops + mappings done by gntdev (struct grant_map) and I need to 
> release map on dma_buf .release
> callback which makes some cross-dependencies between modules which 
> seemed to be not cute
> (gntdev keeps its all structs and functions inside, so I cannot easily 
> access those w/o
> helpers).
>
> But I'll try one more time and move all DMA specific stuff into 
> gntdev_dma.c
Could you please take a quick look at the way I re-structured the 
sources here [1]?
If this is what you meant.

Thank you,
Oleksandr
>> -boris
>>
> Thank you,
> Oleksandr
>>
>>>   drivers/xen/grant-table.c     |  176 +++++-
>>>   drivers/xen/mem-reservation.c |  134 +++++
>>>   include/uapi/xen/gntdev.h     |  106 ++++
>>>   include/xen/grant_dev.h       |   37 ++
>>>   include/xen/grant_table.h     |   28 +
>>>   include/xen/mem_reservation.h |   29 +
>>>   10 files changed, 1527 insertions(+), 103 deletions(-)
>>>   create mode 100644 drivers/xen/mem-reservation.c
>>>   create mode 100644 include/xen/grant_dev.h
>>>   create mode 100644 include/xen/mem_reservation.h
>>>
>
[1] 
https://github.com/andr2000/linux/commits/xen_tip_linux_next_xen_dma_buf_v2
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Oleksandr Andrushchenko]

On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote:
> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>>
>>
>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>>
>>>
>>> Oleksandr Andrushchenko (8):
>>>    xen/grant-table: Make set/clear page private code shared
>>>    xen/balloon: Move common memory reservation routines to a module
>>>    xen/grant-table: Allow allocating buffers suitable for DMA
>>>    xen/gntdev: Allow mappings for DMA buffers
>>>    xen/gntdev: Add initial support for dma-buf UAPI
>>>    xen/gntdev: Implement dma-buf export functionality
>>>    xen/gntdev: Implement dma-buf import functionality
>>>    xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
>>>
>>>   drivers/xen/Kconfig           |   23 +
>>>   drivers/xen/Makefile          |    1 +
>>>   drivers/xen/balloon.c         |   71 +--
>>>   drivers/xen/gntdev.c          | 1025 
>>> ++++++++++++++++++++++++++++++++-
>>
>>
>> I think this calls for gntdev_dma.c.
> I assume you mean as a separate file (part of gntdev driver)?
>> I only had a quick look over gntdev changes but they very much are 
>> concentrated in dma-specific routines.
>>
> I tried to do that, but there are some dependencies between the 
> gntdev.c and gntdev_dma.c,
> so finally I decided to put it all together.
>> You essentially only share file_operations entry points with original 
>> gntdev code, right?
>>
> fops + mappings done by gntdev (struct grant_map) and I need to 
> release map on dma_buf .release
> callback which makes some cross-dependencies between modules which 
> seemed to be not cute
> (gntdev keeps its all structs and functions inside, so I cannot easily 
> access those w/o
> helpers).
>
> But I'll try one more time and move all DMA specific stuff into 
> gntdev_dma.c
Could you please take a quick look at the way I re-structured the 
sources here [1]?
If this is what you meant.

Thank you,
Oleksandr
>> -boris
>>
> Thank you,
> Oleksandr
>>
>>>   drivers/xen/grant-table.c     |  176 +++++-
>>>   drivers/xen/mem-reservation.c |  134 +++++
>>>   include/uapi/xen/gntdev.h     |  106 ++++
>>>   include/xen/grant_dev.h       |   37 ++
>>>   include/xen/grant_table.h     |   28 +
>>>   include/xen/mem_reservation.h |   29 +
>>>   10 files changed, 1527 insertions(+), 103 deletions(-)
>>>   create mode 100644 drivers/xen/mem-reservation.c
>>>   create mode 100644 include/xen/grant_dev.h
>>>   create mode 100644 include/xen/mem_reservation.h
>>>
>
[1] 
https://github.com/andr2000/linux/commits/xen_tip_linux_next_xen_dma_buf_v2

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

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

[Oleksandr Andrushchenko]

On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>
>
> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>
>>
>> Oleksandr Andrushchenko (8):
>>    xen/grant-table: Make set/clear page private code shared
>>    xen/balloon: Move common memory reservation routines to a module
>>    xen/grant-table: Allow allocating buffers suitable for DMA
>>    xen/gntdev: Allow mappings for DMA buffers
>>    xen/gntdev: Add initial support for dma-buf UAPI
>>    xen/gntdev: Implement dma-buf export functionality
>>    xen/gntdev: Implement dma-buf import functionality
>>    xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
>>
>>   drivers/xen/Kconfig           |   23 +
>>   drivers/xen/Makefile          |    1 +
>>   drivers/xen/balloon.c         |   71 +--
>>   drivers/xen/gntdev.c          | 1025 ++++++++++++++++++++++++++++++++-
>
>
> I think this calls for gntdev_dma.c.
I assume you mean as a separate file (part of gntdev driver)?
> I only had a quick look over gntdev changes but they very much are 
> concentrated in dma-specific routines.
>
I tried to do that, but there are some dependencies between the gntdev.c 
and gntdev_dma.c,
so finally I decided to put it all together.
> You essentially only share file_operations entry points with original 
> gntdev code, right?
>
fops + mappings done by gntdev (struct grant_map) and I need to release 
map on dma_buf .release
callback which makes some cross-dependencies between modules which 
seemed to be not cute
(gntdev keeps its all structs and functions inside, so I cannot easily 
access those w/o
helpers).

But I'll try one more time and move all DMA specific stuff into gntdev_dma.c
> -boris
>
Thank you,
Oleksandr
>
>>   drivers/xen/grant-table.c     |  176 +++++-
>>   drivers/xen/mem-reservation.c |  134 +++++
>>   include/uapi/xen/gntdev.h     |  106 ++++
>>   include/xen/grant_dev.h       |   37 ++
>>   include/xen/grant_table.h     |   28 +
>>   include/xen/mem_reservation.h |   29 +
>>   10 files changed, 1527 insertions(+), 103 deletions(-)
>>   create mode 100644 drivers/xen/mem-reservation.c
>>   create mode 100644 include/xen/grant_dev.h
>>   create mode 100644 include/xen/mem_reservation.h
>>

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

[Oleksandr Andrushchenko]

On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>
>
> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>
>>
>> Oleksandr Andrushchenko (8):
>>    xen/grant-table: Make set/clear page private code shared
>>    xen/balloon: Move common memory reservation routines to a module
>>    xen/grant-table: Allow allocating buffers suitable for DMA
>>    xen/gntdev: Allow mappings for DMA buffers
>>    xen/gntdev: Add initial support for dma-buf UAPI
>>    xen/gntdev: Implement dma-buf export functionality
>>    xen/gntdev: Implement dma-buf import functionality
>>    xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
>>
>>   drivers/xen/Kconfig           |   23 +
>>   drivers/xen/Makefile          |    1 +
>>   drivers/xen/balloon.c         |   71 +--
>>   drivers/xen/gntdev.c          | 1025 ++++++++++++++++++++++++++++++++-
>
>
> I think this calls for gntdev_dma.c.
I assume you mean as a separate file (part of gntdev driver)?
> I only had a quick look over gntdev changes but they very much are 
> concentrated in dma-specific routines.
>
I tried to do that, but there are some dependencies between the gntdev.c 
and gntdev_dma.c,
so finally I decided to put it all together.
> You essentially only share file_operations entry points with original 
> gntdev code, right?
>
fops + mappings done by gntdev (struct grant_map) and I need to release 
map on dma_buf .release
callback which makes some cross-dependencies between modules which 
seemed to be not cute
(gntdev keeps its all structs and functions inside, so I cannot easily 
access those w/o
helpers).

But I'll try one more time and move all DMA specific stuff into gntdev_dma.c
> -boris
>
Thank you,
Oleksandr
>
>>   drivers/xen/grant-table.c     |  176 +++++-
>>   drivers/xen/mem-reservation.c |  134 +++++
>>   include/uapi/xen/gntdev.h     |  106 ++++
>>   include/xen/grant_dev.h       |   37 ++
>>   include/xen/grant_table.h     |   28 +
>>   include/xen/mem_reservation.h |   29 +
>>   10 files changed, 1527 insertions(+), 103 deletions(-)
>>   create mode 100644 drivers/xen/mem-reservation.c
>>   create mode 100644 include/xen/grant_dev.h
>>   create mode 100644 include/xen/mem_reservation.h
>>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Oleksandr Andrushchenko]

On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>
>
> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>
>>
>> Oleksandr Andrushchenko (8):
>>    xen/grant-table: Make set/clear page private code shared
>>    xen/balloon: Move common memory reservation routines to a module
>>    xen/grant-table: Allow allocating buffers suitable for DMA
>>    xen/gntdev: Allow mappings for DMA buffers
>>    xen/gntdev: Add initial support for dma-buf UAPI
>>    xen/gntdev: Implement dma-buf export functionality
>>    xen/gntdev: Implement dma-buf import functionality
>>    xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
>>
>>   drivers/xen/Kconfig           |   23 +
>>   drivers/xen/Makefile          |    1 +
>>   drivers/xen/balloon.c         |   71 +--
>>   drivers/xen/gntdev.c          | 1025 ++++++++++++++++++++++++++++++++-
>
>
> I think this calls for gntdev_dma.c.
I assume you mean as a separate file (part of gntdev driver)?
> I only had a quick look over gntdev changes but they very much are 
> concentrated in dma-specific routines.
>
I tried to do that, but there are some dependencies between the gntdev.c 
and gntdev_dma.c,
so finally I decided to put it all together.
> You essentially only share file_operations entry points with original 
> gntdev code, right?
>
fops + mappings done by gntdev (struct grant_map) and I need to release 
map on dma_buf .release
callback which makes some cross-dependencies between modules which 
seemed to be not cute
(gntdev keeps its all structs and functions inside, so I cannot easily 
access those w/o
helpers).

But I'll try one more time and move all DMA specific stuff into gntdev_dma.c
> -boris
>
Thank you,
Oleksandr
>
>>   drivers/xen/grant-table.c     |  176 +++++-
>>   drivers/xen/mem-reservation.c |  134 +++++
>>   include/uapi/xen/gntdev.h     |  106 ++++
>>   include/xen/grant_dev.h       |   37 ++
>>   include/xen/grant_table.h     |   28 +
>>   include/xen/mem_reservation.h |   29 +
>>   10 files changed, 1527 insertions(+), 103 deletions(-)
>>   create mode 100644 drivers/xen/mem-reservation.c
>>   create mode 100644 include/xen/grant_dev.h
>>   create mode 100644 include/xen/mem_reservation.h
>>


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

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

[Boris Ostrovsky]

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:

> 
> Oleksandr Andrushchenko (8):
>    xen/grant-table: Make set/clear page private code shared
>    xen/balloon: Move common memory reservation routines to a module
>    xen/grant-table: Allow allocating buffers suitable for DMA
>    xen/gntdev: Allow mappings for DMA buffers
>    xen/gntdev: Add initial support for dma-buf UAPI
>    xen/gntdev: Implement dma-buf export functionality
>    xen/gntdev: Implement dma-buf import functionality
>    xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
> 
>   drivers/xen/Kconfig           |   23 +
>   drivers/xen/Makefile          |    1 +
>   drivers/xen/balloon.c         |   71 +--
>   drivers/xen/gntdev.c          | 1025 ++++++++++++++++++++++++++++++++-


I think this calls for gntdev_dma.c. I only had a quick look over gntdev 
changes but they very much are concentrated in dma-specific routines.

You essentially only share file_operations entry points with original 
gntdev code, right?

-boris


>   drivers/xen/grant-table.c     |  176 +++++-
>   drivers/xen/mem-reservation.c |  134 +++++
>   include/uapi/xen/gntdev.h     |  106 ++++
>   include/xen/grant_dev.h       |   37 ++
>   include/xen/grant_table.h     |   28 +
>   include/xen/mem_reservation.h |   29 +
>   10 files changed, 1527 insertions(+), 103 deletions(-)
>   create mode 100644 drivers/xen/mem-reservation.c
>   create mode 100644 include/xen/grant_dev.h
>   create mode 100644 include/xen/mem_reservation.h
> 

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

[Boris Ostrovsky]

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:

> 
> Oleksandr Andrushchenko (8):
>    xen/grant-table: Make set/clear page private code shared
>    xen/balloon: Move common memory reservation routines to a module
>    xen/grant-table: Allow allocating buffers suitable for DMA
>    xen/gntdev: Allow mappings for DMA buffers
>    xen/gntdev: Add initial support for dma-buf UAPI
>    xen/gntdev: Implement dma-buf export functionality
>    xen/gntdev: Implement dma-buf import functionality
>    xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
> 
>   drivers/xen/Kconfig           |   23 +
>   drivers/xen/Makefile          |    1 +
>   drivers/xen/balloon.c         |   71 +--
>   drivers/xen/gntdev.c          | 1025 ++++++++++++++++++++++++++++++++-


I think this calls for gntdev_dma.c. I only had a quick look over gntdev 
changes but they very much are concentrated in dma-specific routines.

You essentially only share file_operations entry points with original 
gntdev code, right?

-boris


>   drivers/xen/grant-table.c     |  176 +++++-
>   drivers/xen/mem-reservation.c |  134 +++++
>   include/uapi/xen/gntdev.h     |  106 ++++
>   include/xen/grant_dev.h       |   37 ++
>   include/xen/grant_table.h     |   28 +
>   include/xen/mem_reservation.h |   29 +
>   10 files changed, 1527 insertions(+), 103 deletions(-)
>   create mode 100644 drivers/xen/mem-reservation.c
>   create mode 100644 include/xen/grant_dev.h
>   create mode 100644 include/xen/mem_reservation.h
> 

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

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

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

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 four 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-Move-common-memory-reservation-routines-.patch
   0003-xen-grant-table-Allow-allocating-buffers-suitable-fo.patch
   0004-xen-gntdev-Allow-mappings-for-DMA-buffers.patch

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

The last patch makes it possible for in-kernel use of Xen dma-buf API:
  0008-xen-gntdev-Expose-gntdev-s-dma-buf-API-for-in-kernel.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.

*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

Oleksandr Andrushchenko (8):
  xen/grant-table: Make set/clear page private code shared
  xen/balloon: Move common memory reservation routines to a module
  xen/grant-table: Allow allocating buffers suitable for DMA
  xen/gntdev: Allow mappings for DMA buffers
  xen/gntdev: Add initial support for dma-buf UAPI
  xen/gntdev: Implement dma-buf export functionality
  xen/gntdev: Implement dma-buf import functionality
  xen/gntdev: Expose gntdev's dma-buf API for in-kernel use

 drivers/xen/Kconfig           |   23 +
 drivers/xen/Makefile          |    1 +
 drivers/xen/balloon.c         |   71 +--
 drivers/xen/gntdev.c          | 1025 ++++++++++++++++++++++++++++++++-
 drivers/xen/grant-table.c     |  176 +++++-
 drivers/xen/mem-reservation.c |  134 +++++
 include/uapi/xen/gntdev.h     |  106 ++++
 include/xen/grant_dev.h       |   37 ++
 include/xen/grant_table.h     |   28 +
 include/xen/mem_reservation.h |   29 +
 10 files changed, 1527 insertions(+), 103 deletions(-)
 create mode 100644 drivers/xen/mem-reservation.c
 create mode 100644 include/xen/grant_dev.h
 create mode 100644 include/xen/mem_reservation.h

-- 
2.17.0

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

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

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 four 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-Move-common-memory-reservation-routines-.patch
   0003-xen-grant-table-Allow-allocating-buffers-suitable-fo.patch
   0004-xen-gntdev-Allow-mappings-for-DMA-buffers.patch

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

The last patch makes it possible for in-kernel use of Xen dma-buf API:
  0008-xen-gntdev-Expose-gntdev-s-dma-buf-API-for-in-kernel.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.

*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

Oleksandr Andrushchenko (8):
  xen/grant-table: Make set/clear page private code shared
  xen/balloon: Move common memory reservation routines to a module
  xen/grant-table: Allow allocating buffers suitable for DMA
  xen/gntdev: Allow mappings for DMA buffers
  xen/gntdev: Add initial support for dma-buf UAPI
  xen/gntdev: Implement dma-buf export functionality
  xen/gntdev: Implement dma-buf import functionality
  xen/gntdev: Expose gntdev's dma-buf API for in-kernel use

 drivers/xen/Kconfig           |   23 +
 drivers/xen/Makefile          |    1 +
 drivers/xen/balloon.c         |   71 +--
 drivers/xen/gntdev.c          | 1025 ++++++++++++++++++++++++++++++++-
 drivers/xen/grant-table.c     |  176 +++++-
 drivers/xen/mem-reservation.c |  134 +++++
 include/uapi/xen/gntdev.h     |  106 ++++
 include/xen/grant_dev.h       |   37 ++
 include/xen/grant_table.h     |   28 +
 include/xen/mem_reservation.h |   29 +
 10 files changed, 1527 insertions(+), 103 deletions(-)
 create mode 100644 drivers/xen/mem-reservation.c
 create mode 100644 include/xen/grant_dev.h
 create mode 100644 include/xen/mem_reservation.h

-- 
2.17.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel