Re: [PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI
On 06/08/2018 01:26 AM, Boris Ostrovsky wrote: On 06/07/2018 03:17 AM, Oleksandr Andrushchenko wrote: On 06/07/2018 12:32 AM, Boris Ostrovsky wrote: On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote: On 06/04/2018 11:49 PM, Boris Ostrovsky wrote: diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 9813fc440c70..7d58dfb3e5e8 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c ... +#ifdef CONFIG_XEN_GNTDEV_DMABUF This code belongs in gntdev-dmabuf.c. The reason I have this code here is that it is heavily tied to gntdev's internal functionality, e.g. map/unmap. I do not want to extend gntdev's API, so gntdev-dmabuf can access these. What is more dma-buf doesn't need to know about maps done by gntdev as there is no use of that information in gntdev-dmabuf. So, it seems more naturally to have dma-buf's related map/unmap code where it is: in gntdev. Sorry, I don't follow. Why would this require extending the API? It's just moving routines to a different file that is linked to the same module. I do understand your intention here and tried to avoid dma-buf related code in gntdev.c as much as possible. So, let me explain my decision in more detail. There are 2 use-cases we have: dma-buf import and export. While importing a dma-buf all the dma-buf related functionality can easily be kept inside gntdev-dmabuf.c w/o any issue as all we need from gntdev.c is dev, dma_buf_fd, count and domid for that. But in case of dma-buf export we need to: 1. struct grant_map *map = gntdev_alloc_map(priv, count, dmabuf_flags); 2. gntdev_add_map(priv, map); 3. Set map->flags 4. ret = map_grant_pages(map); 5. And only now we are all set to export the new dma-buf from *map->pages* So, until 5) we use private gtndev.c's API not exported to outside world: a. struct grant_map b. static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count, int dma_flags) c. static void gntdev_add_map(struct gntdev_priv *priv, struct grant_map *add) d. static int map_grant_pages(struct grant_map *map) Thus, all the above cannot be accessed from gntdev-dmabuf.c This is why I say that gntdev.c's API will need to be extended to provide the above a-d if we want all dma-buf export code to leave in gntdev-dmabuf.c. I still don't understand why you feel this would be extending the API. These routines and the struct can be declared in local header file and this header file will not be visible to anyone but gntdev.c and gntdev-dmabuf.c. Ok, this is what I meant: I will need to move private structures and some function prototypes from gntdev.c into a header file, thus extending its API: before the header nothing were exposed. Sorry for not being clear here. You can, for example, put this into gntdev-dmabuf.h (and then rename it to something else, like gntdev-common.h). Sure, I will move all I need into that shared header But that doesn't seem good to me and what is more a-d are really gntdev.c's functionality, not dma-buf's which only needs pages and doesn't really care from where those come. That was the reason I partitioned export into 2 chunks: gntdev + gntdev-dmabuf. You might also ask why importing side does Xen related things (granting references+) in gntdev-dmabuf, not gntdev so it is consistent with the dma-buf exporter? This is because importer uses grant-table's API which seems to be not natural for gntdev.c, so it can leave in gntdev-dmabuf.c which has a use-case for that, while gntdev remains the same. Yet another reason why this code should be moved: importing and exporting functionalities logically belong together. The fat that they are implemented using different methods is not relevant IMO. If you have code which is under ifdef CONFIG_GNTDEV_DMABUF and you have file called gntdev-dmabuf.c it sort of implies that this code should live in that file (unless that code is intertwined with other code, which is not the case here). Ok, will move as discussed above -boris Thank you, Oleksandr Since this is under CONFIG_XEN_GNTDEV_DMABUF then why shouldn't it be in gntdev-dmabuf.c? In my view that's the file where all dma-related "stuff" lives. Agree, but IMO grant_map stuff for dma-buf importer is right in its place in gntdev.c and all the rest of dma-buf specifics live in gntdev-dmabuf.c as they should -boris -boris Thank you, Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI
On 06/07/2018 03:17 AM, Oleksandr Andrushchenko wrote: > On 06/07/2018 12:32 AM, Boris Ostrovsky wrote: >> On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote: >>> On 06/04/2018 11:49 PM, Boris Ostrovsky wrote: > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c > index 9813fc440c70..7d58dfb3e5e8 100644 > --- a/drivers/xen/gntdev.c > +++ b/drivers/xen/gntdev.c ... > +#ifdef CONFIG_XEN_GNTDEV_DMABUF This code belongs in gntdev-dmabuf.c. >>> The reason I have this code here is that it is heavily >>> tied to gntdev's internal functionality, e.g. map/unmap. >>> I do not want to extend gntdev's API, so gntdev-dmabuf can >>> access these. What is more dma-buf doesn't need to know about >>> maps done by gntdev as there is no use of that information >>> in gntdev-dmabuf. So, it seems more naturally to have >>> dma-buf's related map/unmap code where it is: in gntdev. >> Sorry, I don't follow. Why would this require extending the API? It's >> just moving routines to a different file that is linked to the same >> module. > I do understand your intention here and tried to avoid dma-buf > related code in gntdev.c as much as possible. So, let me explain > my decision in more detail. > > There are 2 use-cases we have: dma-buf import and export. > > While importing a dma-buf all the dma-buf related functionality can > easily be kept inside gntdev-dmabuf.c w/o any issue as all we need > from gntdev.c is dev, dma_buf_fd, count and domid for that. > > But in case of dma-buf export we need to: > 1. struct grant_map *map = gntdev_alloc_map(priv, count, dmabuf_flags); > 2. gntdev_add_map(priv, map); > 3. Set map->flags > 4. ret = map_grant_pages(map); > 5. And only now we are all set to export the new dma-buf from > *map->pages* > > So, until 5) we use private gtndev.c's API not exported to outside world: > a. struct grant_map > b. static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, > int count, > int dma_flags) > c. static void gntdev_add_map(struct gntdev_priv *priv, struct > grant_map *add) > d. static int map_grant_pages(struct grant_map *map) > > Thus, all the above cannot be accessed from gntdev-dmabuf.c > This is why I say that gntdev.c's API will need to be extended to > provide the above > a-d if we want all dma-buf export code to leave in gntdev-dmabuf.c. I still don't understand why you feel this would be extending the API. These routines and the struct can be declared in local header file and this header file will not be visible to anyone but gntdev.c and gntdev-dmabuf.c. You can, for example, put this into gntdev-dmabuf.h (and then rename it to something else, like gntdev-common.h). > But that doesn't seem good to me and what is more a-d are really > gntdev.c's > functionality, not dma-buf's which only needs pages and doesn't really > care from > where those come. > That was the reason I partitioned export into 2 chunks: gntdev + > gntdev-dmabuf. > > You might also ask why importing side does Xen related things > (granting references+) > in gntdev-dmabuf, not gntdev so it is consistent with the dma-buf > exporter? > This is because importer uses grant-table's API which seems to be not > natural for gntdev.c, > so it can leave in gntdev-dmabuf.c which has a use-case for that, > while gntdev > remains the same. Yet another reason why this code should be moved: importing and exporting functionalities logically belong together. The fat that they are implemented using different methods is not relevant IMO. If you have code which is under ifdef CONFIG_GNTDEV_DMABUF and you have file called gntdev-dmabuf.c it sort of implies that this code should live in that file (unless that code is intertwined with other code, which is not the case here). -boris >> Since this is under CONFIG_XEN_GNTDEV_DMABUF then why shouldn't it be in >> gntdev-dmabuf.c? In my view that's the file where all dma-related >> "stuff" lives. > Agree, but IMO grant_map stuff for dma-buf importer is right in its > place in gntdev.c > and all the rest of dma-buf specifics live in gntdev-dmabuf.c as they > should >> >> -boris >> >> >> -boris >> > Thank you, > Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI
On 06/07/2018 12:32 AM, Boris Ostrovsky wrote:
On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote:
On 06/04/2018 11:49 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
+struct gntdev_dmabuf_export_args {
+ int dummy;
+};
Please define the full structure (at least what you have in the next
patch) here.
Ok, will define what I have in the next patch, but won't
initialize anything until the next patch. Will this work for you?
Sure, I just didn't see the need for the dummy argument that you remove
later.
Ok
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 9813fc440c70..7d58dfb3e5e8 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
...
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
This code belongs in gntdev-dmabuf.c.
The reason I have this code here is that it is heavily
tied to gntdev's internal functionality, e.g. map/unmap.
I do not want to extend gntdev's API, so gntdev-dmabuf can
access these. What is more dma-buf doesn't need to know about
maps done by gntdev as there is no use of that information
in gntdev-dmabuf. So, it seems more naturally to have
dma-buf's related map/unmap code where it is: in gntdev.
Sorry, I don't follow. Why would this require extending the API? It's
just moving routines to a different file that is linked to the same module.
I do understand your intention here and tried to avoid dma-buf
related code in gntdev.c as much as possible. So, let me explain
my decision in more detail.
There are 2 use-cases we have: dma-buf import and export.
While importing a dma-buf all the dma-buf related functionality can
easily be kept inside gntdev-dmabuf.c w/o any issue as all we need
from gntdev.c is dev, dma_buf_fd, count and domid for that.
But in case of dma-buf export we need to:
1. struct grant_map *map = gntdev_alloc_map(priv, count, dmabuf_flags);
2. gntdev_add_map(priv, map);
3. Set map->flags
4. ret = map_grant_pages(map);
5. And only now we are all set to export the new dma-buf from *map->pages*
So, until 5) we use private gtndev.c's API not exported to outside world:
a. struct grant_map
b. static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv,
int count,
int dma_flags)
c. static void gntdev_add_map(struct gntdev_priv *priv, struct grant_map
*add)
d. static int map_grant_pages(struct grant_map *map)
Thus, all the above cannot be accessed from gntdev-dmabuf.c
This is why I say that gntdev.c's API will need to be extended to
provide the above
a-d if we want all dma-buf export code to leave in gntdev-dmabuf.c.
But that doesn't seem good to me and what is more a-d are really gntdev.c's
functionality, not dma-buf's which only needs pages and doesn't really
care from
where those come.
That was the reason I partitioned export into 2 chunks: gntdev +
gntdev-dmabuf.
You might also ask why importing side does Xen related things (granting
references+)
in gntdev-dmabuf, not gntdev so it is consistent with the dma-buf exporter?
This is because importer uses grant-table's API which seems to be not
natural for gntdev.c,
so it can leave in gntdev-dmabuf.c which has a use-case for that, while
gntdev
remains the same.
Since this is under CONFIG_XEN_GNTDEV_DMABUF then why shouldn't it be in
gntdev-dmabuf.c? In my view that's the file where all dma-related
"stuff" lives.
Agree, but IMO grant_map stuff for dma-buf importer is right in its
place in gntdev.c
and all the rest of dma-buf specifics live in gntdev-dmabuf.c as they should
-boris
-boris
Thank you,
Oleksandr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI
On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote:
> On 06/04/2018 11:49 PM, Boris Ostrovsky wrote:
>> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
>> +struct gntdev_dmabuf_export_args {
>> + int dummy;
>> +};
>>
>> Please define the full structure (at least what you have in the next
>> patch) here.
> Ok, will define what I have in the next patch, but won't
> initialize anything until the next patch. Will this work for you?
Sure, I just didn't see the need for the dummy argument that you remove
later.
>>
>>> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
>>> index 9813fc440c70..7d58dfb3e5e8 100644
>>> --- a/drivers/xen/gntdev.c
>>> +++ b/drivers/xen/gntdev.c
>> ...
>>
>>> +#ifdef CONFIG_XEN_GNTDEV_DMABUF
>> This code belongs in gntdev-dmabuf.c.
> The reason I have this code here is that it is heavily
> tied to gntdev's internal functionality, e.g. map/unmap.
> I do not want to extend gntdev's API, so gntdev-dmabuf can
> access these. What is more dma-buf doesn't need to know about
> maps done by gntdev as there is no use of that information
> in gntdev-dmabuf. So, it seems more naturally to have
> dma-buf's related map/unmap code where it is: in gntdev.
Sorry, I don't follow. Why would this require extending the API? It's
just moving routines to a different file that is linked to the same module.
Since this is under CONFIG_XEN_GNTDEV_DMABUF then why shouldn't it be in
gntdev-dmabuf.c? In my view that's the file where all dma-related
"stuff" lives.
-boris
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI
On 06/04/2018 11:49 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf implementation. With this extension grant
references to the pages of an imported dma-buf can be exported
for other domain use and grant references coming from a foreign
domain can be converted into a local dma-buf for local export.
Implement basic initialization and stubs for Xen DMA buffers'
support.
It would be very helpful if people advocating for this interface
reviewed it as well.
I would also love to see their comments here ;)
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/Kconfig | 10 +++
drivers/xen/Makefile| 1 +
drivers/xen/gntdev-dmabuf.c | 75 +++
drivers/xen/gntdev-dmabuf.h | 41 +++
drivers/xen/gntdev.c| 142
include/uapi/xen/gntdev.h | 91 +++
6 files changed, 360 insertions(+)
create mode 100644 drivers/xen/gntdev-dmabuf.c
create mode 100644 drivers/xen/gntdev-dmabuf.h
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 39536ddfbce4..52d64e4b6b81 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -152,6 +152,16 @@ config XEN_GNTDEV
help
Allows userspace processes to use grants.
+config XEN_GNTDEV_DMABUF
+ bool "Add support for dma-buf grant access device driver extension"
+ depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC && DMA_SHARED_BUFFER
Is there a reason to have XEN_GRANT_DMA_ALLOC without XEN_GNTDEV_DMABUF?
One can use grant-table's DMA API without using dma-buf at all, e.g.
dma-buf is sort of functionality on top of DMA allocated memory.
We have a use-case for a driver domain (guest domain in fact)
backed with IOMMU and still requiring allocations created as
contiguous/DMA memory, so those buffers can be passed around to
drivers expecting DMA-only buffers.
So, IMO this is a valid use-case "to have XEN_GRANT_DMA_ALLOC
without XEN_GNTDEV_DMABUF"
+ help
+ Allows userspace processes and kernel modules to use Xen backed
+ dma-buf implementation. With this extension grant references to
+ the pages of an imported dma-buf can be exported for other domain
+ use and grant references coming from a foreign domain can be
+ converted into a local dma-buf for local export.
+
config XEN_GRANT_DEV_ALLOC
tristate "User-space grant reference allocator driver"
depends on XEN
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 3c87b0c3aca6..33afb7b2b227 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -41,5 +41,6 @@ obj-$(CONFIG_XEN_PVCALLS_BACKEND) += pvcalls-back.o
obj-$(CONFIG_XEN_PVCALLS_FRONTEND)+= pvcalls-front.o
xen-evtchn-y := evtchn.o
xen-gntdev-y := gntdev.o
+xen-gntdev-$(CONFIG_XEN_GNTDEV_DMABUF) += gntdev-dmabuf.o
xen-gntalloc-y:= gntalloc.o
xen-privcmd-y := privcmd.o
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
new file mode 100644
index ..6bedd1387bd9
--- /dev/null
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Xen dma-buf functionality for gntdev.
+ *
+ * Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
+ */
+
+#include
+
+#include "gntdev-dmabuf.h"
+
+struct gntdev_dmabuf_priv {
+ int dummy;
+};
+
+/* -- */
+/* DMA buffer export support. */
+/* -- */
+
+/* -- */
+/* Implementation of wait for exported DMA buffer to be released. */
+/* -- */
Why this comment style?
Just a copy-paste from gntdev, will change to usual /*..*/
+
+int gntdev_dmabuf_exp_wait_released(struct gntdev_dmabuf_priv *priv, int fd,
+ int wait_to_ms)
+{
+ return -EINVAL;
+}
+
+/* -- */
+/* DMA buffer export support. */
+/* -- */
+
+int gntdev_dmabuf_exp_from_pages(struct gntdev_dmabuf_export_args *args)
+{
+ return -EINVAL;
+}
+
+/* -- */
+/* DMA buffer import support. */
+/* -- */
+
+struct gntdev_dmabuf *
+gntdev_dmabuf_imp_to_refs(struct
Re: [PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add UAPI and IOCTLs for dma-buf grant device driver extension:
> the extension allows userspace processes and kernel modules to
> use Xen backed dma-buf implementation. With this extension grant
> references to the pages of an imported dma-buf can be exported
> for other domain use and grant references coming from a foreign
> domain can be converted into a local dma-buf for local export.
> Implement basic initialization and stubs for Xen DMA buffers'
> support.
It would be very helpful if people advocating for this interface
reviewed it as well.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/Kconfig | 10 +++
> drivers/xen/Makefile| 1 +
> drivers/xen/gntdev-dmabuf.c | 75 +++
> drivers/xen/gntdev-dmabuf.h | 41 +++
> drivers/xen/gntdev.c| 142
> include/uapi/xen/gntdev.h | 91 +++
> 6 files changed, 360 insertions(+)
> create mode 100644 drivers/xen/gntdev-dmabuf.c
> create mode 100644 drivers/xen/gntdev-dmabuf.h
>
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 39536ddfbce4..52d64e4b6b81 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -152,6 +152,16 @@ config XEN_GNTDEV
> help
> Allows userspace processes to use grants.
>
> +config XEN_GNTDEV_DMABUF
> + bool "Add support for dma-buf grant access device driver extension"
> + depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC && DMA_SHARED_BUFFER
Is there a reason to have XEN_GRANT_DMA_ALLOC without XEN_GNTDEV_DMABUF?
> + help
> + Allows userspace processes and kernel modules to use Xen backed
> + dma-buf implementation. With this extension grant references to
> + the pages of an imported dma-buf can be exported for other domain
> + use and grant references coming from a foreign domain can be
> + converted into a local dma-buf for local export.
> +
> config XEN_GRANT_DEV_ALLOC
> tristate "User-space grant reference allocator driver"
> depends on XEN
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 3c87b0c3aca6..33afb7b2b227 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -41,5 +41,6 @@ obj-$(CONFIG_XEN_PVCALLS_BACKEND) += pvcalls-back.o
> obj-$(CONFIG_XEN_PVCALLS_FRONTEND) += pvcalls-front.o
> xen-evtchn-y := evtchn.o
> xen-gntdev-y := gntdev.o
> +xen-gntdev-$(CONFIG_XEN_GNTDEV_DMABUF) += gntdev-dmabuf.o
> xen-gntalloc-y := gntalloc.o
> xen-privcmd-y:= privcmd.o
> diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
> new file mode 100644
> index ..6bedd1387bd9
> --- /dev/null
> +++ b/drivers/xen/gntdev-dmabuf.c
> @@ -0,0 +1,75 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Xen dma-buf functionality for gntdev.
> + *
> + * Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
> + */
> +
> +#include
> +
> +#include "gntdev-dmabuf.h"
> +
> +struct gntdev_dmabuf_priv {
> + int dummy;
> +};
> +
> +/* -- */
> +/* DMA buffer export support. */
> +/* -- */
> +
> +/* -- */
> +/* Implementation of wait for exported DMA buffer to be released. */
> +/* -- */
Why this comment style?
> +
> +int gntdev_dmabuf_exp_wait_released(struct gntdev_dmabuf_priv *priv, int fd,
> + int wait_to_ms)
> +{
> + return -EINVAL;
> +}
> +
> +/* -- */
> +/* DMA buffer export support. */
> +/* -- */
> +
> +int gntdev_dmabuf_exp_from_pages(struct gntdev_dmabuf_export_args *args)
> +{
> + return -EINVAL;
> +}
> +
> +/* -- */
> +/* DMA buffer import support. */
> +/* -- */
> +
> +struct gntdev_dmabuf *
> +gntdev_dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct device
> *dev,
> + int fd, int count, int domid)
> +{
> + return ERR_PTR(-ENOMEM);
> +}
> +
> +u32 *gntdev_dmabuf_imp_get_refs(struct gntdev_dmabuf *gntdev_dmabuf)
> +{
> + return NULL;
> +}
> +
> +int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32 fd)
> +{
> + return -EINVAL;
> +}
> +
> +struct gntdev_dmabuf_priv *gntdev_dmabuf_init(void)
> +{
> + struct
[PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf implementation. With this extension grant
references to the pages of an imported dma-buf can be exported
for other domain use and grant references coming from a foreign
domain can be converted into a local dma-buf for local export.
Implement basic initialization and stubs for Xen DMA buffers'
support.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/Kconfig | 10 +++
drivers/xen/Makefile| 1 +
drivers/xen/gntdev-dmabuf.c | 75 +++
drivers/xen/gntdev-dmabuf.h | 41 +++
drivers/xen/gntdev.c| 142
include/uapi/xen/gntdev.h | 91 +++
6 files changed, 360 insertions(+)
create mode 100644 drivers/xen/gntdev-dmabuf.c
create mode 100644 drivers/xen/gntdev-dmabuf.h
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 39536ddfbce4..52d64e4b6b81 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -152,6 +152,16 @@ config XEN_GNTDEV
help
Allows userspace processes to use grants.
+config XEN_GNTDEV_DMABUF
+ bool "Add support for dma-buf grant access device driver extension"
+ depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC && DMA_SHARED_BUFFER
+ help
+ Allows userspace processes and kernel modules to use Xen backed
+ dma-buf implementation. With this extension grant references to
+ the pages of an imported dma-buf can be exported for other domain
+ use and grant references coming from a foreign domain can be
+ converted into a local dma-buf for local export.
+
config XEN_GRANT_DEV_ALLOC
tristate "User-space grant reference allocator driver"
depends on XEN
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 3c87b0c3aca6..33afb7b2b227 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -41,5 +41,6 @@ obj-$(CONFIG_XEN_PVCALLS_BACKEND) += pvcalls-back.o
obj-$(CONFIG_XEN_PVCALLS_FRONTEND) += pvcalls-front.o
xen-evtchn-y := evtchn.o
xen-gntdev-y := gntdev.o
+xen-gntdev-$(CONFIG_XEN_GNTDEV_DMABUF) += gntdev-dmabuf.o
xen-gntalloc-y := gntalloc.o
xen-privcmd-y := privcmd.o
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
new file mode 100644
index ..6bedd1387bd9
--- /dev/null
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Xen dma-buf functionality for gntdev.
+ *
+ * Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
+ */
+
+#include
+
+#include "gntdev-dmabuf.h"
+
+struct gntdev_dmabuf_priv {
+ int dummy;
+};
+
+/* -- */
+/* DMA buffer export support. */
+/* -- */
+
+/* -- */
+/* Implementation of wait for exported DMA buffer to be released. */
+/* -- */
+
+int gntdev_dmabuf_exp_wait_released(struct gntdev_dmabuf_priv *priv, int fd,
+ int wait_to_ms)
+{
+ return -EINVAL;
+}
+
+/* -- */
+/* DMA buffer export support. */
+/* -- */
+
+int gntdev_dmabuf_exp_from_pages(struct gntdev_dmabuf_export_args *args)
+{
+ return -EINVAL;
+}
+
+/* -- */
+/* DMA buffer import support. */
+/* -- */
+
+struct gntdev_dmabuf *
+gntdev_dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct device *dev,
+ int fd, int count, int domid)
+{
+ return ERR_PTR(-ENOMEM);
+}
+
+u32 *gntdev_dmabuf_imp_get_refs(struct gntdev_dmabuf *gntdev_dmabuf)
+{
+ return NULL;
+}
+
+int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32 fd)
+{
+ return -EINVAL;
+}
+
+struct gntdev_dmabuf_priv *gntdev_dmabuf_init(void)
+{
+ struct gntdev_dmabuf_priv *priv;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return ERR_PTR(-ENOMEM);
+
+ return priv;
+}
+
+void gntdev_dmabuf_fini(struct gntdev_dmabuf_priv *priv)
+{
+ kfree(priv);
+}
diff --git a/drivers/xen/gntdev-dmabuf.h b/drivers/xen/gntdev-dmabuf.h
new file mode 100644
index ..040b2de904ac
--- /dev/null
+++ b/drivers/xen/gntdev-dmabuf.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier:
