Re: [Xen-devel] [PATCH v2 9/9] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
On 06/07/2018 01:05 AM, Dongwon Kim wrote: On Wed, Jun 06, 2018 at 05:51:38PM -0400, Boris Ostrovsky wrote: On 06/06/2018 08:46 AM, Oleksandr Andrushchenko wrote: On 06/05/2018 01:36 AM, Boris Ostrovsky wrote: On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Allow creating grant device context for use by kernel modules which require functionality, provided by gntdev. Export symbols for dma-buf API provided by the module. Can you give an example of who'd be using these interfaces? There is no use-case at the moment I can think of, but hyper dma-buf [1], [2] I let Intel folks (CCed) to defend this patch as it was done primarily for them and I don't use it in any of my use-cases. So, from this POV it can be dropped, at least from this series. Yes, let's drop this until someone actually needs it. -boris I agree. We are working on re-architecturing hyper_dmabuf. We would use zcopy apis however, not sure if we are going to do it from kernel or from userspace. So please do not expose those for now. Ok, as we are all on the same page for that then I'll drop this patch for now -boris [1] https://patchwork.freedesktop.org/series/38207/ [2] https://patchwork.freedesktop.org/patch/204447/ ___ Xen-devel mailing list xen-de...@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 9/9] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
On 06/06/2018 08:46 AM, Oleksandr Andrushchenko wrote: > On 06/05/2018 01:36 AM, Boris Ostrovsky wrote: >> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko >>> >>> Allow creating grant device context for use by kernel modules which >>> require functionality, provided by gntdev. Export symbols for dma-buf >>> API provided by the module. >> Can you give an example of who'd be using these interfaces? > There is no use-case at the moment I can think of, but hyper dma-buf > [1], [2] > I let Intel folks (CCed) to defend this patch as it was done primarily > for them > and I don't use it in any of my use-cases. So, from this POV it can be > dropped, > at least from this series. Yes, let's drop this until someone actually needs it. -boris >> >> -boris >> > [1] https://patchwork.freedesktop.org/series/38207/ > [2] https://patchwork.freedesktop.org/patch/204447/ > > ___ > Xen-devel mailing list > xen-de...@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 9/9] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
On Wed, Jun 06, 2018 at 05:51:38PM -0400, Boris Ostrovsky wrote: > On 06/06/2018 08:46 AM, Oleksandr Andrushchenko wrote: > > On 06/05/2018 01:36 AM, Boris Ostrovsky wrote: > >> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > >>> From: Oleksandr Andrushchenko > >>> > >>> Allow creating grant device context for use by kernel modules which > >>> require functionality, provided by gntdev. Export symbols for dma-buf > >>> API provided by the module. > >> Can you give an example of who'd be using these interfaces? > > There is no use-case at the moment I can think of, but hyper dma-buf > > [1], [2] > > I let Intel folks (CCed) to defend this patch as it was done primarily > > for them > > and I don't use it in any of my use-cases. So, from this POV it can be > > dropped, > > at least from this series. > > > Yes, let's drop this until someone actually needs it. > > -boris I agree. We are working on re-architecturing hyper_dmabuf. We would use zcopy apis however, not sure if we are going to do it from kernel or from userspace. So please do not expose those for now. > > > >> > >> -boris > >> > > [1] https://patchwork.freedesktop.org/series/38207/ > > [2] https://patchwork.freedesktop.org/patch/204447/ > > > > ___ > > Xen-devel mailing list > > xen-de...@lists.xenproject.org > > https://lists.xenproject.org/mailman/listinfo/xen-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 9/9] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
On 06/05/2018 01:36 AM, Boris Ostrovsky wrote: On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Allow creating grant device context for use by kernel modules which require functionality, provided by gntdev. Export symbols for dma-buf API provided by the module. Can you give an example of who'd be using these interfaces? There is no use-case at the moment I can think of, but hyper dma-buf [1], [2] I let Intel folks (CCed) to defend this patch as it was done primarily for them and I don't use it in any of my use-cases. So, from this POV it can be dropped, at least from this series. -boris [1] https://patchwork.freedesktop.org/series/38207/ [2] https://patchwork.freedesktop.org/patch/204447/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 9/9] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Allow creating grant device context for use by kernel modules which > require functionality, provided by gntdev. Export symbols for dma-buf > API provided by the module. Can you give an example of who'd be using these interfaces? -boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 9/9] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
From: Oleksandr Andrushchenko
Allow creating grant device context for use by kernel modules which
require functionality, provided by gntdev. Export symbols for dma-buf
API provided by the module.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev-dmabuf.c | 6 +++
drivers/xen/gntdev.c| 92 +++--
include/xen/grant_dev.h | 37 +++
3 files changed, 101 insertions(+), 34 deletions(-)
create mode 100644 include/xen/grant_dev.h
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index b5569a220f03..3890ac9dfab6 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -196,6 +196,7 @@ int gntdev_dmabuf_exp_wait_released(struct
gntdev_dmabuf_priv *priv, int fd,
dmabuf_exp_wait_obj_free(priv, obj);
return ret;
}
+EXPORT_SYMBOL_GPL(gntdev_dmabuf_exp_wait_released);
/* -- */
/* DMA buffer export support. */
@@ -621,6 +622,7 @@ gntdev_dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv,
struct device *dev,
dma_buf_put(dma_buf);
return ret;
}
+EXPORT_SYMBOL_GPL(gntdev_dmabuf_imp_to_refs);
u32 *gntdev_dmabuf_imp_get_refs(struct gntdev_dmabuf *gntdev_dmabuf)
{
@@ -629,6 +631,7 @@ u32 *gntdev_dmabuf_imp_get_refs(struct gntdev_dmabuf
*gntdev_dmabuf)
return NULL;
}
+EXPORT_SYMBOL_GPL(gntdev_dmabuf_imp_get_refs);
/*
* Find the hyper dma-buf by its file descriptor and remove
@@ -678,6 +681,7 @@ int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv
*priv, u32 fd)
dmabuf_imp_free_storage(gntdev_dmabuf);
return 0;
}
+EXPORT_SYMBOL_GPL(gntdev_dmabuf_imp_release);
struct gntdev_dmabuf_priv *gntdev_dmabuf_init(void)
{
@@ -694,8 +698,10 @@ struct gntdev_dmabuf_priv *gntdev_dmabuf_init(void)
return priv;
}
+EXPORT_SYMBOL_GPL(gntdev_dmabuf_init);
void gntdev_dmabuf_fini(struct gntdev_dmabuf_priv *priv)
{
kfree(priv);
}
+EXPORT_SYMBOL_GPL(gntdev_dmabuf_fini);
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index cf255d45f20f..63902f5298c9 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -621,14 +621,37 @@ static const struct mmu_notifier_ops gntdev_mmu_ops = {
/* -- */
-static int gntdev_open(struct inode *inode, struct file *flip)
+void gntdev_free_context(struct gntdev_priv *priv)
+{
+ struct grant_map *map;
+
+ pr_debug("priv %p\n", priv);
+
+ mutex_lock(&priv->lock);
+ while (!list_empty(&priv->maps)) {
+ map = list_entry(priv->maps.next, struct grant_map, next);
+ list_del(&map->next);
+ gntdev_put_map(NULL /* already removed */, map);
+ }
+ WARN_ON(!list_empty(&priv->freeable_maps));
+
+ mutex_unlock(&priv->lock);
+
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+ gntdev_dmabuf_fini(priv->dmabuf_priv);
+#endif
+
+ kfree(priv);
+}
+EXPORT_SYMBOL_GPL(gntdev_free_context);
+
+struct gntdev_priv *gntdev_alloc_context(struct device *dev)
{
struct gntdev_priv *priv;
- int ret = 0;
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
INIT_LIST_HEAD(&priv->maps);
INIT_LIST_HEAD(&priv->freeable_maps);
@@ -637,12 +660,40 @@ static int gntdev_open(struct inode *inode, struct file
*flip)
#ifdef CONFIG_XEN_GNTDEV_DMABUF
priv->dmabuf_priv = gntdev_dmabuf_init();
if (IS_ERR(priv->dmabuf_priv)) {
- ret = PTR_ERR(priv->dmabuf_priv);
+ struct gntdev_priv *ret;
+
+ ret = ERR_CAST(priv->dmabuf_priv);
kfree(priv);
return ret;
}
#endif
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ priv->dma_dev = dev;
+
+ /*
+* The device is not spawn from a device tree, so arch_setup_dma_ops
+* is not called, thus leaving the device with dummy DMA ops.
+* Fix this call of_dma_configure() with a NULL node to set
+* default DMA ops.
+*/
+ of_dma_configure(priv->dma_dev, NULL);
+#endif
+ pr_debug("priv %p\n", priv);
+
+ return priv;
+}
+EXPORT_SYMBOL_GPL(gntdev_alloc_context);
+
+static int gntdev_open(struct inode *inode, struct file *flip)
+{
+ struct gntdev_priv *priv;
+ int ret = 0;
+
+ priv = gntdev_alloc_context(gntdev_miscdev.this_device);
+ if (IS_ERR(priv))
+ return PTR_ERR(priv);
+
if (use_ptemod) {
priv->mm = get_task_mm(current);
if (!priv->mm) {
@@ -655,23 +706,11 @@ static int gntdev_open(struct inode *inode, struct file
*flip)
}
if (ret) {
- kfree(priv);
+ gntdev_free_context(priv);
return ret;
}
flip->private_data = priv;
