[PATCH v1 0/3] Add ioctls to map grant refs on the external backing storage

Oleksii Moisieiev posted 3 patches 1 year, 3 months ago
Failed in applying to current master (apply log)
There is a newer version of this series
drivers/dma-buf/dma-buf.c   |  44 ++++
drivers/xen/gntdev-common.h |   8 +-
drivers/xen/gntdev-dmabuf.c | 416 +++++++++++++++++++++++++++++++++++-
drivers/xen/gntdev-dmabuf.h |   7 +
drivers/xen/gntdev.c        | 101 ++++++++-
drivers/xen/grant-table.c   |  73 +++++--
include/linux/dma-buf.h     |  15 ++
include/uapi/xen/gntdev.h   |  62 ++++++
include/xen/grant_table.h   |   8 +
9 files changed, 703 insertions(+), 31 deletions(-)
[PATCH v1 0/3] Add ioctls to map grant refs on the external backing storage
Posted by Oleksii Moisieiev 1 year, 3 months ago
Hello,

Let me introduce the new ioctls, which are intended to allow gntdev to
map scatter-gather table on top of the existing dmabuf, referenced by
file descriptor.

When using dma-buf exporter to create dma-buf with backing storage and
map it to the grant refs, provided from the domain, we've met a problem,
that several HW (i.MX8 gpu in our case) do not support external buffer
and requires backing storage to be created using it's native tools.
That's why new ioctls were added to be able to pass existing dma-buffer
fd as input parameter and use it as backing storage to export to refs.

Following calls were added:
IOCTL_GNTDEV_DMABUF_MAP_REFS_TO_BUF - map existing buffer as the backing
storage and export it to the provided grant refs;
IOCTL_GNTDEV_DMABUF_MAP_RELEASE - detach buffer from the grant table and
set notification to unmap grant refs before releasing the external
buffer. After this call the external buffer should be detroyed.
IOCTL_GNTDEV_DMABUF_MAP_WAIT_RELEASED - wait for timeout until buffer is
completely destroyed and gnt refs unmapped so domain could free grant
pages. Should be called after buffer was destoyed.

Our setup is based on IMX8QM board. We're trying to implement zero-copy
support for DomU graphics using Wayland zwp_linux_dmabuf_v1_interface
implementation.

For dma-buf exporter we used i.MX8 gpu native tools to create backing
storage grant-refs, received from DomU. Buffer for the backing storage was
allocated using gbm_bo_create call because gpu do not support external
buffer and requires backing storage to be created using it's native tools
(eglCreateImageKHR returns EGL_NO_IMAGE_KHR for buffers, which were not
created using gbm_bo_create).

This behaviour was also tested on Qemu setup using
DRM_IOCTL_MODE_CREATE_DUMB call to create backing storage buffer.

---
Oleksii Moisieiev (3):
  xen/grant-table: save page_count on map and use if during async
    unmapping
  dma-buf: add dma buffer release notifier callback
  xen/grant-table: add new ioctls to map dmabuf to existing fd

 drivers/dma-buf/dma-buf.c   |  44 ++++
 drivers/xen/gntdev-common.h |   8 +-
 drivers/xen/gntdev-dmabuf.c | 416 +++++++++++++++++++++++++++++++++++-
 drivers/xen/gntdev-dmabuf.h |   7 +
 drivers/xen/gntdev.c        | 101 ++++++++-
 drivers/xen/grant-table.c   |  73 +++++--
 include/linux/dma-buf.h     |  15 ++
 include/uapi/xen/gntdev.h   |  62 ++++++
 include/xen/grant_table.h   |   8 +
 9 files changed, 703 insertions(+), 31 deletions(-)

-- 
2.25.1
Re: [PATCH v1 0/3] Add ioctls to map grant refs on the external backing storage
Posted by Oleksii Moisieiev 1 year ago
Hello,

Just wanted to add some additional information hoping it will help to start the discussion and find a correct approach:

My goal is to provide correct buffer for the interfaces, such as zwp_linux_dmabuf_v1_interface, so zero-copy
feature will work. My suggestion is to give a possibility to use some specific buffer as backing storage where caller
takes responsibility for the provided buffer to have the correct format.

In our case we are using these calls the following way:
1) Get grefs from another Domain (We're working on the virtualized system with different Domains
working as standalone VMs that are sharing resources);

2) Create buffer using gbm_bo_create and receive fd (i.MX8 requires egl api to be called for the buffer
allocation, or eglCreateImageKHR will return EGL_NO_IMAGE_KHR during param setting for zwp_linux_dmabuf);

3) Call for IOCTL_GNTDEV_DMABUF_MAP_REFS_TO_BUF to map grefs using fd as the backing storage;

4) Call for zwp_linux_dmabuf_v1_interface and use zero-copy feature with Wayland;

5) After work finished - call for IOCTL_GNTDEV_DMABUF_MAP_RELEASE to unmap grant refs;

6) Call gbm_bo_destroy to release allocated BO object;

7) Call for IOCTL_GNTDEV_DMABUF_MAP_WAIT_RELEASED to wait until map released completely

(This includes releasing grant refs on the Domain side).

I've tested my changes on IMX8QM board using gbm_bo_create to allocate buffer and

on QEMU setup using DRM_IOCTL_MODE_CREATE_DUMB for buffer allocation.


There was a suggestion to reverse roles between exporter and imported and allocate buffer on the other side, but
this approach doesn't fit to our setup.

I have a board on which starts XEN hypervisor with several virtual domains:

One domain (Dom0) has access to the hardware and is a backend side for the Graphic sharing. Another domain (DomU) is the frontend

side and runs it's Weston instance with zero-copy on the buffer, provided by the backend.

The configuration when Dom0 as Driver domain allocates dma-buf and the exports it to the DomU is not meant to be supported, see link:
https://nvd.nist.gov/vuln/detail/CVE-2021-26934

The vulnerability is that there is no way to free buffer which was exported to DomU in case if DomU crashes.

That's why I'm trying to make a solution which should work without need to switch importer and exporter.

I'm aware that my solution may be (and is) not correct, but my intend is to start the discussion in order to produce the appropriate solution.

Best regards,

Oleksii.



On 02.01.23 15:41, Oleksii Moisieiev wrote:

Hello,

Let me introduce the new ioctls, which are intended to allow gntdev to
map scatter-gather table on top of the existing dmabuf, referenced by
file descriptor.

When using dma-buf exporter to create dma-buf with backing storage and
map it to the grant refs, provided from the domain, we've met a problem,
that several HW (i.MX8 gpu in our case) do not support external buffer
and requires backing storage to be created using it's native tools.
That's why new ioctls were added to be able to pass existing dma-buffer
fd as input parameter and use it as backing storage to export to refs.

Following calls were added:
IOCTL_GNTDEV_DMABUF_MAP_REFS_TO_BUF - map existing buffer as the backing
storage and export it to the provided grant refs;
IOCTL_GNTDEV_DMABUF_MAP_RELEASE - detach buffer from the grant table and
set notification to unmap grant refs before releasing the external
buffer. After this call the external buffer should be detroyed.
IOCTL_GNTDEV_DMABUF_MAP_WAIT_RELEASED - wait for timeout until buffer is
completely destroyed and gnt refs unmapped so domain could free grant
pages. Should be called after buffer was destoyed.

Our setup is based on IMX8QM board. We're trying to implement zero-copy
support for DomU graphics using Wayland zwp_linux_dmabuf_v1_interface
implementation.

For dma-buf exporter we used i.MX8 gpu native tools to create backing
storage grant-refs, received from DomU. Buffer for the backing storage was
allocated using gbm_bo_create call because gpu do not support external
buffer and requires backing storage to be created using it's native tools
(eglCreateImageKHR returns EGL_NO_IMAGE_KHR for buffers, which were not
created using gbm_bo_create).

This behaviour was also tested on Qemu setup using
DRM_IOCTL_MODE_CREATE_DUMB call to create backing storage buffer.

---
Oleksii Moisieiev (3):
  xen/grant-table: save page_count on map and use if during async
    unmapping
  dma-buf: add dma buffer release notifier callback
  xen/grant-table: add new ioctls to map dmabuf to existing fd

 drivers/dma-buf/dma-buf.c   |  44 ++++
 drivers/xen/gntdev-common.h |   8 +-
 drivers/xen/gntdev-dmabuf.c | 416 +++++++++++++++++++++++++++++++++++-
 drivers/xen/gntdev-dmabuf.h |   7 +
 drivers/xen/gntdev.c        | 101 ++++++++-
 drivers/xen/grant-table.c   |  73 +++++--
 include/linux/dma-buf.h     |  15 ++
 include/uapi/xen/gntdev.h   |  62 ++++++
 include/xen/grant_table.h   |   8 +
 9 files changed, 703 insertions(+), 31 deletions(-)


AW: [PATCH v1 0/3] Add ioctls to map grant refs on the external backing storage
Posted by Koenig, Christian 1 year, 3 months ago
[AMD Official Use Only - General]

Sorry for the messed up mail. We currently have mail problems here at AMD.

________________________________
Von: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>
Gesendet: Montag, 2. Januar 2023 14:41
An: jgross@suse.com <jgross@suse.com>
Cc: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>; Stefano Stabellini <sstabellini@kernel.org>; Oleksandr Tyshchenko <Oleksandr_Tyshchenko@epam.com>; xen-devel@lists.xenproject.org <xen-devel@lists.xenproject.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; Sumit Semwal <sumit.semwal@linaro.org>; Koenig, Christian <Christian.Koenig@amd.com>; linux-media@vger.kernel.org <linux-media@vger.kernel.org>; dri-devel@lists.freedesktop.org <dri-devel@lists.freedesktop.org>; linaro-mm-sig@lists.linaro.org <linaro-mm-sig@lists.linaro.org>
Betreff: [PATCH v1 0/3] Add ioctls to map grant refs on the external backing storage

Hello,

Let me introduce the new ioctls, which are intended to allow gntdev to
map scatter-gather table on top of the existing dmabuf, referenced by
file descriptor.

When using dma-buf exporter to create dma-buf with backing storage and
map it to the grant refs, provided from the domain, we've met a problem,
that several HW (i.MX8 gpu in our case) do not support external buffer
and requires backing storage to be created using it's native tools.
That's why new ioctls were added to be able to pass existing dma-buffer
fd as input parameter and use it as backing storage to export to refs.

This is a pretty big NAK from my side to this approach.

If you need to replace a file descriptor number local to your process then you can simply use dup2() from userspace.

If your intention here is to replace the backing store of the fd on all processes which currently have it open then please just completely forget that. This will *NEVER* ever work correctly.

Regards,
Christian.

Following calls were added:
IOCTL_GNTDEV_DMABUF_MAP_REFS_TO_BUF - map existing buffer as the backing
storage and export it to the provided grant refs;
IOCTL_GNTDEV_DMABUF_MAP_RELEASE - detach buffer from the grant table and
set notification to unmap grant refs before releasing the external
buffer. After this call the external buffer should be detroyed.
IOCTL_GNTDEV_DMABUF_MAP_WAIT_RELEASED - wait for timeout until buffer is
completely destroyed and gnt refs unmapped so domain could free grant
pages. Should be called after buffer was destoyed.

Our setup is based on IMX8QM board. We're trying to implement zero-copy
support for DomU graphics using Wayland zwp_linux_dmabuf_v1_interface
implementation.

For dma-buf exporter we used i.MX8 gpu native tools to create backing
storage grant-refs, received from DomU. Buffer for the backing storage was
allocated using gbm_bo_create call because gpu do not support external
buffer and requires backing storage to be created using it's native tools
(eglCreateImageKHR returns EGL_NO_IMAGE_KHR for buffers, which were not
created using gbm_bo_create).

This behaviour was also tested on Qemu setup using
DRM_IOCTL_MODE_CREATE_DUMB call to create backing storage buffer.

---
Oleksii Moisieiev (3):
  xen/grant-table: save page_count on map and use if during async
    unmapping
  dma-buf: add dma buffer release notifier callback
  xen/grant-table: add new ioctls to map dmabuf to existing fd

 drivers/dma-buf/dma-buf.c   |  44 ++++
 drivers/xen/gntdev-common.h |   8 +-
 drivers/xen/gntdev-dmabuf.c | 416 +++++++++++++++++++++++++++++++++++-
 drivers/xen/gntdev-dmabuf.h |   7 +
 drivers/xen/gntdev.c        | 101 ++++++++-
 drivers/xen/grant-table.c   |  73 +++++--
 include/linux/dma-buf.h     |  15 ++
 include/uapi/xen/gntdev.h   |  62 ++++++
 include/xen/grant_table.h   |   8 +
 9 files changed, 703 insertions(+), 31 deletions(-)

--
2.25.1
Re: AW: [PATCH v1 0/3] Add ioctls to map grant refs on the external backing storage
Posted by Oleksii Moisieiev 1 year, 3 months ago
On 02.01.23 18:36, Koenig, Christian wrote:

[AMD Official Use Only - General]

Sorry for the messed up mail. We currently have mail problems here at AMD.

________________________________
Von: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com><mailto:Oleksii_Moisieiev@epam.com>
Gesendet: Montag, 2. Januar 2023 14:41
An: jgross@suse.com<mailto:jgross@suse.com> <jgross@suse.com><mailto:jgross@suse.com>
Cc: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com><mailto:Oleksii_Moisieiev@epam.com>; Stefano Stabellini <sstabellini@kernel.org><mailto:sstabellini@kernel.org>; Oleksandr Tyshchenko <Oleksandr_Tyshchenko@epam.com><mailto:Oleksandr_Tyshchenko@epam.com>; xen-devel@lists.xenproject.org<mailto:xen-devel@lists.xenproject.org> <xen-devel@lists.xenproject.org><mailto:xen-devel@lists.xenproject.org>; linux-kernel@vger.kernel.org<mailto:linux-kernel@vger.kernel.org> <linux-kernel@vger.kernel.org><mailto:linux-kernel@vger.kernel.org>; Sumit Semwal <sumit.semwal@linaro.org><mailto:sumit.semwal@linaro.org>; Koenig, Christian <Christian.Koenig@amd.com><mailto:Christian.Koenig@amd.com>; linux-media@vger.kernel.org<mailto:linux-media@vger.kernel.org> <linux-media@vger.kernel.org><mailto:linux-media@vger.kernel.org>; dri-devel@lists.freedesktop.org<mailto:dri-devel@lists.freedesktop.org> <dri-devel@lists.freedesktop.org><mailto:dri-devel@lists.freedesktop.org>; linaro-mm-sig@lists.linaro.org<mailto:linaro-mm-sig@lists.linaro.org> <linaro-mm-sig@lists.linaro.org><mailto:linaro-mm-sig@lists.linaro.org>
Betreff: [PATCH v1 0/3] Add ioctls to map grant refs on the external backing storage

Hello,

Let me introduce the new ioctls, which are intended to allow gntdev to
map scatter-gather table on top of the existing dmabuf, referenced by
file descriptor.

When using dma-buf exporter to create dma-buf with backing storage and
map it to the grant refs, provided from the domain, we've met a problem,
that several HW (i.MX8 gpu in our case) do not support external buffer
and requires backing storage to be created using it's native tools.
That's why new ioctls were added to be able to pass existing dma-buffer
fd as input parameter and use it as backing storage to export to refs.

This is a pretty big NAK from my side to this approach.

If you need to replace a file descriptor number local to your process then you can simply use dup2() from userspace.

If your intention here is to replace the backing store of the fd on all processes which currently have it open then please just completely forget that. This will *NEVER* ever work correctly.

Regards,
Christian.


Hello Cristian,


Thank you for the quick response.


My goal is to provide correct buffer for the interfaces, such as zwp_linux_dmabuf_v1_interface, so zero-copy

feature will work. My suggestion is to give a possibility to use some specific buffer as backing storage where caller

takes responsibility for the provided buffer to have the correct format.


In our case we are using these calls the following way:

1) Get grefs from another Domain (We're working on the virtualized system with different Domains

working as standalone VMs that are sharing resources);

2) Create buffer using gbm_bo_create and receive fd (i.MX8 requires egl api to be called for the buffer

allocation, or eglCreateImageKHR will return EGL_NO_IMAGE_KHR during param setting for zwp_linux_dmabuf);

3) Call for IOCTL_GNTDEV_DMABUF_MAP_REFS_TO_BUF to map grefs using fd as the backing storage;

4) Call for zwp_linux_dmabuf_v1_interface and use zero-copy feature with Wayland;

5) After work finished - call for IOCTL_GNTDEV_DMABUF_MAP_RELEASE to unmap grant refs;

6) Call gbm_bo_destroy to release allocated BO object;

7) Call for IOCTL_GNTDEV_DMABUF_MAP_WAIT_RELEASED to wait until map released completely

(This includes releasing grant refs on the Domain side).


I've tested my changes on IMX8QM board using gbm_bo_create to allocate buffer and

on QEMU setup using DRM_IOCTL_MODE_CREATE_DUMB for buffer allocation.

I can provide test applications I've used for testing purposes.


Best regards,

Oleksii.


Following calls were added:
IOCTL_GNTDEV_DMABUF_MAP_REFS_TO_BUF - map existing buffer as the backing
storage and export it to the provided grant refs;
IOCTL_GNTDEV_DMABUF_MAP_RELEASE - detach buffer from the grant table and
set notification to unmap grant refs before releasing the external
buffer. After this call the external buffer should be detroyed.
IOCTL_GNTDEV_DMABUF_MAP_WAIT_RELEASED - wait for timeout until buffer is
completely destroyed and gnt refs unmapped so domain could free grant
pages. Should be called after buffer was destoyed.

Our setup is based on IMX8QM board. We're trying to implement zero-copy
support for DomU graphics using Wayland zwp_linux_dmabuf_v1_interface
implementation.

For dma-buf exporter we used i.MX8 gpu native tools to create backing
storage grant-refs, received from DomU. Buffer for the backing storage was
allocated using gbm_bo_create call because gpu do not support external
buffer and requires backing storage to be created using it's native tools
(eglCreateImageKHR returns EGL_NO_IMAGE_KHR for buffers, which were not
created using gbm_bo_create).

This behaviour was also tested on Qemu setup using
DRM_IOCTL_MODE_CREATE_DUMB call to create backing storage buffer.

---
Oleksii Moisieiev (3):
  xen/grant-table: save page_count on map and use if during async
    unmapping
  dma-buf: add dma buffer release notifier callback
  xen/grant-table: add new ioctls to map dmabuf to existing fd

 drivers/dma-buf/dma-buf.c   |  44 ++++
 drivers/xen/gntdev-common.h |   8 +-
 drivers/xen/gntdev-dmabuf.c | 416 +++++++++++++++++++++++++++++++++++-
 drivers/xen/gntdev-dmabuf.h |   7 +
 drivers/xen/gntdev.c        | 101 ++++++++-
 drivers/xen/grant-table.c   |  73 +++++--
 include/linux/dma-buf.h     |  15 ++
 include/uapi/xen/gntdev.h   |  62 ++++++
 include/xen/grant_table.h   |   8 +
 9 files changed, 703 insertions(+), 31 deletions(-)

--
2.25.1