* [PATCH v3 0/4] Support virtio cross-device resources @ 2020-03-11 11:20 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: Daniel Vetter, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Stevens, linux-kernel, dri-devel, virtualization, linux-media, linaro-mm-sig, virtio-dev This patchset implements the current proposal for virtio cross-device resource sharing [1], with minor changes based on recent comments. It is expected that this will be used to import virtio resources into the virtio-video driver currently under discussion [2]. This patchset adds a new hook to dma-buf, for querying the dma-buf's underlying virtio UUID. This hook is then plumbed through DRM PRIME buffers, and finally implemented in virtgpu. [1] https://markmail.org/thread/jsaoqy7phrqdcpqu [2] https://markmail.org/thread/p5d3k566srtdtute v2 -> v3 changes: - Remove ifdefs. - Simplify virtgpu_gem_prime_export as it can only be called once. - Use virtio_gpu_vbuffer's objs field instead of abusing data_buf. David Stevens (4): dma-buf: add support for virtio exported objects drm/prime: add support for virtio exported objects virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature drm/virtio: Support virtgpu exported resources drivers/dma-buf/dma-buf.c | 12 ++++++ drivers/gpu/drm/drm_prime.c | 23 +++++++++++ drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++ drivers/gpu/drm/virtio/virtgpu_drv.h | 18 +++++++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++ drivers/gpu/drm/virtio/virtgpu_prime.c | 41 +++++++++++++++++-- drivers/gpu/drm/virtio/virtgpu_vq.c | 55 ++++++++++++++++++++++++++ include/drm/drm_drv.h | 10 +++++ include/linux/dma-buf.h | 18 +++++++++ include/uapi/linux/virtio_gpu.h | 19 +++++++++ 10 files changed, 200 insertions(+), 3 deletions(-) -- 2.25.1.481.gfbce0eb801-goog ^ permalink raw reply [flat|nested] 71+ messages in thread
* [virtio-dev] [PATCH v3 0/4] Support virtio cross-device resources @ 2020-03-11 11:20 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: Daniel Vetter, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Stevens, linux-kernel, dri-devel, virtualization, linux-media, linaro-mm-sig, virtio-dev This patchset implements the current proposal for virtio cross-device resource sharing [1], with minor changes based on recent comments. It is expected that this will be used to import virtio resources into the virtio-video driver currently under discussion [2]. This patchset adds a new hook to dma-buf, for querying the dma-buf's underlying virtio UUID. This hook is then plumbed through DRM PRIME buffers, and finally implemented in virtgpu. [1] https://markmail.org/thread/jsaoqy7phrqdcpqu [2] https://markmail.org/thread/p5d3k566srtdtute v2 -> v3 changes: - Remove ifdefs. - Simplify virtgpu_gem_prime_export as it can only be called once. - Use virtio_gpu_vbuffer's objs field instead of abusing data_buf. David Stevens (4): dma-buf: add support for virtio exported objects drm/prime: add support for virtio exported objects virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature drm/virtio: Support virtgpu exported resources drivers/dma-buf/dma-buf.c | 12 ++++++ drivers/gpu/drm/drm_prime.c | 23 +++++++++++ drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++ drivers/gpu/drm/virtio/virtgpu_drv.h | 18 +++++++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++ drivers/gpu/drm/virtio/virtgpu_prime.c | 41 +++++++++++++++++-- drivers/gpu/drm/virtio/virtgpu_vq.c | 55 ++++++++++++++++++++++++++ include/drm/drm_drv.h | 10 +++++ include/linux/dma-buf.h | 18 +++++++++ include/uapi/linux/virtio_gpu.h | 19 +++++++++ 10 files changed, 200 insertions(+), 3 deletions(-) -- 2.25.1.481.gfbce0eb801-goog --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply [flat|nested] 71+ messages in thread
* [PATCH v3 0/4] Support virtio cross-device resources @ 2020-03-11 11:20 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: dri-devel, virtio-dev, Thomas Zimmermann, Michael S . Tsirkin, Jason Wang, linux-kernel, virtualization, linaro-mm-sig, David Stevens, linux-media This patchset implements the current proposal for virtio cross-device resource sharing [1], with minor changes based on recent comments. It is expected that this will be used to import virtio resources into the virtio-video driver currently under discussion [2]. This patchset adds a new hook to dma-buf, for querying the dma-buf's underlying virtio UUID. This hook is then plumbed through DRM PRIME buffers, and finally implemented in virtgpu. [1] https://markmail.org/thread/jsaoqy7phrqdcpqu [2] https://markmail.org/thread/p5d3k566srtdtute v2 -> v3 changes: - Remove ifdefs. - Simplify virtgpu_gem_prime_export as it can only be called once. - Use virtio_gpu_vbuffer's objs field instead of abusing data_buf. David Stevens (4): dma-buf: add support for virtio exported objects drm/prime: add support for virtio exported objects virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature drm/virtio: Support virtgpu exported resources drivers/dma-buf/dma-buf.c | 12 ++++++ drivers/gpu/drm/drm_prime.c | 23 +++++++++++ drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++ drivers/gpu/drm/virtio/virtgpu_drv.h | 18 +++++++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++ drivers/gpu/drm/virtio/virtgpu_prime.c | 41 +++++++++++++++++-- drivers/gpu/drm/virtio/virtgpu_vq.c | 55 ++++++++++++++++++++++++++ include/drm/drm_drv.h | 10 +++++ include/linux/dma-buf.h | 18 +++++++++ include/uapi/linux/virtio_gpu.h | 19 +++++++++ 10 files changed, 200 insertions(+), 3 deletions(-) -- 2.25.1.481.gfbce0eb801-goog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* [PATCH v3 1/4] dma-buf: add support for virtio exported objects 2020-03-11 11:20 ` David Stevens (?) @ 2020-03-11 11:20 ` David Stevens -1 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: Daniel Vetter, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Stevens, linux-kernel, dri-devel, virtualization, linux-media, linaro-mm-sig, virtio-dev This change adds a new dma-buf operation that allows dma-bufs to be used by virtio drivers to share exported objects. The new operation allows the importing driver to query the exporting driver for the UUID which identifies the underlying exported object. Signed-off-by: David Stevens <stevensd@chromium.org> --- drivers/dma-buf/dma-buf.c | 12 ++++++++++++ include/linux/dma-buf.h | 18 ++++++++++++++++++ 2 files changed, 30 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..fa5210ba6aaa 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1158,6 +1158,18 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) } EXPORT_SYMBOL_GPL(dma_buf_vunmap); +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid) +{ + if (WARN_ON(!dmabuf) || !uuid) + return -EINVAL; + + if (!dmabuf->ops->get_uuid) + return -ENODEV; + + return dmabuf->ops->get_uuid(dmabuf, uuid); +} +EXPORT_SYMBOL_GPL(dma_buf_get_uuid); + #ifdef CONFIG_DEBUG_FS static int dma_buf_debug_show(struct seq_file *s, void *unused) { diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index abf5459a5b9d..00758523597d 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -251,6 +251,21 @@ struct dma_buf_ops { void *(*vmap)(struct dma_buf *); void (*vunmap)(struct dma_buf *, void *vaddr); + + /** + * @get_uuid + * + * This is called by dma_buf_get_uuid to get the UUID which identifies + * the buffer to virtio devices. + * + * This callback is optional. + * + * Returns: + * + * 0 on success or a negative error code on failure. On success uuid + * will be populated with the buffer's UUID. + */ + int (*get_uuid)(struct dma_buf *dmabuf, uuid_t *uuid); }; /** @@ -444,4 +459,7 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, unsigned long); void *dma_buf_vmap(struct dma_buf *); void dma_buf_vunmap(struct dma_buf *, void *vaddr); + +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid); + #endif /* __DMA_BUF_H__ */ -- 2.25.1.481.gfbce0eb801-goog ^ permalink raw reply related [flat|nested] 71+ messages in thread
* [virtio-dev] [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-03-11 11:20 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: Daniel Vetter, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Stevens, linux-kernel, dri-devel, virtualization, linux-media, linaro-mm-sig, virtio-dev This change adds a new dma-buf operation that allows dma-bufs to be used by virtio drivers to share exported objects. The new operation allows the importing driver to query the exporting driver for the UUID which identifies the underlying exported object. Signed-off-by: David Stevens <stevensd@chromium.org> --- drivers/dma-buf/dma-buf.c | 12 ++++++++++++ include/linux/dma-buf.h | 18 ++++++++++++++++++ 2 files changed, 30 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..fa5210ba6aaa 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1158,6 +1158,18 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) } EXPORT_SYMBOL_GPL(dma_buf_vunmap); +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid) +{ + if (WARN_ON(!dmabuf) || !uuid) + return -EINVAL; + + if (!dmabuf->ops->get_uuid) + return -ENODEV; + + return dmabuf->ops->get_uuid(dmabuf, uuid); +} +EXPORT_SYMBOL_GPL(dma_buf_get_uuid); + #ifdef CONFIG_DEBUG_FS static int dma_buf_debug_show(struct seq_file *s, void *unused) { diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index abf5459a5b9d..00758523597d 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -251,6 +251,21 @@ struct dma_buf_ops { void *(*vmap)(struct dma_buf *); void (*vunmap)(struct dma_buf *, void *vaddr); + + /** + * @get_uuid + * + * This is called by dma_buf_get_uuid to get the UUID which identifies + * the buffer to virtio devices. + * + * This callback is optional. + * + * Returns: + * + * 0 on success or a negative error code on failure. On success uuid + * will be populated with the buffer's UUID. + */ + int (*get_uuid)(struct dma_buf *dmabuf, uuid_t *uuid); }; /** @@ -444,4 +459,7 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, unsigned long); void *dma_buf_vmap(struct dma_buf *); void dma_buf_vunmap(struct dma_buf *, void *vaddr); + +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid); + #endif /* __DMA_BUF_H__ */ -- 2.25.1.481.gfbce0eb801-goog --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-03-11 11:20 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: dri-devel, virtio-dev, Thomas Zimmermann, Michael S . Tsirkin, Jason Wang, linux-kernel, virtualization, linaro-mm-sig, David Stevens, linux-media This change adds a new dma-buf operation that allows dma-bufs to be used by virtio drivers to share exported objects. The new operation allows the importing driver to query the exporting driver for the UUID which identifies the underlying exported object. Signed-off-by: David Stevens <stevensd@chromium.org> --- drivers/dma-buf/dma-buf.c | 12 ++++++++++++ include/linux/dma-buf.h | 18 ++++++++++++++++++ 2 files changed, 30 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..fa5210ba6aaa 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1158,6 +1158,18 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) } EXPORT_SYMBOL_GPL(dma_buf_vunmap); +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid) +{ + if (WARN_ON(!dmabuf) || !uuid) + return -EINVAL; + + if (!dmabuf->ops->get_uuid) + return -ENODEV; + + return dmabuf->ops->get_uuid(dmabuf, uuid); +} +EXPORT_SYMBOL_GPL(dma_buf_get_uuid); + #ifdef CONFIG_DEBUG_FS static int dma_buf_debug_show(struct seq_file *s, void *unused) { diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index abf5459a5b9d..00758523597d 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -251,6 +251,21 @@ struct dma_buf_ops { void *(*vmap)(struct dma_buf *); void (*vunmap)(struct dma_buf *, void *vaddr); + + /** + * @get_uuid + * + * This is called by dma_buf_get_uuid to get the UUID which identifies + * the buffer to virtio devices. + * + * This callback is optional. + * + * Returns: + * + * 0 on success or a negative error code on failure. On success uuid + * will be populated with the buffer's UUID. + */ + int (*get_uuid)(struct dma_buf *dmabuf, uuid_t *uuid); }; /** @@ -444,4 +459,7 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, unsigned long); void *dma_buf_vmap(struct dma_buf *); void dma_buf_vunmap(struct dma_buf *, void *vaddr); + +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid); + #endif /* __DMA_BUF_H__ */ -- 2.25.1.481.gfbce0eb801-goog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects 2020-03-11 11:20 ` David Stevens (?) @ 2020-05-13 15:45 ` Daniel Vetter -1 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-13 15:45 UTC (permalink / raw) To: David Stevens, Tomasz Figa Cc: Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Wed, Mar 11, 2020 at 12:20 PM David Stevens <stevensd@chromium.org> wrote: > > This change adds a new dma-buf operation that allows dma-bufs to be used > by virtio drivers to share exported objects. The new operation allows > the importing driver to query the exporting driver for the UUID which > identifies the underlying exported object. > > Signed-off-by: David Stevens <stevensd@chromium.org> Adding Tomasz Figa, I've discussed this with him at elce last year I think. Just to make sure. Bunch of things: - obviously we need the users of this in a few drivers, can't really review anything stand-alone - adding very specific ops to the generic interface is rather awkward, eventually everyone wants that and we end up in a mess. I think the best solution here would be if we create a struct virtio_dma_buf which subclasses dma-buf, add a (hopefully safe) runtime upcasting functions, and then a virtio_dma_buf_get_uuid() function. Just storing the uuid should be doable (assuming this doesn't change during the lifetime of the buffer), so no need for a callback. - for the runtime upcasting the usual approach is to check the ->ops pointer. Which means that would need to be the same for all virtio dma_bufs, which might get a bit awkward. But I'd really prefer we not add allocator specific stuff like this to dma-buf. -Daniel > --- > drivers/dma-buf/dma-buf.c | 12 ++++++++++++ > include/linux/dma-buf.h | 18 ++++++++++++++++++ > 2 files changed, 30 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index d4097856c86b..fa5210ba6aaa 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1158,6 +1158,18 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) > } > EXPORT_SYMBOL_GPL(dma_buf_vunmap); > > +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid) > +{ > + if (WARN_ON(!dmabuf) || !uuid) > + return -EINVAL; > + > + if (!dmabuf->ops->get_uuid) > + return -ENODEV; > + > + return dmabuf->ops->get_uuid(dmabuf, uuid); > +} > +EXPORT_SYMBOL_GPL(dma_buf_get_uuid); > + > #ifdef CONFIG_DEBUG_FS > static int dma_buf_debug_show(struct seq_file *s, void *unused) > { > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h > index abf5459a5b9d..00758523597d 100644 > --- a/include/linux/dma-buf.h > +++ b/include/linux/dma-buf.h > @@ -251,6 +251,21 @@ struct dma_buf_ops { > > void *(*vmap)(struct dma_buf *); > void (*vunmap)(struct dma_buf *, void *vaddr); > + > + /** > + * @get_uuid > + * > + * This is called by dma_buf_get_uuid to get the UUID which identifies > + * the buffer to virtio devices. > + * > + * This callback is optional. > + * > + * Returns: > + * > + * 0 on success or a negative error code on failure. On success uuid > + * will be populated with the buffer's UUID. > + */ > + int (*get_uuid)(struct dma_buf *dmabuf, uuid_t *uuid); > }; > > /** > @@ -444,4 +459,7 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, > unsigned long); > void *dma_buf_vmap(struct dma_buf *); > void dma_buf_vunmap(struct dma_buf *, void *vaddr); > + > +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid); > + > #endif /* __DMA_BUF_H__ */ > -- > 2.25.1.481.gfbce0eb801-goog > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-13 15:45 ` Daniel Vetter 0 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-13 15:45 UTC (permalink / raw) To: David Stevens, Tomasz Figa Cc: virtio-dev, dri-devel, Michael S . Tsirkin, David Airlie, Jason Wang, Linux Kernel Mailing List, open list:VIRTIO CORE, NET..., moderated list:DMA BUFFER SHARING FRAMEWORK, Gerd Hoffmann, Thomas Zimmermann, open list:DMA BUFFER SHARING FRAMEWORK On Wed, Mar 11, 2020 at 12:20 PM David Stevens <stevensd@chromium.org> wrote: > > This change adds a new dma-buf operation that allows dma-bufs to be used > by virtio drivers to share exported objects. The new operation allows > the importing driver to query the exporting driver for the UUID which > identifies the underlying exported object. > > Signed-off-by: David Stevens <stevensd@chromium.org> Adding Tomasz Figa, I've discussed this with him at elce last year I think. Just to make sure. Bunch of things: - obviously we need the users of this in a few drivers, can't really review anything stand-alone - adding very specific ops to the generic interface is rather awkward, eventually everyone wants that and we end up in a mess. I think the best solution here would be if we create a struct virtio_dma_buf which subclasses dma-buf, add a (hopefully safe) runtime upcasting functions, and then a virtio_dma_buf_get_uuid() function. Just storing the uuid should be doable (assuming this doesn't change during the lifetime of the buffer), so no need for a callback. - for the runtime upcasting the usual approach is to check the ->ops pointer. Which means that would need to be the same for all virtio dma_bufs, which might get a bit awkward. But I'd really prefer we not add allocator specific stuff like this to dma-buf. -Daniel > --- > drivers/dma-buf/dma-buf.c | 12 ++++++++++++ > include/linux/dma-buf.h | 18 ++++++++++++++++++ > 2 files changed, 30 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index d4097856c86b..fa5210ba6aaa 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1158,6 +1158,18 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) > } > EXPORT_SYMBOL_GPL(dma_buf_vunmap); > > +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid) > +{ > + if (WARN_ON(!dmabuf) || !uuid) > + return -EINVAL; > + > + if (!dmabuf->ops->get_uuid) > + return -ENODEV; > + > + return dmabuf->ops->get_uuid(dmabuf, uuid); > +} > +EXPORT_SYMBOL_GPL(dma_buf_get_uuid); > + > #ifdef CONFIG_DEBUG_FS > static int dma_buf_debug_show(struct seq_file *s, void *unused) > { > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h > index abf5459a5b9d..00758523597d 100644 > --- a/include/linux/dma-buf.h > +++ b/include/linux/dma-buf.h > @@ -251,6 +251,21 @@ struct dma_buf_ops { > > void *(*vmap)(struct dma_buf *); > void (*vunmap)(struct dma_buf *, void *vaddr); > + > + /** > + * @get_uuid > + * > + * This is called by dma_buf_get_uuid to get the UUID which identifies > + * the buffer to virtio devices. > + * > + * This callback is optional. > + * > + * Returns: > + * > + * 0 on success or a negative error code on failure. On success uuid > + * will be populated with the buffer's UUID. > + */ > + int (*get_uuid)(struct dma_buf *dmabuf, uuid_t *uuid); > }; > > /** > @@ -444,4 +459,7 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, > unsigned long); > void *dma_buf_vmap(struct dma_buf *); > void dma_buf_vunmap(struct dma_buf *, void *vaddr); > + > +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid); > + > #endif /* __DMA_BUF_H__ */ > -- > 2.25.1.481.gfbce0eb801-goog > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-13 15:45 ` Daniel Vetter 0 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-13 15:45 UTC (permalink / raw) To: David Stevens, Tomasz Figa Cc: Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Wed, Mar 11, 2020 at 12:20 PM David Stevens <stevensd@chromium.org> wrote: > > This change adds a new dma-buf operation that allows dma-bufs to be used > by virtio drivers to share exported objects. The new operation allows > the importing driver to query the exporting driver for the UUID which > identifies the underlying exported object. > > Signed-off-by: David Stevens <stevensd@chromium.org> Adding Tomasz Figa, I've discussed this with him at elce last year I think. Just to make sure. Bunch of things: - obviously we need the users of this in a few drivers, can't really review anything stand-alone - adding very specific ops to the generic interface is rather awkward, eventually everyone wants that and we end up in a mess. I think the best solution here would be if we create a struct virtio_dma_buf which subclasses dma-buf, add a (hopefully safe) runtime upcasting functions, and then a virtio_dma_buf_get_uuid() function. Just storing the uuid should be doable (assuming this doesn't change during the lifetime of the buffer), so no need for a callback. - for the runtime upcasting the usual approach is to check the ->ops pointer. Which means that would need to be the same for all virtio dma_bufs, which might get a bit awkward. But I'd really prefer we not add allocator specific stuff like this to dma-buf. -Daniel > --- > drivers/dma-buf/dma-buf.c | 12 ++++++++++++ > include/linux/dma-buf.h | 18 ++++++++++++++++++ > 2 files changed, 30 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index d4097856c86b..fa5210ba6aaa 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1158,6 +1158,18 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) > } > EXPORT_SYMBOL_GPL(dma_buf_vunmap); > > +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid) > +{ > + if (WARN_ON(!dmabuf) || !uuid) > + return -EINVAL; > + > + if (!dmabuf->ops->get_uuid) > + return -ENODEV; > + > + return dmabuf->ops->get_uuid(dmabuf, uuid); > +} > +EXPORT_SYMBOL_GPL(dma_buf_get_uuid); > + > #ifdef CONFIG_DEBUG_FS > static int dma_buf_debug_show(struct seq_file *s, void *unused) > { > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h > index abf5459a5b9d..00758523597d 100644 > --- a/include/linux/dma-buf.h > +++ b/include/linux/dma-buf.h > @@ -251,6 +251,21 @@ struct dma_buf_ops { > > void *(*vmap)(struct dma_buf *); > void (*vunmap)(struct dma_buf *, void *vaddr); > + > + /** > + * @get_uuid > + * > + * This is called by dma_buf_get_uuid to get the UUID which identifies > + * the buffer to virtio devices. > + * > + * This callback is optional. > + * > + * Returns: > + * > + * 0 on success or a negative error code on failure. On success uuid > + * will be populated with the buffer's UUID. > + */ > + int (*get_uuid)(struct dma_buf *dmabuf, uuid_t *uuid); > }; > > /** > @@ -444,4 +459,7 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, > unsigned long); > void *dma_buf_vmap(struct dma_buf *); > void dma_buf_vunmap(struct dma_buf *, void *vaddr); > + > +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid); > + > #endif /* __DMA_BUF_H__ */ > -- > 2.25.1.481.gfbce0eb801-goog > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects 2020-05-13 15:45 ` Daniel Vetter (?) (?) @ 2020-05-14 2:08 ` David Stevens -1 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-14 2:08 UTC (permalink / raw) To: Daniel Vetter Cc: Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Thu, May 14, 2020 at 12:45 AM Daniel Vetter <daniel@ffwll.ch> wrote: > On Wed, Mar 11, 2020 at 12:20 PM David Stevens <stevensd@chromium.org> wrote: > > > > This change adds a new dma-buf operation that allows dma-bufs to be used > > by virtio drivers to share exported objects. The new operation allows > > the importing driver to query the exporting driver for the UUID which > > identifies the underlying exported object. > > > > Signed-off-by: David Stevens <stevensd@chromium.org> > > Adding Tomasz Figa, I've discussed this with him at elce last year I > think. Just to make sure. > > Bunch of things: > - obviously we need the users of this in a few drivers, can't really > review anything stand-alone Here is a link to the usage of this feature by the currently under development virtio-video driver: https://markmail.org/thread/j4xlqaaim266qpks > - adding very specific ops to the generic interface is rather awkward, > eventually everyone wants that and we end up in a mess. I think the > best solution here would be if we create a struct virtio_dma_buf which > subclasses dma-buf, add a (hopefully safe) runtime upcasting > functions, and then a virtio_dma_buf_get_uuid() function. Just storing > the uuid should be doable (assuming this doesn't change during the > lifetime of the buffer), so no need for a callback. So you would prefer a solution similar to the original version of this patchset? https://markmail.org/message/z7if4u56q5fmaok4 ^ permalink raw reply [flat|nested] 71+ messages in thread
* [virtio-dev] Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 2:08 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-14 2:08 UTC (permalink / raw) To: Daniel Vetter Cc: Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Thu, May 14, 2020 at 12:45 AM Daniel Vetter <daniel@ffwll.ch> wrote: > On Wed, Mar 11, 2020 at 12:20 PM David Stevens <stevensd@chromium.org> wrote: > > > > This change adds a new dma-buf operation that allows dma-bufs to be used > > by virtio drivers to share exported objects. The new operation allows > > the importing driver to query the exporting driver for the UUID which > > identifies the underlying exported object. > > > > Signed-off-by: David Stevens <stevensd@chromium.org> > > Adding Tomasz Figa, I've discussed this with him at elce last year I > think. Just to make sure. > > Bunch of things: > - obviously we need the users of this in a few drivers, can't really > review anything stand-alone Here is a link to the usage of this feature by the currently under development virtio-video driver: https://markmail.org/thread/j4xlqaaim266qpks > - adding very specific ops to the generic interface is rather awkward, > eventually everyone wants that and we end up in a mess. I think the > best solution here would be if we create a struct virtio_dma_buf which > subclasses dma-buf, add a (hopefully safe) runtime upcasting > functions, and then a virtio_dma_buf_get_uuid() function. Just storing > the uuid should be doable (assuming this doesn't change during the > lifetime of the buffer), so no need for a callback. So you would prefer a solution similar to the original version of this patchset? https://markmail.org/message/z7if4u56q5fmaok4 --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 2:08 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-14 2:08 UTC (permalink / raw) To: Daniel Vetter Cc: virtio-dev, dri-devel, Michael S . Tsirkin, David Airlie, Jason Wang, Linux Kernel Mailing List, Tomasz Figa, moderated list:DMA BUFFER SHARING FRAMEWORK, Gerd Hoffmann, Thomas Zimmermann, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK On Thu, May 14, 2020 at 12:45 AM Daniel Vetter <daniel@ffwll.ch> wrote: > On Wed, Mar 11, 2020 at 12:20 PM David Stevens <stevensd@chromium.org> wrote: > > > > This change adds a new dma-buf operation that allows dma-bufs to be used > > by virtio drivers to share exported objects. The new operation allows > > the importing driver to query the exporting driver for the UUID which > > identifies the underlying exported object. > > > > Signed-off-by: David Stevens <stevensd@chromium.org> > > Adding Tomasz Figa, I've discussed this with him at elce last year I > think. Just to make sure. > > Bunch of things: > - obviously we need the users of this in a few drivers, can't really > review anything stand-alone Here is a link to the usage of this feature by the currently under development virtio-video driver: https://markmail.org/thread/j4xlqaaim266qpks > - adding very specific ops to the generic interface is rather awkward, > eventually everyone wants that and we end up in a mess. I think the > best solution here would be if we create a struct virtio_dma_buf which > subclasses dma-buf, add a (hopefully safe) runtime upcasting > functions, and then a virtio_dma_buf_get_uuid() function. Just storing > the uuid should be doable (assuming this doesn't change during the > lifetime of the buffer), so no need for a callback. So you would prefer a solution similar to the original version of this patchset? https://markmail.org/message/z7if4u56q5fmaok4 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 2:08 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-14 2:08 UTC (permalink / raw) To: Daniel Vetter Cc: Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Thu, May 14, 2020 at 12:45 AM Daniel Vetter <daniel@ffwll.ch> wrote: > On Wed, Mar 11, 2020 at 12:20 PM David Stevens <stevensd@chromium.org> wrote: > > > > This change adds a new dma-buf operation that allows dma-bufs to be used > > by virtio drivers to share exported objects. The new operation allows > > the importing driver to query the exporting driver for the UUID which > > identifies the underlying exported object. > > > > Signed-off-by: David Stevens <stevensd@chromium.org> > > Adding Tomasz Figa, I've discussed this with him at elce last year I > think. Just to make sure. > > Bunch of things: > - obviously we need the users of this in a few drivers, can't really > review anything stand-alone Here is a link to the usage of this feature by the currently under development virtio-video driver: https://markmail.org/thread/j4xlqaaim266qpks > - adding very specific ops to the generic interface is rather awkward, > eventually everyone wants that and we end up in a mess. I think the > best solution here would be if we create a struct virtio_dma_buf which > subclasses dma-buf, add a (hopefully safe) runtime upcasting > functions, and then a virtio_dma_buf_get_uuid() function. Just storing > the uuid should be doable (assuming this doesn't change during the > lifetime of the buffer), so no need for a callback. So you would prefer a solution similar to the original version of this patchset? https://markmail.org/message/z7if4u56q5fmaok4 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects 2020-05-14 2:08 ` David Stevens (?) @ 2020-05-14 12:28 ` Daniel Vetter -1 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-14 12:28 UTC (permalink / raw) To: David Stevens Cc: Daniel Vetter, Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Thu, May 14, 2020 at 11:08:52AM +0900, David Stevens wrote: > On Thu, May 14, 2020 at 12:45 AM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Wed, Mar 11, 2020 at 12:20 PM David Stevens <stevensd@chromium.org> wrote: > > > > > > This change adds a new dma-buf operation that allows dma-bufs to be used > > > by virtio drivers to share exported objects. The new operation allows > > > the importing driver to query the exporting driver for the UUID which > > > identifies the underlying exported object. > > > > > > Signed-off-by: David Stevens <stevensd@chromium.org> > > > > Adding Tomasz Figa, I've discussed this with him at elce last year I > > think. Just to make sure. > > > > Bunch of things: > > - obviously we need the users of this in a few drivers, can't really > > review anything stand-alone > > Here is a link to the usage of this feature by the currently under > development virtio-video driver: > https://markmail.org/thread/j4xlqaaim266qpks > > > - adding very specific ops to the generic interface is rather awkward, > > eventually everyone wants that and we end up in a mess. I think the > > best solution here would be if we create a struct virtio_dma_buf which > > subclasses dma-buf, add a (hopefully safe) runtime upcasting > > functions, and then a virtio_dma_buf_get_uuid() function. Just storing > > the uuid should be doable (assuming this doesn't change during the > > lifetime of the buffer), so no need for a callback. > > So you would prefer a solution similar to the original version of this > patchset? https://markmail.org/message/z7if4u56q5fmaok4 yup. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 12:28 ` Daniel Vetter 0 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-14 12:28 UTC (permalink / raw) To: David Stevens Cc: dri-devel, virtio-dev, Thomas Zimmermann, Michael S . Tsirkin, David Airlie, Jason Wang, Linux Kernel Mailing List, Tomasz Figa, moderated list:DMA BUFFER SHARING FRAMEWORK, Gerd Hoffmann, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK On Thu, May 14, 2020 at 11:08:52AM +0900, David Stevens wrote: > On Thu, May 14, 2020 at 12:45 AM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Wed, Mar 11, 2020 at 12:20 PM David Stevens <stevensd@chromium.org> wrote: > > > > > > This change adds a new dma-buf operation that allows dma-bufs to be used > > > by virtio drivers to share exported objects. The new operation allows > > > the importing driver to query the exporting driver for the UUID which > > > identifies the underlying exported object. > > > > > > Signed-off-by: David Stevens <stevensd@chromium.org> > > > > Adding Tomasz Figa, I've discussed this with him at elce last year I > > think. Just to make sure. > > > > Bunch of things: > > - obviously we need the users of this in a few drivers, can't really > > review anything stand-alone > > Here is a link to the usage of this feature by the currently under > development virtio-video driver: > https://markmail.org/thread/j4xlqaaim266qpks > > > - adding very specific ops to the generic interface is rather awkward, > > eventually everyone wants that and we end up in a mess. I think the > > best solution here would be if we create a struct virtio_dma_buf which > > subclasses dma-buf, add a (hopefully safe) runtime upcasting > > functions, and then a virtio_dma_buf_get_uuid() function. Just storing > > the uuid should be doable (assuming this doesn't change during the > > lifetime of the buffer), so no need for a callback. > > So you would prefer a solution similar to the original version of this > patchset? https://markmail.org/message/z7if4u56q5fmaok4 yup. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 12:28 ` Daniel Vetter 0 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-14 12:28 UTC (permalink / raw) To: David Stevens Cc: Daniel Vetter, Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Thu, May 14, 2020 at 11:08:52AM +0900, David Stevens wrote: > On Thu, May 14, 2020 at 12:45 AM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Wed, Mar 11, 2020 at 12:20 PM David Stevens <stevensd@chromium.org> wrote: > > > > > > This change adds a new dma-buf operation that allows dma-bufs to be used > > > by virtio drivers to share exported objects. The new operation allows > > > the importing driver to query the exporting driver for the UUID which > > > identifies the underlying exported object. > > > > > > Signed-off-by: David Stevens <stevensd@chromium.org> > > > > Adding Tomasz Figa, I've discussed this with him at elce last year I > > think. Just to make sure. > > > > Bunch of things: > > - obviously we need the users of this in a few drivers, can't really > > review anything stand-alone > > Here is a link to the usage of this feature by the currently under > development virtio-video driver: > https://markmail.org/thread/j4xlqaaim266qpks > > > - adding very specific ops to the generic interface is rather awkward, > > eventually everyone wants that and we end up in a mess. I think the > > best solution here would be if we create a struct virtio_dma_buf which > > subclasses dma-buf, add a (hopefully safe) runtime upcasting > > functions, and then a virtio_dma_buf_get_uuid() function. Just storing > > the uuid should be doable (assuming this doesn't change during the > > lifetime of the buffer), so no need for a callback. > > So you would prefer a solution similar to the original version of this > patchset? https://markmail.org/message/z7if4u56q5fmaok4 yup. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects 2020-05-13 15:45 ` Daniel Vetter (?) (?) @ 2020-05-14 7:59 ` Gerd Hoffmann -1 siblings, 0 replies; 71+ messages in thread From: Gerd Hoffmann @ 2020-05-14 7:59 UTC (permalink / raw) To: Daniel Vetter Cc: David Stevens, Tomasz Figa, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev Hi, > - for the runtime upcasting the usual approach is to check the ->ops > pointer. Which means that would need to be the same for all virtio > dma_bufs, which might get a bit awkward. But I'd really prefer we not > add allocator specific stuff like this to dma-buf. This is exactly the problem, it gets messy quickly, also when it comes to using the drm_prime.c helpers ... take care, Gerd ^ permalink raw reply [flat|nested] 71+ messages in thread
* [virtio-dev] Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 7:59 ` Gerd Hoffmann 0 siblings, 0 replies; 71+ messages in thread From: Gerd Hoffmann @ 2020-05-14 7:59 UTC (permalink / raw) To: Daniel Vetter Cc: David Stevens, Tomasz Figa, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev Hi, > - for the runtime upcasting the usual approach is to check the ->ops > pointer. Which means that would need to be the same for all virtio > dma_bufs, which might get a bit awkward. But I'd really prefer we not > add allocator specific stuff like this to dma-buf. This is exactly the problem, it gets messy quickly, also when it comes to using the drm_prime.c helpers ... take care, Gerd --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 7:59 ` Gerd Hoffmann 0 siblings, 0 replies; 71+ messages in thread From: Gerd Hoffmann @ 2020-05-14 7:59 UTC (permalink / raw) To: Daniel Vetter Cc: virtio-dev, dri-devel, Michael S . Tsirkin, David Airlie, Jason Wang, Linux Kernel Mailing List, Tomasz Figa, moderated list:DMA BUFFER SHARING FRAMEWORK, David Stevens, Thomas Zimmermann, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK Hi, > - for the runtime upcasting the usual approach is to check the ->ops > pointer. Which means that would need to be the same for all virtio > dma_bufs, which might get a bit awkward. But I'd really prefer we not > add allocator specific stuff like this to dma-buf. This is exactly the problem, it gets messy quickly, also when it comes to using the drm_prime.c helpers ... take care, Gerd _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 7:59 ` Gerd Hoffmann 0 siblings, 0 replies; 71+ messages in thread From: Gerd Hoffmann @ 2020-05-14 7:59 UTC (permalink / raw) To: Daniel Vetter Cc: David Stevens, Tomasz Figa, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev Hi, > - for the runtime upcasting the usual approach is to check the ->ops > pointer. Which means that would need to be the same for all virtio > dma_bufs, which might get a bit awkward. But I'd really prefer we not > add allocator specific stuff like this to dma-buf. This is exactly the problem, it gets messy quickly, also when it comes to using the drm_prime.c helpers ... take care, Gerd ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects 2020-05-14 7:59 ` Gerd Hoffmann (?) @ 2020-05-14 12:31 ` Daniel Vetter -1 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-14 12:31 UTC (permalink / raw) To: Gerd Hoffmann Cc: Daniel Vetter, David Stevens, Tomasz Figa, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Thu, May 14, 2020 at 09:59:52AM +0200, Gerd Hoffmann wrote: > Hi, > > > - for the runtime upcasting the usual approach is to check the ->ops > > pointer. Which means that would need to be the same for all virtio > > dma_bufs, which might get a bit awkward. But I'd really prefer we not > > add allocator specific stuff like this to dma-buf. > > This is exactly the problem, it gets messy quickly, also when it comes > to using the drm_prime.c helpers ... drm_prime.c helpers (not the core bits) exist becaues nvidia needed something that wasnt EXPORT_SYMBOL_GPL. I wouldn't shed a big tear if they don't fit anymore, they're kinda not great to begin with. Much midlayer, not much of valued added, but at least the _GPL is gone. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 12:31 ` Daniel Vetter 0 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-14 12:31 UTC (permalink / raw) To: Gerd Hoffmann Cc: dri-devel, virtio-dev, Thomas Zimmermann, Michael S . Tsirkin, David Airlie, Jason Wang, Linux Kernel Mailing List, Tomasz Figa, moderated list:DMA BUFFER SHARING FRAMEWORK, David Stevens, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK On Thu, May 14, 2020 at 09:59:52AM +0200, Gerd Hoffmann wrote: > Hi, > > > - for the runtime upcasting the usual approach is to check the ->ops > > pointer. Which means that would need to be the same for all virtio > > dma_bufs, which might get a bit awkward. But I'd really prefer we not > > add allocator specific stuff like this to dma-buf. > > This is exactly the problem, it gets messy quickly, also when it comes > to using the drm_prime.c helpers ... drm_prime.c helpers (not the core bits) exist becaues nvidia needed something that wasnt EXPORT_SYMBOL_GPL. I wouldn't shed a big tear if they don't fit anymore, they're kinda not great to begin with. Much midlayer, not much of valued added, but at least the _GPL is gone. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 12:31 ` Daniel Vetter 0 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-14 12:31 UTC (permalink / raw) To: Gerd Hoffmann Cc: Daniel Vetter, David Stevens, Tomasz Figa, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Thu, May 14, 2020 at 09:59:52AM +0200, Gerd Hoffmann wrote: > Hi, > > > - for the runtime upcasting the usual approach is to check the ->ops > > pointer. Which means that would need to be the same for all virtio > > dma_bufs, which might get a bit awkward. But I'd really prefer we not > > add allocator specific stuff like this to dma-buf. > > This is exactly the problem, it gets messy quickly, also when it comes > to using the drm_prime.c helpers ... drm_prime.c helpers (not the core bits) exist becaues nvidia needed something that wasnt EXPORT_SYMBOL_GPL. I wouldn't shed a big tear if they don't fit anymore, they're kinda not great to begin with. Much midlayer, not much of valued added, but at least the _GPL is gone. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects 2020-05-13 15:45 ` Daniel Vetter (?) (?) @ 2020-05-14 8:19 ` David Stevens -1 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-14 8:19 UTC (permalink / raw) To: Daniel Vetter Cc: Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev Sorry for the duplicate reply, didn't notice this until now. > Just storing > the uuid should be doable (assuming this doesn't change during the > lifetime of the buffer), so no need for a callback. Directly storing the uuid doesn't work that well because of synchronization issues. The uuid needs to be shared between multiple virtio devices with independent command streams, so to prevent races between importing and exporting, the exporting driver can't share the uuid with other drivers until it knows that the device has finished registering the uuid. That requires a round trip to and then back from the device. Using a callback allows the latency from that round trip registration to be hidden. -David ^ permalink raw reply [flat|nested] 71+ messages in thread
* [virtio-dev] Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 8:19 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-14 8:19 UTC (permalink / raw) To: Daniel Vetter Cc: Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev Sorry for the duplicate reply, didn't notice this until now. > Just storing > the uuid should be doable (assuming this doesn't change during the > lifetime of the buffer), so no need for a callback. Directly storing the uuid doesn't work that well because of synchronization issues. The uuid needs to be shared between multiple virtio devices with independent command streams, so to prevent races between importing and exporting, the exporting driver can't share the uuid with other drivers until it knows that the device has finished registering the uuid. That requires a round trip to and then back from the device. Using a callback allows the latency from that round trip registration to be hidden. -David --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 8:19 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-14 8:19 UTC (permalink / raw) To: Daniel Vetter Cc: virtio-dev, dri-devel, Michael S . Tsirkin, David Airlie, Jason Wang, Linux Kernel Mailing List, Tomasz Figa, moderated list:DMA BUFFER SHARING FRAMEWORK, Gerd Hoffmann, Thomas Zimmermann, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK Sorry for the duplicate reply, didn't notice this until now. > Just storing > the uuid should be doable (assuming this doesn't change during the > lifetime of the buffer), so no need for a callback. Directly storing the uuid doesn't work that well because of synchronization issues. The uuid needs to be shared between multiple virtio devices with independent command streams, so to prevent races between importing and exporting, the exporting driver can't share the uuid with other drivers until it knows that the device has finished registering the uuid. That requires a round trip to and then back from the device. Using a callback allows the latency from that round trip registration to be hidden. -David _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 8:19 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-14 8:19 UTC (permalink / raw) To: Daniel Vetter Cc: Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev Sorry for the duplicate reply, didn't notice this until now. > Just storing > the uuid should be doable (assuming this doesn't change during the > lifetime of the buffer), so no need for a callback. Directly storing the uuid doesn't work that well because of synchronization issues. The uuid needs to be shared between multiple virtio devices with independent command streams, so to prevent races between importing and exporting, the exporting driver can't share the uuid with other drivers until it knows that the device has finished registering the uuid. That requires a round trip to and then back from the device. Using a callback allows the latency from that round trip registration to be hidden. -David ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects 2020-05-14 8:19 ` David Stevens (?) @ 2020-05-14 12:30 ` Daniel Vetter -1 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-14 12:30 UTC (permalink / raw) To: David Stevens Cc: Daniel Vetter, Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > Sorry for the duplicate reply, didn't notice this until now. > > > Just storing > > the uuid should be doable (assuming this doesn't change during the > > lifetime of the buffer), so no need for a callback. > > Directly storing the uuid doesn't work that well because of > synchronization issues. The uuid needs to be shared between multiple > virtio devices with independent command streams, so to prevent races > between importing and exporting, the exporting driver can't share the > uuid with other drivers until it knows that the device has finished > registering the uuid. That requires a round trip to and then back from > the device. Using a callback allows the latency from that round trip > registration to be hidden. Uh, that means you actually do something and there's locking involved. Makes stuff more complicated, invariant attributes are a lot easier generally. Registering that uuid just always doesn't work, and blocking when you're exporting? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 12:30 ` Daniel Vetter 0 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-14 12:30 UTC (permalink / raw) To: David Stevens Cc: dri-devel, virtio-dev, Thomas Zimmermann, Michael S . Tsirkin, David Airlie, Jason Wang, Linux Kernel Mailing List, Tomasz Figa, moderated list:DMA BUFFER SHARING FRAMEWORK, Gerd Hoffmann, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > Sorry for the duplicate reply, didn't notice this until now. > > > Just storing > > the uuid should be doable (assuming this doesn't change during the > > lifetime of the buffer), so no need for a callback. > > Directly storing the uuid doesn't work that well because of > synchronization issues. The uuid needs to be shared between multiple > virtio devices with independent command streams, so to prevent races > between importing and exporting, the exporting driver can't share the > uuid with other drivers until it knows that the device has finished > registering the uuid. That requires a round trip to and then back from > the device. Using a callback allows the latency from that round trip > registration to be hidden. Uh, that means you actually do something and there's locking involved. Makes stuff more complicated, invariant attributes are a lot easier generally. Registering that uuid just always doesn't work, and blocking when you're exporting? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-14 12:30 ` Daniel Vetter 0 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-14 12:30 UTC (permalink / raw) To: David Stevens Cc: Daniel Vetter, Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > Sorry for the duplicate reply, didn't notice this until now. > > > Just storing > > the uuid should be doable (assuming this doesn't change during the > > lifetime of the buffer), so no need for a callback. > > Directly storing the uuid doesn't work that well because of > synchronization issues. The uuid needs to be shared between multiple > virtio devices with independent command streams, so to prevent races > between importing and exporting, the exporting driver can't share the > uuid with other drivers until it knows that the device has finished > registering the uuid. That requires a round trip to and then back from > the device. Using a callback allows the latency from that round trip > registration to be hidden. Uh, that means you actually do something and there's locking involved. Makes stuff more complicated, invariant attributes are a lot easier generally. Registering that uuid just always doesn't work, and blocking when you're exporting? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects 2020-05-14 12:30 ` Daniel Vetter (?) (?) @ 2020-05-15 5:07 ` David Stevens -1 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-15 5:07 UTC (permalink / raw) To: David Stevens, Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev Cc: Daniel Vetter On Thu, May 14, 2020 at 9:30 PM Daniel Vetter <daniel@ffwll.ch> wrote: > On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > > Sorry for the duplicate reply, didn't notice this until now. > > > > > Just storing > > > the uuid should be doable (assuming this doesn't change during the > > > lifetime of the buffer), so no need for a callback. > > > > Directly storing the uuid doesn't work that well because of > > synchronization issues. The uuid needs to be shared between multiple > > virtio devices with independent command streams, so to prevent races > > between importing and exporting, the exporting driver can't share the > > uuid with other drivers until it knows that the device has finished > > registering the uuid. That requires a round trip to and then back from > > the device. Using a callback allows the latency from that round trip > > registration to be hidden. > > Uh, that means you actually do something and there's locking involved. > Makes stuff more complicated, invariant attributes are a lot easier > generally. Registering that uuid just always doesn't work, and blocking > when you're exporting? Registering the id at creation and blocking in gem export is feasible, but it doesn't work well for systems with a centralized buffer allocator that doesn't support batch allocations (e.g. gralloc). In such a system, the round trip latency would almost certainly be included in the buffer allocation time. At least on the system I'm working on, I suspect that would add 10s of milliseconds of startup latency to video pipelines (although I haven't benchmarked the difference). Doing the blocking as late as possible means most or all of the latency can be hidden behind other pipeline setup work. In terms of complexity, I think the synchronization would be basically the same in either approach, just in different locations. All it would do is alleviate the need for a callback to fetch the UUID. -David ^ permalink raw reply [flat|nested] 71+ messages in thread
* [virtio-dev] Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-15 5:07 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-15 5:07 UTC (permalink / raw) To: David Stevens, Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev Cc: Daniel Vetter On Thu, May 14, 2020 at 9:30 PM Daniel Vetter <daniel@ffwll.ch> wrote: > On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > > Sorry for the duplicate reply, didn't notice this until now. > > > > > Just storing > > > the uuid should be doable (assuming this doesn't change during the > > > lifetime of the buffer), so no need for a callback. > > > > Directly storing the uuid doesn't work that well because of > > synchronization issues. The uuid needs to be shared between multiple > > virtio devices with independent command streams, so to prevent races > > between importing and exporting, the exporting driver can't share the > > uuid with other drivers until it knows that the device has finished > > registering the uuid. That requires a round trip to and then back from > > the device. Using a callback allows the latency from that round trip > > registration to be hidden. > > Uh, that means you actually do something and there's locking involved. > Makes stuff more complicated, invariant attributes are a lot easier > generally. Registering that uuid just always doesn't work, and blocking > when you're exporting? Registering the id at creation and blocking in gem export is feasible, but it doesn't work well for systems with a centralized buffer allocator that doesn't support batch allocations (e.g. gralloc). In such a system, the round trip latency would almost certainly be included in the buffer allocation time. At least on the system I'm working on, I suspect that would add 10s of milliseconds of startup latency to video pipelines (although I haven't benchmarked the difference). Doing the blocking as late as possible means most or all of the latency can be hidden behind other pipeline setup work. In terms of complexity, I think the synchronization would be basically the same in either approach, just in different locations. All it would do is alleviate the need for a callback to fetch the UUID. -David --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-15 5:07 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-15 5:07 UTC (permalink / raw) To: David Stevens, Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Thu, May 14, 2020 at 9:30 PM Daniel Vetter <daniel@ffwll.ch> wrote: > On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > > Sorry for the duplicate reply, didn't notice this until now. > > > > > Just storing > > > the uuid should be doable (assuming this doesn't change during the > > > lifetime of the buffer), so no need for a callback. > > > > Directly storing the uuid doesn't work that well because of > > synchronization issues. The uuid needs to be shared between multiple > > virtio devices with independent command streams, so to prevent races > > between importing and exporting, the exporting driver can't share the > > uuid with other drivers until it knows that the device has finished > > registering the uuid. That requires a round trip to and then back from > > the device. Using a callback allows the latency from that round trip > > registration to be hidden. > > Uh, that means you actually do something and there's locking involved. > Makes stuff more complicated, invariant attributes are a lot easier > generally. Registering that uuid just always doesn't work, and blocking > when you're exporting? Registering the id at creation and blocking in gem export is feasible, but it doesn't work well for systems with a centralized buffer allocator that doesn't support batch allocations (e.g. gralloc). In such a system, the round trip latency would almost certainly be included in the buffer allocation time. At least on the system I'm working on, I suspect that would add 10s of milliseconds of startup latency to video pipelines (although I haven't benchmarked the difference). Doing the blocking as late as possible means most or all of the latency can be hidden behind other pipeline setup work. In terms of complexity, I think the synchronization would be basically the same in either approach, just in different locations. All it would do is alleviate the need for a callback to fetch the UUID. -David _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-15 5:07 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-15 5:07 UTC (permalink / raw) To: David Stevens, Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev Cc: Daniel Vetter On Thu, May 14, 2020 at 9:30 PM Daniel Vetter <daniel@ffwll.ch> wrote: > On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > > Sorry for the duplicate reply, didn't notice this until now. > > > > > Just storing > > > the uuid should be doable (assuming this doesn't change during the > > > lifetime of the buffer), so no need for a callback. > > > > Directly storing the uuid doesn't work that well because of > > synchronization issues. The uuid needs to be shared between multiple > > virtio devices with independent command streams, so to prevent races > > between importing and exporting, the exporting driver can't share the > > uuid with other drivers until it knows that the device has finished > > registering the uuid. That requires a round trip to and then back from > > the device. Using a callback allows the latency from that round trip > > registration to be hidden. > > Uh, that means you actually do something and there's locking involved. > Makes stuff more complicated, invariant attributes are a lot easier > generally. Registering that uuid just always doesn't work, and blocking > when you're exporting? Registering the id at creation and blocking in gem export is feasible, but it doesn't work well for systems with a centralized buffer allocator that doesn't support batch allocations (e.g. gralloc). In such a system, the round trip latency would almost certainly be included in the buffer allocation time. At least on the system I'm working on, I suspect that would add 10s of milliseconds of startup latency to video pipelines (although I haven't benchmarked the difference). Doing the blocking as late as possible means most or all of the latency can be hidden behind other pipeline setup work. In terms of complexity, I think the synchronization would be basically the same in either approach, just in different locations. All it would do is alleviate the need for a callback to fetch the UUID. -David ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects 2020-05-15 5:07 ` David Stevens (?) @ 2020-05-15 14:03 ` Daniel Vetter -1 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-15 14:03 UTC (permalink / raw) To: David Stevens Cc: Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev, Daniel Vetter On Fri, May 15, 2020 at 02:07:06PM +0900, David Stevens wrote: > On Thu, May 14, 2020 at 9:30 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > > > Sorry for the duplicate reply, didn't notice this until now. > > > > > > > Just storing > > > > the uuid should be doable (assuming this doesn't change during the > > > > lifetime of the buffer), so no need for a callback. > > > > > > Directly storing the uuid doesn't work that well because of > > > synchronization issues. The uuid needs to be shared between multiple > > > virtio devices with independent command streams, so to prevent races > > > between importing and exporting, the exporting driver can't share the > > > uuid with other drivers until it knows that the device has finished > > > registering the uuid. That requires a round trip to and then back from > > > the device. Using a callback allows the latency from that round trip > > > registration to be hidden. > > > > Uh, that means you actually do something and there's locking involved. > > Makes stuff more complicated, invariant attributes are a lot easier > > generally. Registering that uuid just always doesn't work, and blocking > > when you're exporting? > > Registering the id at creation and blocking in gem export is feasible, > but it doesn't work well for systems with a centralized buffer > allocator that doesn't support batch allocations (e.g. gralloc). In > such a system, the round trip latency would almost certainly be > included in the buffer allocation time. At least on the system I'm > working on, I suspect that would add 10s of milliseconds of startup > latency to video pipelines (although I haven't benchmarked the > difference). Doing the blocking as late as possible means most or all > of the latency can be hidden behind other pipeline setup work. > > In terms of complexity, I think the synchronization would be basically > the same in either approach, just in different locations. All it would > do is alleviate the need for a callback to fetch the UUID. Hm ok. I guess if we go with the older patch, where this all is a lot more just code in virtio, doing an extra function to allocate the uuid sounds fine. Then synchronization is entirely up to the virtio subsystem and not a dma-buf problem (and hence not mine). You can use dma_resv_lock or so, but no need to. But with callbacks potentially going both ways things always get a bit interesting wrt locking - this is what makes peer2peer dma-buf so painful right now. Hence I'd like to avoid that if needed, at least at the dma-buf level. virtio code I don't mind what you do there :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-15 14:03 ` Daniel Vetter 0 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-15 14:03 UTC (permalink / raw) To: David Stevens Cc: virtio-dev, dri-devel, Michael S . Tsirkin, David Airlie, Jason Wang, Linux Kernel Mailing List, Tomasz Figa, moderated list:DMA BUFFER SHARING FRAMEWORK, Gerd Hoffmann, Thomas Zimmermann, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK On Fri, May 15, 2020 at 02:07:06PM +0900, David Stevens wrote: > On Thu, May 14, 2020 at 9:30 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > > > Sorry for the duplicate reply, didn't notice this until now. > > > > > > > Just storing > > > > the uuid should be doable (assuming this doesn't change during the > > > > lifetime of the buffer), so no need for a callback. > > > > > > Directly storing the uuid doesn't work that well because of > > > synchronization issues. The uuid needs to be shared between multiple > > > virtio devices with independent command streams, so to prevent races > > > between importing and exporting, the exporting driver can't share the > > > uuid with other drivers until it knows that the device has finished > > > registering the uuid. That requires a round trip to and then back from > > > the device. Using a callback allows the latency from that round trip > > > registration to be hidden. > > > > Uh, that means you actually do something and there's locking involved. > > Makes stuff more complicated, invariant attributes are a lot easier > > generally. Registering that uuid just always doesn't work, and blocking > > when you're exporting? > > Registering the id at creation and blocking in gem export is feasible, > but it doesn't work well for systems with a centralized buffer > allocator that doesn't support batch allocations (e.g. gralloc). In > such a system, the round trip latency would almost certainly be > included in the buffer allocation time. At least on the system I'm > working on, I suspect that would add 10s of milliseconds of startup > latency to video pipelines (although I haven't benchmarked the > difference). Doing the blocking as late as possible means most or all > of the latency can be hidden behind other pipeline setup work. > > In terms of complexity, I think the synchronization would be basically > the same in either approach, just in different locations. All it would > do is alleviate the need for a callback to fetch the UUID. Hm ok. I guess if we go with the older patch, where this all is a lot more just code in virtio, doing an extra function to allocate the uuid sounds fine. Then synchronization is entirely up to the virtio subsystem and not a dma-buf problem (and hence not mine). You can use dma_resv_lock or so, but no need to. But with callbacks potentially going both ways things always get a bit interesting wrt locking - this is what makes peer2peer dma-buf so painful right now. Hence I'd like to avoid that if needed, at least at the dma-buf level. virtio code I don't mind what you do there :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-15 14:03 ` Daniel Vetter 0 siblings, 0 replies; 71+ messages in thread From: Daniel Vetter @ 2020-05-15 14:03 UTC (permalink / raw) To: David Stevens Cc: Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev, Daniel Vetter On Fri, May 15, 2020 at 02:07:06PM +0900, David Stevens wrote: > On Thu, May 14, 2020 at 9:30 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > > > Sorry for the duplicate reply, didn't notice this until now. > > > > > > > Just storing > > > > the uuid should be doable (assuming this doesn't change during the > > > > lifetime of the buffer), so no need for a callback. > > > > > > Directly storing the uuid doesn't work that well because of > > > synchronization issues. The uuid needs to be shared between multiple > > > virtio devices with independent command streams, so to prevent races > > > between importing and exporting, the exporting driver can't share the > > > uuid with other drivers until it knows that the device has finished > > > registering the uuid. That requires a round trip to and then back from > > > the device. Using a callback allows the latency from that round trip > > > registration to be hidden. > > > > Uh, that means you actually do something and there's locking involved. > > Makes stuff more complicated, invariant attributes are a lot easier > > generally. Registering that uuid just always doesn't work, and blocking > > when you're exporting? > > Registering the id at creation and blocking in gem export is feasible, > but it doesn't work well for systems with a centralized buffer > allocator that doesn't support batch allocations (e.g. gralloc). In > such a system, the round trip latency would almost certainly be > included in the buffer allocation time. At least on the system I'm > working on, I suspect that would add 10s of milliseconds of startup > latency to video pipelines (although I haven't benchmarked the > difference). Doing the blocking as late as possible means most or all > of the latency can be hidden behind other pipeline setup work. > > In terms of complexity, I think the synchronization would be basically > the same in either approach, just in different locations. All it would > do is alleviate the need for a callback to fetch the UUID. Hm ok. I guess if we go with the older patch, where this all is a lot more just code in virtio, doing an extra function to allocate the uuid sounds fine. Then synchronization is entirely up to the virtio subsystem and not a dma-buf problem (and hence not mine). You can use dma_resv_lock or so, but no need to. But with callbacks potentially going both ways things always get a bit interesting wrt locking - this is what makes peer2peer dma-buf so painful right now. Hence I'd like to avoid that if needed, at least at the dma-buf level. virtio code I don't mind what you do there :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects 2020-05-15 14:03 ` Daniel Vetter (?) @ 2020-05-18 11:17 ` Sumit Semwal -1 siblings, 0 replies; 71+ messages in thread From: Sumit Semwal @ 2020-05-18 11:17 UTC (permalink / raw) To: David Stevens, Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev Cc: Daniel Vetter Hello David, On Fri, 15 May 2020 at 19:33, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Fri, May 15, 2020 at 02:07:06PM +0900, David Stevens wrote: > > On Thu, May 14, 2020 at 9:30 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > > On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > > > > Sorry for the duplicate reply, didn't notice this until now. > > > > > > > > > Just storing > > > > > the uuid should be doable (assuming this doesn't change during the > > > > > lifetime of the buffer), so no need for a callback. > > > > > > > > Directly storing the uuid doesn't work that well because of > > > > synchronization issues. The uuid needs to be shared between multiple > > > > virtio devices with independent command streams, so to prevent races > > > > between importing and exporting, the exporting driver can't share the > > > > uuid with other drivers until it knows that the device has finished > > > > registering the uuid. That requires a round trip to and then back from > > > > the device. Using a callback allows the latency from that round trip > > > > registration to be hidden. > > > > > > Uh, that means you actually do something and there's locking involved. > > > Makes stuff more complicated, invariant attributes are a lot easier > > > generally. Registering that uuid just always doesn't work, and blocking > > > when you're exporting? > > > > Registering the id at creation and blocking in gem export is feasible, > > but it doesn't work well for systems with a centralized buffer > > allocator that doesn't support batch allocations (e.g. gralloc). In > > such a system, the round trip latency would almost certainly be > > included in the buffer allocation time. At least on the system I'm > > working on, I suspect that would add 10s of milliseconds of startup > > latency to video pipelines (although I haven't benchmarked the > > difference). Doing the blocking as late as possible means most or all > > of the latency can be hidden behind other pipeline setup work. > > > > In terms of complexity, I think the synchronization would be basically > > the same in either approach, just in different locations. All it would > > do is alleviate the need for a callback to fetch the UUID. > I think I agree with Daniel there - this seems best suited for code within virtio. > Hm ok. I guess if we go with the older patch, where this all is a lot more > just code in virtio, doing an extra function to allocate the uuid sounds > fine. Then synchronization is entirely up to the virtio subsystem and not > a dma-buf problem (and hence not mine). You can use dma_resv_lock or so, > but no need to. But with callbacks potentially going both ways things > always get a bit interesting wrt locking - this is what makes peer2peer > dma-buf so painful right now. Hence I'd like to avoid that if needed, at > least at the dma-buf level. virtio code I don't mind what you do there :-) > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch Best, Sumit. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-18 11:17 ` Sumit Semwal 0 siblings, 0 replies; 71+ messages in thread From: Sumit Semwal @ 2020-05-18 11:17 UTC (permalink / raw) To: David Stevens, Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev Hello David, On Fri, 15 May 2020 at 19:33, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Fri, May 15, 2020 at 02:07:06PM +0900, David Stevens wrote: > > On Thu, May 14, 2020 at 9:30 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > > On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > > > > Sorry for the duplicate reply, didn't notice this until now. > > > > > > > > > Just storing > > > > > the uuid should be doable (assuming this doesn't change during the > > > > > lifetime of the buffer), so no need for a callback. > > > > > > > > Directly storing the uuid doesn't work that well because of > > > > synchronization issues. The uuid needs to be shared between multiple > > > > virtio devices with independent command streams, so to prevent races > > > > between importing and exporting, the exporting driver can't share the > > > > uuid with other drivers until it knows that the device has finished > > > > registering the uuid. That requires a round trip to and then back from > > > > the device. Using a callback allows the latency from that round trip > > > > registration to be hidden. > > > > > > Uh, that means you actually do something and there's locking involved. > > > Makes stuff more complicated, invariant attributes are a lot easier > > > generally. Registering that uuid just always doesn't work, and blocking > > > when you're exporting? > > > > Registering the id at creation and blocking in gem export is feasible, > > but it doesn't work well for systems with a centralized buffer > > allocator that doesn't support batch allocations (e.g. gralloc). In > > such a system, the round trip latency would almost certainly be > > included in the buffer allocation time. At least on the system I'm > > working on, I suspect that would add 10s of milliseconds of startup > > latency to video pipelines (although I haven't benchmarked the > > difference). Doing the blocking as late as possible means most or all > > of the latency can be hidden behind other pipeline setup work. > > > > In terms of complexity, I think the synchronization would be basically > > the same in either approach, just in different locations. All it would > > do is alleviate the need for a callback to fetch the UUID. > I think I agree with Daniel there - this seems best suited for code within virtio. > Hm ok. I guess if we go with the older patch, where this all is a lot more > just code in virtio, doing an extra function to allocate the uuid sounds > fine. Then synchronization is entirely up to the virtio subsystem and not > a dma-buf problem (and hence not mine). You can use dma_resv_lock or so, > but no need to. But with callbacks potentially going both ways things > always get a bit interesting wrt locking - this is what makes peer2peer > dma-buf so painful right now. Hence I'd like to avoid that if needed, at > least at the dma-buf level. virtio code I don't mind what you do there :-) > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch Best, Sumit. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects @ 2020-05-18 11:17 ` Sumit Semwal 0 siblings, 0 replies; 71+ messages in thread From: Sumit Semwal @ 2020-05-18 11:17 UTC (permalink / raw) To: David Stevens, Tomasz Figa, Gerd Hoffmann, David Airlie, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Linux Kernel Mailing List, dri-devel, open list:VIRTIO CORE, NET..., open list:DMA BUFFER SHARING FRAMEWORK, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev Cc: Daniel Vetter Hello David, On Fri, 15 May 2020 at 19:33, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Fri, May 15, 2020 at 02:07:06PM +0900, David Stevens wrote: > > On Thu, May 14, 2020 at 9:30 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > > On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > > > > Sorry for the duplicate reply, didn't notice this until now. > > > > > > > > > Just storing > > > > > the uuid should be doable (assuming this doesn't change during the > > > > > lifetime of the buffer), so no need for a callback. > > > > > > > > Directly storing the uuid doesn't work that well because of > > > > synchronization issues. The uuid needs to be shared between multiple > > > > virtio devices with independent command streams, so to prevent races > > > > between importing and exporting, the exporting driver can't share the > > > > uuid with other drivers until it knows that the device has finished > > > > registering the uuid. That requires a round trip to and then back from > > > > the device. Using a callback allows the latency from that round trip > > > > registration to be hidden. > > > > > > Uh, that means you actually do something and there's locking involved. > > > Makes stuff more complicated, invariant attributes are a lot easier > > > generally. Registering that uuid just always doesn't work, and blocking > > > when you're exporting? > > > > Registering the id at creation and blocking in gem export is feasible, > > but it doesn't work well for systems with a centralized buffer > > allocator that doesn't support batch allocations (e.g. gralloc). In > > such a system, the round trip latency would almost certainly be > > included in the buffer allocation time. At least on the system I'm > > working on, I suspect that would add 10s of milliseconds of startup > > latency to video pipelines (although I haven't benchmarked the > > difference). Doing the blocking as late as possible means most or all > > of the latency can be hidden behind other pipeline setup work. > > > > In terms of complexity, I think the synchronization would be basically > > the same in either approach, just in different locations. All it would > > do is alleviate the need for a callback to fetch the UUID. > I think I agree with Daniel there - this seems best suited for code within virtio. > Hm ok. I guess if we go with the older patch, where this all is a lot more > just code in virtio, doing an extra function to allocate the uuid sounds > fine. Then synchronization is entirely up to the virtio subsystem and not > a dma-buf problem (and hence not mine). You can use dma_resv_lock or so, > but no need to. But with callbacks potentially going both ways things > always get a bit interesting wrt locking - this is what makes peer2peer > dma-buf so painful right now. Hence I'd like to avoid that if needed, at > least at the dma-buf level. virtio code I don't mind what you do there :-) > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch Best, Sumit. ^ permalink raw reply [flat|nested] 71+ messages in thread
* [PATCH v3 2/4] drm/prime: add support for virtio exported objects 2020-03-11 11:20 ` David Stevens (?) @ 2020-03-11 11:20 ` David Stevens -1 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: Daniel Vetter, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Stevens, linux-kernel, dri-devel, virtualization, linux-media, linaro-mm-sig, virtio-dev This change exposes dma-buf's get_uuid callback to PRIME drivers. Signed-off-by: David Stevens <stevensd@chromium.org> --- drivers/gpu/drm/drm_prime.c | 23 +++++++++++++++++++++++ include/drm/drm_drv.h | 10 ++++++++++ 2 files changed, 33 insertions(+) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 86d9b0e45c8c..50fed8497d3c 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -779,6 +779,28 @@ int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma) } EXPORT_SYMBOL(drm_gem_dmabuf_mmap); +/** + * drm_gem_dmabuf_get_uuid - dma_buf get_uuid implementation for GEM + * @dma_buf: buffer to query + * @uuid: uuid outparam + * + * Queries the buffer's virtio UUID. This can be used as the + * &dma_buf_ops.get_uuid callback. Calls into &drm_driver.gem_prime_get_uuid. + * + * Returns 0 on success or a negative error code on failure. + */ +int drm_gem_dmabuf_get_uuid(struct dma_buf *dma_buf, uuid_t *uuid) +{ + struct drm_gem_object *obj = dma_buf->priv; + struct drm_device *dev = obj->dev; + + if (!dev->driver->gem_prime_get_uuid) + return -ENODEV; + + return dev->driver->gem_prime_get_uuid(obj, uuid); +} +EXPORT_SYMBOL(drm_gem_dmabuf_get_uuid); + static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = { .cache_sgt_mapping = true, .attach = drm_gem_map_attach, @@ -789,6 +811,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = { .mmap = drm_gem_dmabuf_mmap, .vmap = drm_gem_dmabuf_vmap, .vunmap = drm_gem_dmabuf_vunmap, + .get_uuid = drm_gem_dmabuf_get_uuid, }; /** diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h index 77685ed7aa65..61e3ff341844 100644 --- a/include/drm/drm_drv.h +++ b/include/drm/drm_drv.h @@ -29,6 +29,7 @@ #include <linux/list.h> #include <linux/irqreturn.h> +#include <linux/uuid.h> #include <drm/drm_device.h> @@ -639,6 +640,15 @@ struct drm_driver { int (*gem_prime_mmap)(struct drm_gem_object *obj, struct vm_area_struct *vma); + /** + * @gem_prime_get_uuid + * + * get_uuid hook for GEM drivers. Retrieves the virtio uuid of the + * given GEM buffer. + */ + int (*gem_prime_get_uuid)(struct drm_gem_object *obj, + uuid_t *uuid); + /** * @dumb_create: * -- 2.25.1.481.gfbce0eb801-goog ^ permalink raw reply related [flat|nested] 71+ messages in thread
* [virtio-dev] [PATCH v3 2/4] drm/prime: add support for virtio exported objects @ 2020-03-11 11:20 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: Daniel Vetter, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Stevens, linux-kernel, dri-devel, virtualization, linux-media, linaro-mm-sig, virtio-dev This change exposes dma-buf's get_uuid callback to PRIME drivers. Signed-off-by: David Stevens <stevensd@chromium.org> --- drivers/gpu/drm/drm_prime.c | 23 +++++++++++++++++++++++ include/drm/drm_drv.h | 10 ++++++++++ 2 files changed, 33 insertions(+) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 86d9b0e45c8c..50fed8497d3c 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -779,6 +779,28 @@ int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma) } EXPORT_SYMBOL(drm_gem_dmabuf_mmap); +/** + * drm_gem_dmabuf_get_uuid - dma_buf get_uuid implementation for GEM + * @dma_buf: buffer to query + * @uuid: uuid outparam + * + * Queries the buffer's virtio UUID. This can be used as the + * &dma_buf_ops.get_uuid callback. Calls into &drm_driver.gem_prime_get_uuid. + * + * Returns 0 on success or a negative error code on failure. + */ +int drm_gem_dmabuf_get_uuid(struct dma_buf *dma_buf, uuid_t *uuid) +{ + struct drm_gem_object *obj = dma_buf->priv; + struct drm_device *dev = obj->dev; + + if (!dev->driver->gem_prime_get_uuid) + return -ENODEV; + + return dev->driver->gem_prime_get_uuid(obj, uuid); +} +EXPORT_SYMBOL(drm_gem_dmabuf_get_uuid); + static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = { .cache_sgt_mapping = true, .attach = drm_gem_map_attach, @@ -789,6 +811,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = { .mmap = drm_gem_dmabuf_mmap, .vmap = drm_gem_dmabuf_vmap, .vunmap = drm_gem_dmabuf_vunmap, + .get_uuid = drm_gem_dmabuf_get_uuid, }; /** diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h index 77685ed7aa65..61e3ff341844 100644 --- a/include/drm/drm_drv.h +++ b/include/drm/drm_drv.h @@ -29,6 +29,7 @@ #include <linux/list.h> #include <linux/irqreturn.h> +#include <linux/uuid.h> #include <drm/drm_device.h> @@ -639,6 +640,15 @@ struct drm_driver { int (*gem_prime_mmap)(struct drm_gem_object *obj, struct vm_area_struct *vma); + /** + * @gem_prime_get_uuid + * + * get_uuid hook for GEM drivers. Retrieves the virtio uuid of the + * given GEM buffer. + */ + int (*gem_prime_get_uuid)(struct drm_gem_object *obj, + uuid_t *uuid); + /** * @dumb_create: * -- 2.25.1.481.gfbce0eb801-goog --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v3 2/4] drm/prime: add support for virtio exported objects @ 2020-03-11 11:20 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: dri-devel, virtio-dev, Thomas Zimmermann, Michael S . Tsirkin, Jason Wang, linux-kernel, virtualization, linaro-mm-sig, David Stevens, linux-media This change exposes dma-buf's get_uuid callback to PRIME drivers. Signed-off-by: David Stevens <stevensd@chromium.org> --- drivers/gpu/drm/drm_prime.c | 23 +++++++++++++++++++++++ include/drm/drm_drv.h | 10 ++++++++++ 2 files changed, 33 insertions(+) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 86d9b0e45c8c..50fed8497d3c 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -779,6 +779,28 @@ int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma) } EXPORT_SYMBOL(drm_gem_dmabuf_mmap); +/** + * drm_gem_dmabuf_get_uuid - dma_buf get_uuid implementation for GEM + * @dma_buf: buffer to query + * @uuid: uuid outparam + * + * Queries the buffer's virtio UUID. This can be used as the + * &dma_buf_ops.get_uuid callback. Calls into &drm_driver.gem_prime_get_uuid. + * + * Returns 0 on success or a negative error code on failure. + */ +int drm_gem_dmabuf_get_uuid(struct dma_buf *dma_buf, uuid_t *uuid) +{ + struct drm_gem_object *obj = dma_buf->priv; + struct drm_device *dev = obj->dev; + + if (!dev->driver->gem_prime_get_uuid) + return -ENODEV; + + return dev->driver->gem_prime_get_uuid(obj, uuid); +} +EXPORT_SYMBOL(drm_gem_dmabuf_get_uuid); + static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = { .cache_sgt_mapping = true, .attach = drm_gem_map_attach, @@ -789,6 +811,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = { .mmap = drm_gem_dmabuf_mmap, .vmap = drm_gem_dmabuf_vmap, .vunmap = drm_gem_dmabuf_vunmap, + .get_uuid = drm_gem_dmabuf_get_uuid, }; /** diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h index 77685ed7aa65..61e3ff341844 100644 --- a/include/drm/drm_drv.h +++ b/include/drm/drm_drv.h @@ -29,6 +29,7 @@ #include <linux/list.h> #include <linux/irqreturn.h> +#include <linux/uuid.h> #include <drm/drm_device.h> @@ -639,6 +640,15 @@ struct drm_driver { int (*gem_prime_mmap)(struct drm_gem_object *obj, struct vm_area_struct *vma); + /** + * @gem_prime_get_uuid + * + * get_uuid hook for GEM drivers. Retrieves the virtio uuid of the + * given GEM buffer. + */ + int (*gem_prime_get_uuid)(struct drm_gem_object *obj, + uuid_t *uuid); + /** * @dumb_create: * -- 2.25.1.481.gfbce0eb801-goog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v3 3/4] virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature 2020-03-11 11:20 ` David Stevens (?) @ 2020-03-11 11:20 ` David Stevens -1 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: Daniel Vetter, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Stevens, linux-kernel, dri-devel, virtualization, linux-media, linaro-mm-sig, virtio-dev This feature allows the guest to request a UUID from the host for a particular virtio_gpu resource. The UUID can then be shared with other virtio devices, to allow the other host devices to access the virtio_gpu's corresponding host resource. Signed-off-by: David Stevens <stevensd@chromium.org> --- include/uapi/linux/virtio_gpu.h | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h index 0c85914d9369..9721d58b4d58 100644 --- a/include/uapi/linux/virtio_gpu.h +++ b/include/uapi/linux/virtio_gpu.h @@ -50,6 +50,10 @@ * VIRTIO_GPU_CMD_GET_EDID */ #define VIRTIO_GPU_F_EDID 1 +/* + * VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID + */ +#define VIRTIO_GPU_F_RESOURCE_UUID 2 enum virtio_gpu_ctrl_type { VIRTIO_GPU_UNDEFINED = 0, @@ -66,6 +70,7 @@ enum virtio_gpu_ctrl_type { VIRTIO_GPU_CMD_GET_CAPSET_INFO, VIRTIO_GPU_CMD_GET_CAPSET, VIRTIO_GPU_CMD_GET_EDID, + VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID, /* 3d commands */ VIRTIO_GPU_CMD_CTX_CREATE = 0x0200, @@ -87,6 +92,7 @@ enum virtio_gpu_ctrl_type { VIRTIO_GPU_RESP_OK_CAPSET_INFO, VIRTIO_GPU_RESP_OK_CAPSET, VIRTIO_GPU_RESP_OK_EDID, + VIRTIO_GPU_RESP_OK_RESOURCE_UUID, /* error responses */ VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200, @@ -340,4 +346,17 @@ enum virtio_gpu_formats { VIRTIO_GPU_FORMAT_R8G8B8X8_UNORM = 134, }; +/* VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID */ +struct virtio_gpu_resource_assign_uuid { + struct virtio_gpu_ctrl_hdr hdr; + __le32 resource_id; + __le32 padding; +}; + +/* VIRTIO_GPU_RESP_OK_RESOURCE_UUID */ +struct virtio_gpu_resp_resource_uuid { + struct virtio_gpu_ctrl_hdr hdr; + __u8 uuid[16]; +}; + #endif -- 2.25.1.481.gfbce0eb801-goog ^ permalink raw reply related [flat|nested] 71+ messages in thread
* [virtio-dev] [PATCH v3 3/4] virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature @ 2020-03-11 11:20 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: Daniel Vetter, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Stevens, linux-kernel, dri-devel, virtualization, linux-media, linaro-mm-sig, virtio-dev This feature allows the guest to request a UUID from the host for a particular virtio_gpu resource. The UUID can then be shared with other virtio devices, to allow the other host devices to access the virtio_gpu's corresponding host resource. Signed-off-by: David Stevens <stevensd@chromium.org> --- include/uapi/linux/virtio_gpu.h | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h index 0c85914d9369..9721d58b4d58 100644 --- a/include/uapi/linux/virtio_gpu.h +++ b/include/uapi/linux/virtio_gpu.h @@ -50,6 +50,10 @@ * VIRTIO_GPU_CMD_GET_EDID */ #define VIRTIO_GPU_F_EDID 1 +/* + * VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID + */ +#define VIRTIO_GPU_F_RESOURCE_UUID 2 enum virtio_gpu_ctrl_type { VIRTIO_GPU_UNDEFINED = 0, @@ -66,6 +70,7 @@ enum virtio_gpu_ctrl_type { VIRTIO_GPU_CMD_GET_CAPSET_INFO, VIRTIO_GPU_CMD_GET_CAPSET, VIRTIO_GPU_CMD_GET_EDID, + VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID, /* 3d commands */ VIRTIO_GPU_CMD_CTX_CREATE = 0x0200, @@ -87,6 +92,7 @@ enum virtio_gpu_ctrl_type { VIRTIO_GPU_RESP_OK_CAPSET_INFO, VIRTIO_GPU_RESP_OK_CAPSET, VIRTIO_GPU_RESP_OK_EDID, + VIRTIO_GPU_RESP_OK_RESOURCE_UUID, /* error responses */ VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200, @@ -340,4 +346,17 @@ enum virtio_gpu_formats { VIRTIO_GPU_FORMAT_R8G8B8X8_UNORM = 134, }; +/* VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID */ +struct virtio_gpu_resource_assign_uuid { + struct virtio_gpu_ctrl_hdr hdr; + __le32 resource_id; + __le32 padding; +}; + +/* VIRTIO_GPU_RESP_OK_RESOURCE_UUID */ +struct virtio_gpu_resp_resource_uuid { + struct virtio_gpu_ctrl_hdr hdr; + __u8 uuid[16]; +}; + #endif -- 2.25.1.481.gfbce0eb801-goog --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v3 3/4] virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature @ 2020-03-11 11:20 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: dri-devel, virtio-dev, Thomas Zimmermann, Michael S . Tsirkin, Jason Wang, linux-kernel, virtualization, linaro-mm-sig, David Stevens, linux-media This feature allows the guest to request a UUID from the host for a particular virtio_gpu resource. The UUID can then be shared with other virtio devices, to allow the other host devices to access the virtio_gpu's corresponding host resource. Signed-off-by: David Stevens <stevensd@chromium.org> --- include/uapi/linux/virtio_gpu.h | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h index 0c85914d9369..9721d58b4d58 100644 --- a/include/uapi/linux/virtio_gpu.h +++ b/include/uapi/linux/virtio_gpu.h @@ -50,6 +50,10 @@ * VIRTIO_GPU_CMD_GET_EDID */ #define VIRTIO_GPU_F_EDID 1 +/* + * VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID + */ +#define VIRTIO_GPU_F_RESOURCE_UUID 2 enum virtio_gpu_ctrl_type { VIRTIO_GPU_UNDEFINED = 0, @@ -66,6 +70,7 @@ enum virtio_gpu_ctrl_type { VIRTIO_GPU_CMD_GET_CAPSET_INFO, VIRTIO_GPU_CMD_GET_CAPSET, VIRTIO_GPU_CMD_GET_EDID, + VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID, /* 3d commands */ VIRTIO_GPU_CMD_CTX_CREATE = 0x0200, @@ -87,6 +92,7 @@ enum virtio_gpu_ctrl_type { VIRTIO_GPU_RESP_OK_CAPSET_INFO, VIRTIO_GPU_RESP_OK_CAPSET, VIRTIO_GPU_RESP_OK_EDID, + VIRTIO_GPU_RESP_OK_RESOURCE_UUID, /* error responses */ VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200, @@ -340,4 +346,17 @@ enum virtio_gpu_formats { VIRTIO_GPU_FORMAT_R8G8B8X8_UNORM = 134, }; +/* VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID */ +struct virtio_gpu_resource_assign_uuid { + struct virtio_gpu_ctrl_hdr hdr; + __le32 resource_id; + __le32 padding; +}; + +/* VIRTIO_GPU_RESP_OK_RESOURCE_UUID */ +struct virtio_gpu_resp_resource_uuid { + struct virtio_gpu_ctrl_hdr hdr; + __u8 uuid[16]; +}; + #endif -- 2.25.1.481.gfbce0eb801-goog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources 2020-03-11 11:20 ` David Stevens (?) @ 2020-03-11 11:20 ` David Stevens -1 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: Daniel Vetter, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Stevens, linux-kernel, dri-devel, virtualization, linux-media, linaro-mm-sig, virtio-dev Add support for UUID-based resource sharing mechanism to virtgpu. This implements the new virtgpu commands and hooks them up to dma-buf's get_uuid callback. Signed-off-by: David Stevens <stevensd@chromium.org> --- drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++ drivers/gpu/drm/virtio/virtgpu_drv.h | 18 +++++++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++ drivers/gpu/drm/virtio/virtgpu_prime.c | 41 +++++++++++++++++-- drivers/gpu/drm/virtio/virtgpu_vq.c | 55 ++++++++++++++++++++++++++ 5 files changed, 118 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index ab4bed78e656..776e6667042e 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.c +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c @@ -165,6 +165,7 @@ static unsigned int features[] = { VIRTIO_GPU_F_VIRGL, #endif VIRTIO_GPU_F_EDID, + VIRTIO_GPU_F_RESOURCE_UUID, }; static struct virtio_driver virtio_gpu_driver = { .feature_table = features, @@ -202,7 +203,9 @@ static struct drm_driver driver = { .prime_handle_to_fd = drm_gem_prime_handle_to_fd, .prime_fd_to_handle = drm_gem_prime_fd_to_handle, .gem_prime_mmap = drm_gem_prime_mmap, + .gem_prime_export = virtgpu_gem_prime_export, .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table, + .gem_prime_get_uuid = virtgpu_gem_prime_get_uuid, .gem_create_object = virtio_gpu_create_object, .fops = &virtio_gpu_driver_fops, diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index af9403e1cf78..fab65f0f5a4d 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -49,6 +49,10 @@ #define DRIVER_MINOR 1 #define DRIVER_PATCHLEVEL 0 +#define UUID_INITIALIZING 0 +#define UUID_INITIALIZED 1 +#define UUID_INITIALIZATION_FAILED 2 + struct virtio_gpu_object_params { uint32_t format; uint32_t width; @@ -75,6 +79,9 @@ struct virtio_gpu_object { bool dumb; bool created; + + int uuid_state; + uuid_t uuid; }; #define gem_to_virtio_gpu_obj(gobj) \ container_of((gobj), struct virtio_gpu_object, base.base) @@ -196,6 +203,7 @@ struct virtio_gpu_device { bool has_virgl_3d; bool has_edid; bool has_indirect; + bool has_resource_assign_uuid; struct work_struct config_changed_work; @@ -206,6 +214,8 @@ struct virtio_gpu_device { struct virtio_gpu_drv_capset *capsets; uint32_t num_capsets; struct list_head cap_cache; + + spinlock_t resource_export_lock; }; struct virtio_gpu_fpriv { @@ -338,6 +348,10 @@ void virtio_gpu_dequeue_fence_func(struct work_struct *work); void virtio_gpu_disable_notify(struct virtio_gpu_device *vgdev); void virtio_gpu_enable_notify(struct virtio_gpu_device *vgdev); +int +virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev, + struct virtio_gpu_object_array *objs); + /* virtio_gpu_display.c */ void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev); void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev); @@ -366,6 +380,10 @@ int virtio_gpu_object_create(struct virtio_gpu_device *vgdev, struct virtio_gpu_object **bo_ptr, struct virtio_gpu_fence *fence); /* virtgpu_prime.c */ +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, + int flags); +int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj, + uuid_t *uuid); struct drm_gem_object *virtgpu_gem_prime_import_sg_table( struct drm_device *dev, struct dma_buf_attachment *attach, struct sg_table *sgt); diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 4009c2f97d08..5a2aeb6d2f35 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -134,6 +134,7 @@ int virtio_gpu_init(struct drm_device *dev) vgdev->dev = dev->dev; spin_lock_init(&vgdev->display_info_lock); + spin_lock_init(&vgdev->resource_export_lock); ida_init(&vgdev->ctx_id_ida); ida_init(&vgdev->resource_ida); init_waitqueue_head(&vgdev->resp_wq); @@ -162,6 +163,9 @@ int virtio_gpu_init(struct drm_device *dev) if (virtio_has_feature(vgdev->vdev, VIRTIO_RING_F_INDIRECT_DESC)) { vgdev->has_indirect = true; } + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { + vgdev->has_resource_assign_uuid = true; + } DRM_INFO("features: %cvirgl %cedid\n", vgdev->has_virgl_3d ? '+' : '-', diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c index 050d24c39a8f..7c6357f59877 100644 --- a/drivers/gpu/drm/virtio/virtgpu_prime.c +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c @@ -26,9 +26,44 @@ #include "virtgpu_drv.h" -/* Empty Implementations as there should not be any other driver for a virtual - * device that might share buffers with virtgpu - */ +int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj, + uuid_t *uuid) +{ + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); + struct virtio_gpu_device *vgdev = obj->dev->dev_private; + + wait_event(vgdev->resp_wq, bo->uuid_state != UUID_INITIALIZING); + if (bo->uuid_state != UUID_INITIALIZED) + return -ENODEV; + + uuid_copy(uuid, &bo->uuid); + + return 0; +} + +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, + int flags) +{ + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); + struct virtio_gpu_device *vgdev = obj->dev->dev_private; + struct virtio_gpu_object_array *objs; + int ret = 0; + + if (vgdev->has_resource_assign_uuid) { + objs = virtio_gpu_array_alloc(1); + if (!objs) + return ERR_PTR(-ENOMEM); + virtio_gpu_array_add_obj(objs, &bo->base.base); + + ret = virtio_gpu_cmd_resource_assign_uuid(vgdev, objs); + if (ret) + return ERR_PTR(ret); + } else { + bo->uuid_state = UUID_INITIALIZATION_FAILED; + } + + return drm_gem_prime_export(obj, flags); +} struct drm_gem_object *virtgpu_gem_prime_import_sg_table( struct drm_device *dev, struct dma_buf_attachment *attach, diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index cfe9c54f87a3..b968eaa46bb0 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -1111,3 +1111,58 @@ void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev, memcpy(cur_p, &output->cursor, sizeof(output->cursor)); virtio_gpu_queue_cursor(vgdev, vbuf); } + +static void virtio_gpu_cmd_resource_uuid_cb(struct virtio_gpu_device *vgdev, + struct virtio_gpu_vbuffer *vbuf) +{ + struct virtio_gpu_object *obj = + gem_to_virtio_gpu_obj(vbuf->objs->objs[0]); + struct virtio_gpu_resp_resource_uuid *resp = + (struct virtio_gpu_resp_resource_uuid *)vbuf->resp_buf; + uint32_t resp_type = le32_to_cpu(resp->hdr.type); + + spin_lock(&vgdev->resource_export_lock); + WARN_ON(obj->uuid_state != UUID_INITIALIZING); + + if (resp_type == VIRTIO_GPU_RESP_OK_RESOURCE_UUID && + obj->uuid_state == UUID_INITIALIZING) { + memcpy(&obj->uuid.b, resp->uuid, sizeof(obj->uuid.b)); + obj->uuid_state = UUID_INITIALIZED; + } else { + obj->uuid_state = UUID_INITIALIZATION_FAILED; + } + spin_unlock(&vgdev->resource_export_lock); + + wake_up_all(&vgdev->resp_wq); +} + +int +virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev, + struct virtio_gpu_object_array *objs) +{ + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(objs->objs[0]); + struct virtio_gpu_resource_assign_uuid *cmd_p; + struct virtio_gpu_vbuffer *vbuf; + struct virtio_gpu_resp_resource_uuid *resp_buf; + + resp_buf = kzalloc(sizeof(*resp_buf), GFP_KERNEL); + if (!resp_buf) { + spin_lock(&vgdev->resource_export_lock); + bo->uuid_state = UUID_INITIALIZATION_FAILED; + spin_unlock(&vgdev->resource_export_lock); + virtio_gpu_array_put_free(objs); + return -ENOMEM; + } + + cmd_p = virtio_gpu_alloc_cmd_resp(vgdev, + virtio_gpu_cmd_resource_uuid_cb, &vbuf, sizeof(*cmd_p), + sizeof(struct virtio_gpu_resp_resource_uuid), resp_buf); + memset(cmd_p, 0, sizeof(*cmd_p)); + + cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID); + cmd_p->resource_id = cpu_to_le32(bo->hw_res_handle); + + vbuf->objs = objs; + virtio_gpu_queue_ctrl_buffer(vgdev, vbuf); + return 0; +} -- 2.25.1.481.gfbce0eb801-goog ^ permalink raw reply related [flat|nested] 71+ messages in thread
* [virtio-dev] [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-03-11 11:20 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: Daniel Vetter, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Stevens, linux-kernel, dri-devel, virtualization, linux-media, linaro-mm-sig, virtio-dev Add support for UUID-based resource sharing mechanism to virtgpu. This implements the new virtgpu commands and hooks them up to dma-buf's get_uuid callback. Signed-off-by: David Stevens <stevensd@chromium.org> --- drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++ drivers/gpu/drm/virtio/virtgpu_drv.h | 18 +++++++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++ drivers/gpu/drm/virtio/virtgpu_prime.c | 41 +++++++++++++++++-- drivers/gpu/drm/virtio/virtgpu_vq.c | 55 ++++++++++++++++++++++++++ 5 files changed, 118 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index ab4bed78e656..776e6667042e 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.c +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c @@ -165,6 +165,7 @@ static unsigned int features[] = { VIRTIO_GPU_F_VIRGL, #endif VIRTIO_GPU_F_EDID, + VIRTIO_GPU_F_RESOURCE_UUID, }; static struct virtio_driver virtio_gpu_driver = { .feature_table = features, @@ -202,7 +203,9 @@ static struct drm_driver driver = { .prime_handle_to_fd = drm_gem_prime_handle_to_fd, .prime_fd_to_handle = drm_gem_prime_fd_to_handle, .gem_prime_mmap = drm_gem_prime_mmap, + .gem_prime_export = virtgpu_gem_prime_export, .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table, + .gem_prime_get_uuid = virtgpu_gem_prime_get_uuid, .gem_create_object = virtio_gpu_create_object, .fops = &virtio_gpu_driver_fops, diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index af9403e1cf78..fab65f0f5a4d 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -49,6 +49,10 @@ #define DRIVER_MINOR 1 #define DRIVER_PATCHLEVEL 0 +#define UUID_INITIALIZING 0 +#define UUID_INITIALIZED 1 +#define UUID_INITIALIZATION_FAILED 2 + struct virtio_gpu_object_params { uint32_t format; uint32_t width; @@ -75,6 +79,9 @@ struct virtio_gpu_object { bool dumb; bool created; + + int uuid_state; + uuid_t uuid; }; #define gem_to_virtio_gpu_obj(gobj) \ container_of((gobj), struct virtio_gpu_object, base.base) @@ -196,6 +203,7 @@ struct virtio_gpu_device { bool has_virgl_3d; bool has_edid; bool has_indirect; + bool has_resource_assign_uuid; struct work_struct config_changed_work; @@ -206,6 +214,8 @@ struct virtio_gpu_device { struct virtio_gpu_drv_capset *capsets; uint32_t num_capsets; struct list_head cap_cache; + + spinlock_t resource_export_lock; }; struct virtio_gpu_fpriv { @@ -338,6 +348,10 @@ void virtio_gpu_dequeue_fence_func(struct work_struct *work); void virtio_gpu_disable_notify(struct virtio_gpu_device *vgdev); void virtio_gpu_enable_notify(struct virtio_gpu_device *vgdev); +int +virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev, + struct virtio_gpu_object_array *objs); + /* virtio_gpu_display.c */ void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev); void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev); @@ -366,6 +380,10 @@ int virtio_gpu_object_create(struct virtio_gpu_device *vgdev, struct virtio_gpu_object **bo_ptr, struct virtio_gpu_fence *fence); /* virtgpu_prime.c */ +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, + int flags); +int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj, + uuid_t *uuid); struct drm_gem_object *virtgpu_gem_prime_import_sg_table( struct drm_device *dev, struct dma_buf_attachment *attach, struct sg_table *sgt); diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 4009c2f97d08..5a2aeb6d2f35 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -134,6 +134,7 @@ int virtio_gpu_init(struct drm_device *dev) vgdev->dev = dev->dev; spin_lock_init(&vgdev->display_info_lock); + spin_lock_init(&vgdev->resource_export_lock); ida_init(&vgdev->ctx_id_ida); ida_init(&vgdev->resource_ida); init_waitqueue_head(&vgdev->resp_wq); @@ -162,6 +163,9 @@ int virtio_gpu_init(struct drm_device *dev) if (virtio_has_feature(vgdev->vdev, VIRTIO_RING_F_INDIRECT_DESC)) { vgdev->has_indirect = true; } + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { + vgdev->has_resource_assign_uuid = true; + } DRM_INFO("features: %cvirgl %cedid\n", vgdev->has_virgl_3d ? '+' : '-', diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c index 050d24c39a8f..7c6357f59877 100644 --- a/drivers/gpu/drm/virtio/virtgpu_prime.c +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c @@ -26,9 +26,44 @@ #include "virtgpu_drv.h" -/* Empty Implementations as there should not be any other driver for a virtual - * device that might share buffers with virtgpu - */ +int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj, + uuid_t *uuid) +{ + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); + struct virtio_gpu_device *vgdev = obj->dev->dev_private; + + wait_event(vgdev->resp_wq, bo->uuid_state != UUID_INITIALIZING); + if (bo->uuid_state != UUID_INITIALIZED) + return -ENODEV; + + uuid_copy(uuid, &bo->uuid); + + return 0; +} + +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, + int flags) +{ + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); + struct virtio_gpu_device *vgdev = obj->dev->dev_private; + struct virtio_gpu_object_array *objs; + int ret = 0; + + if (vgdev->has_resource_assign_uuid) { + objs = virtio_gpu_array_alloc(1); + if (!objs) + return ERR_PTR(-ENOMEM); + virtio_gpu_array_add_obj(objs, &bo->base.base); + + ret = virtio_gpu_cmd_resource_assign_uuid(vgdev, objs); + if (ret) + return ERR_PTR(ret); + } else { + bo->uuid_state = UUID_INITIALIZATION_FAILED; + } + + return drm_gem_prime_export(obj, flags); +} struct drm_gem_object *virtgpu_gem_prime_import_sg_table( struct drm_device *dev, struct dma_buf_attachment *attach, diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index cfe9c54f87a3..b968eaa46bb0 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -1111,3 +1111,58 @@ void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev, memcpy(cur_p, &output->cursor, sizeof(output->cursor)); virtio_gpu_queue_cursor(vgdev, vbuf); } + +static void virtio_gpu_cmd_resource_uuid_cb(struct virtio_gpu_device *vgdev, + struct virtio_gpu_vbuffer *vbuf) +{ + struct virtio_gpu_object *obj = + gem_to_virtio_gpu_obj(vbuf->objs->objs[0]); + struct virtio_gpu_resp_resource_uuid *resp = + (struct virtio_gpu_resp_resource_uuid *)vbuf->resp_buf; + uint32_t resp_type = le32_to_cpu(resp->hdr.type); + + spin_lock(&vgdev->resource_export_lock); + WARN_ON(obj->uuid_state != UUID_INITIALIZING); + + if (resp_type == VIRTIO_GPU_RESP_OK_RESOURCE_UUID && + obj->uuid_state == UUID_INITIALIZING) { + memcpy(&obj->uuid.b, resp->uuid, sizeof(obj->uuid.b)); + obj->uuid_state = UUID_INITIALIZED; + } else { + obj->uuid_state = UUID_INITIALIZATION_FAILED; + } + spin_unlock(&vgdev->resource_export_lock); + + wake_up_all(&vgdev->resp_wq); +} + +int +virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev, + struct virtio_gpu_object_array *objs) +{ + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(objs->objs[0]); + struct virtio_gpu_resource_assign_uuid *cmd_p; + struct virtio_gpu_vbuffer *vbuf; + struct virtio_gpu_resp_resource_uuid *resp_buf; + + resp_buf = kzalloc(sizeof(*resp_buf), GFP_KERNEL); + if (!resp_buf) { + spin_lock(&vgdev->resource_export_lock); + bo->uuid_state = UUID_INITIALIZATION_FAILED; + spin_unlock(&vgdev->resource_export_lock); + virtio_gpu_array_put_free(objs); + return -ENOMEM; + } + + cmd_p = virtio_gpu_alloc_cmd_resp(vgdev, + virtio_gpu_cmd_resource_uuid_cb, &vbuf, sizeof(*cmd_p), + sizeof(struct virtio_gpu_resp_resource_uuid), resp_buf); + memset(cmd_p, 0, sizeof(*cmd_p)); + + cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID); + cmd_p->resource_id = cpu_to_le32(bo->hw_res_handle); + + vbuf->objs = objs; + virtio_gpu_queue_ctrl_buffer(vgdev, vbuf); + return 0; +} -- 2.25.1.481.gfbce0eb801-goog --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-03-11 11:20 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-03-11 11:20 UTC (permalink / raw) To: Gerd Hoffmann, David Airlie Cc: dri-devel, virtio-dev, Thomas Zimmermann, Michael S . Tsirkin, Jason Wang, linux-kernel, virtualization, linaro-mm-sig, David Stevens, linux-media Add support for UUID-based resource sharing mechanism to virtgpu. This implements the new virtgpu commands and hooks them up to dma-buf's get_uuid callback. Signed-off-by: David Stevens <stevensd@chromium.org> --- drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++ drivers/gpu/drm/virtio/virtgpu_drv.h | 18 +++++++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++ drivers/gpu/drm/virtio/virtgpu_prime.c | 41 +++++++++++++++++-- drivers/gpu/drm/virtio/virtgpu_vq.c | 55 ++++++++++++++++++++++++++ 5 files changed, 118 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index ab4bed78e656..776e6667042e 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.c +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c @@ -165,6 +165,7 @@ static unsigned int features[] = { VIRTIO_GPU_F_VIRGL, #endif VIRTIO_GPU_F_EDID, + VIRTIO_GPU_F_RESOURCE_UUID, }; static struct virtio_driver virtio_gpu_driver = { .feature_table = features, @@ -202,7 +203,9 @@ static struct drm_driver driver = { .prime_handle_to_fd = drm_gem_prime_handle_to_fd, .prime_fd_to_handle = drm_gem_prime_fd_to_handle, .gem_prime_mmap = drm_gem_prime_mmap, + .gem_prime_export = virtgpu_gem_prime_export, .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table, + .gem_prime_get_uuid = virtgpu_gem_prime_get_uuid, .gem_create_object = virtio_gpu_create_object, .fops = &virtio_gpu_driver_fops, diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index af9403e1cf78..fab65f0f5a4d 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -49,6 +49,10 @@ #define DRIVER_MINOR 1 #define DRIVER_PATCHLEVEL 0 +#define UUID_INITIALIZING 0 +#define UUID_INITIALIZED 1 +#define UUID_INITIALIZATION_FAILED 2 + struct virtio_gpu_object_params { uint32_t format; uint32_t width; @@ -75,6 +79,9 @@ struct virtio_gpu_object { bool dumb; bool created; + + int uuid_state; + uuid_t uuid; }; #define gem_to_virtio_gpu_obj(gobj) \ container_of((gobj), struct virtio_gpu_object, base.base) @@ -196,6 +203,7 @@ struct virtio_gpu_device { bool has_virgl_3d; bool has_edid; bool has_indirect; + bool has_resource_assign_uuid; struct work_struct config_changed_work; @@ -206,6 +214,8 @@ struct virtio_gpu_device { struct virtio_gpu_drv_capset *capsets; uint32_t num_capsets; struct list_head cap_cache; + + spinlock_t resource_export_lock; }; struct virtio_gpu_fpriv { @@ -338,6 +348,10 @@ void virtio_gpu_dequeue_fence_func(struct work_struct *work); void virtio_gpu_disable_notify(struct virtio_gpu_device *vgdev); void virtio_gpu_enable_notify(struct virtio_gpu_device *vgdev); +int +virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev, + struct virtio_gpu_object_array *objs); + /* virtio_gpu_display.c */ void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev); void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev); @@ -366,6 +380,10 @@ int virtio_gpu_object_create(struct virtio_gpu_device *vgdev, struct virtio_gpu_object **bo_ptr, struct virtio_gpu_fence *fence); /* virtgpu_prime.c */ +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, + int flags); +int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj, + uuid_t *uuid); struct drm_gem_object *virtgpu_gem_prime_import_sg_table( struct drm_device *dev, struct dma_buf_attachment *attach, struct sg_table *sgt); diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 4009c2f97d08..5a2aeb6d2f35 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -134,6 +134,7 @@ int virtio_gpu_init(struct drm_device *dev) vgdev->dev = dev->dev; spin_lock_init(&vgdev->display_info_lock); + spin_lock_init(&vgdev->resource_export_lock); ida_init(&vgdev->ctx_id_ida); ida_init(&vgdev->resource_ida); init_waitqueue_head(&vgdev->resp_wq); @@ -162,6 +163,9 @@ int virtio_gpu_init(struct drm_device *dev) if (virtio_has_feature(vgdev->vdev, VIRTIO_RING_F_INDIRECT_DESC)) { vgdev->has_indirect = true; } + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { + vgdev->has_resource_assign_uuid = true; + } DRM_INFO("features: %cvirgl %cedid\n", vgdev->has_virgl_3d ? '+' : '-', diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c index 050d24c39a8f..7c6357f59877 100644 --- a/drivers/gpu/drm/virtio/virtgpu_prime.c +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c @@ -26,9 +26,44 @@ #include "virtgpu_drv.h" -/* Empty Implementations as there should not be any other driver for a virtual - * device that might share buffers with virtgpu - */ +int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj, + uuid_t *uuid) +{ + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); + struct virtio_gpu_device *vgdev = obj->dev->dev_private; + + wait_event(vgdev->resp_wq, bo->uuid_state != UUID_INITIALIZING); + if (bo->uuid_state != UUID_INITIALIZED) + return -ENODEV; + + uuid_copy(uuid, &bo->uuid); + + return 0; +} + +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, + int flags) +{ + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); + struct virtio_gpu_device *vgdev = obj->dev->dev_private; + struct virtio_gpu_object_array *objs; + int ret = 0; + + if (vgdev->has_resource_assign_uuid) { + objs = virtio_gpu_array_alloc(1); + if (!objs) + return ERR_PTR(-ENOMEM); + virtio_gpu_array_add_obj(objs, &bo->base.base); + + ret = virtio_gpu_cmd_resource_assign_uuid(vgdev, objs); + if (ret) + return ERR_PTR(ret); + } else { + bo->uuid_state = UUID_INITIALIZATION_FAILED; + } + + return drm_gem_prime_export(obj, flags); +} struct drm_gem_object *virtgpu_gem_prime_import_sg_table( struct drm_device *dev, struct dma_buf_attachment *attach, diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index cfe9c54f87a3..b968eaa46bb0 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -1111,3 +1111,58 @@ void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev, memcpy(cur_p, &output->cursor, sizeof(output->cursor)); virtio_gpu_queue_cursor(vgdev, vbuf); } + +static void virtio_gpu_cmd_resource_uuid_cb(struct virtio_gpu_device *vgdev, + struct virtio_gpu_vbuffer *vbuf) +{ + struct virtio_gpu_object *obj = + gem_to_virtio_gpu_obj(vbuf->objs->objs[0]); + struct virtio_gpu_resp_resource_uuid *resp = + (struct virtio_gpu_resp_resource_uuid *)vbuf->resp_buf; + uint32_t resp_type = le32_to_cpu(resp->hdr.type); + + spin_lock(&vgdev->resource_export_lock); + WARN_ON(obj->uuid_state != UUID_INITIALIZING); + + if (resp_type == VIRTIO_GPU_RESP_OK_RESOURCE_UUID && + obj->uuid_state == UUID_INITIALIZING) { + memcpy(&obj->uuid.b, resp->uuid, sizeof(obj->uuid.b)); + obj->uuid_state = UUID_INITIALIZED; + } else { + obj->uuid_state = UUID_INITIALIZATION_FAILED; + } + spin_unlock(&vgdev->resource_export_lock); + + wake_up_all(&vgdev->resp_wq); +} + +int +virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev, + struct virtio_gpu_object_array *objs) +{ + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(objs->objs[0]); + struct virtio_gpu_resource_assign_uuid *cmd_p; + struct virtio_gpu_vbuffer *vbuf; + struct virtio_gpu_resp_resource_uuid *resp_buf; + + resp_buf = kzalloc(sizeof(*resp_buf), GFP_KERNEL); + if (!resp_buf) { + spin_lock(&vgdev->resource_export_lock); + bo->uuid_state = UUID_INITIALIZATION_FAILED; + spin_unlock(&vgdev->resource_export_lock); + virtio_gpu_array_put_free(objs); + return -ENOMEM; + } + + cmd_p = virtio_gpu_alloc_cmd_resp(vgdev, + virtio_gpu_cmd_resource_uuid_cb, &vbuf, sizeof(*cmd_p), + sizeof(struct virtio_gpu_resp_resource_uuid), resp_buf); + memset(cmd_p, 0, sizeof(*cmd_p)); + + cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID); + cmd_p->resource_id = cpu_to_le32(bo->hw_res_handle); + + vbuf->objs = objs; + virtio_gpu_queue_ctrl_buffer(vgdev, vbuf); + return 0; +} -- 2.25.1.481.gfbce0eb801-goog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources 2020-03-11 11:20 ` David Stevens (?) @ 2020-05-13 16:34 ` Michael S. Tsirkin -1 siblings, 0 replies; 71+ messages in thread From: Michael S. Tsirkin @ 2020-05-13 16:34 UTC (permalink / raw) To: David Stevens Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, linux-kernel, dri-devel, virtualization, linux-media, linaro-mm-sig, virtio-dev On Wed, Mar 11, 2020 at 08:20:04PM +0900, David Stevens wrote: > Add support for UUID-based resource sharing mechanism to virtgpu. This > implements the new virtgpu commands and hooks them up to dma-buf's > get_uuid callback. > > Signed-off-by: David Stevens <stevensd@chromium.org> > --- > drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++ > drivers/gpu/drm/virtio/virtgpu_drv.h | 18 +++++++++ > drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++ > drivers/gpu/drm/virtio/virtgpu_prime.c | 41 +++++++++++++++++-- > drivers/gpu/drm/virtio/virtgpu_vq.c | 55 ++++++++++++++++++++++++++ > 5 files changed, 118 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c > index ab4bed78e656..776e6667042e 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c > @@ -165,6 +165,7 @@ static unsigned int features[] = { > VIRTIO_GPU_F_VIRGL, > #endif > VIRTIO_GPU_F_EDID, > + VIRTIO_GPU_F_RESOURCE_UUID, > }; > static struct virtio_driver virtio_gpu_driver = { > .feature_table = features, > @@ -202,7 +203,9 @@ static struct drm_driver driver = { > .prime_handle_to_fd = drm_gem_prime_handle_to_fd, > .prime_fd_to_handle = drm_gem_prime_fd_to_handle, > .gem_prime_mmap = drm_gem_prime_mmap, > + .gem_prime_export = virtgpu_gem_prime_export, > .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table, > + .gem_prime_get_uuid = virtgpu_gem_prime_get_uuid, > > .gem_create_object = virtio_gpu_create_object, > .fops = &virtio_gpu_driver_fops, > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h > index af9403e1cf78..fab65f0f5a4d 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h > @@ -49,6 +49,10 @@ > #define DRIVER_MINOR 1 > #define DRIVER_PATCHLEVEL 0 > > +#define UUID_INITIALIZING 0 > +#define UUID_INITIALIZED 1 > +#define UUID_INITIALIZATION_FAILED 2 > + > struct virtio_gpu_object_params { > uint32_t format; > uint32_t width; > @@ -75,6 +79,9 @@ struct virtio_gpu_object { > > bool dumb; > bool created; > + > + int uuid_state; > + uuid_t uuid; > }; > #define gem_to_virtio_gpu_obj(gobj) \ > container_of((gobj), struct virtio_gpu_object, base.base) > @@ -196,6 +203,7 @@ struct virtio_gpu_device { > bool has_virgl_3d; > bool has_edid; > bool has_indirect; > + bool has_resource_assign_uuid; > > struct work_struct config_changed_work; > > @@ -206,6 +214,8 @@ struct virtio_gpu_device { > struct virtio_gpu_drv_capset *capsets; > uint32_t num_capsets; > struct list_head cap_cache; > + > + spinlock_t resource_export_lock; > }; > > struct virtio_gpu_fpriv { > @@ -338,6 +348,10 @@ void virtio_gpu_dequeue_fence_func(struct work_struct *work); > void virtio_gpu_disable_notify(struct virtio_gpu_device *vgdev); > void virtio_gpu_enable_notify(struct virtio_gpu_device *vgdev); > > +int > +virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev, > + struct virtio_gpu_object_array *objs); > + > /* virtio_gpu_display.c */ > void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev); > void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev); > @@ -366,6 +380,10 @@ int virtio_gpu_object_create(struct virtio_gpu_device *vgdev, > struct virtio_gpu_object **bo_ptr, > struct virtio_gpu_fence *fence); > /* virtgpu_prime.c */ > +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, > + int flags); > +int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj, > + uuid_t *uuid); > struct drm_gem_object *virtgpu_gem_prime_import_sg_table( > struct drm_device *dev, struct dma_buf_attachment *attach, > struct sg_table *sgt); > diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c > index 4009c2f97d08..5a2aeb6d2f35 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_kms.c > +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c > @@ -134,6 +134,7 @@ int virtio_gpu_init(struct drm_device *dev) > vgdev->dev = dev->dev; > > spin_lock_init(&vgdev->display_info_lock); > + spin_lock_init(&vgdev->resource_export_lock); > ida_init(&vgdev->ctx_id_ida); > ida_init(&vgdev->resource_ida); > init_waitqueue_head(&vgdev->resp_wq); > @@ -162,6 +163,9 @@ int virtio_gpu_init(struct drm_device *dev) > if (virtio_has_feature(vgdev->vdev, VIRTIO_RING_F_INDIRECT_DESC)) { > vgdev->has_indirect = true; > } > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > + vgdev->has_resource_assign_uuid = true; > + } Just a question: this relies on DMA bufs so I assume it is not really assumed to work when DMA API is bypassed, right? Rather than worry what does it mean, how about just disabling this feature without PLATFORM_DMA for now? > > DRM_INFO("features: %cvirgl %cedid\n", > vgdev->has_virgl_3d ? '+' : '-', > diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c > index 050d24c39a8f..7c6357f59877 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_prime.c > +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c > @@ -26,9 +26,44 @@ > > #include "virtgpu_drv.h" > > -/* Empty Implementations as there should not be any other driver for a virtual > - * device that might share buffers with virtgpu > - */ > +int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj, > + uuid_t *uuid) > +{ > + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); > + struct virtio_gpu_device *vgdev = obj->dev->dev_private; > + > + wait_event(vgdev->resp_wq, bo->uuid_state != UUID_INITIALIZING); > + if (bo->uuid_state != UUID_INITIALIZED) > + return -ENODEV; > + > + uuid_copy(uuid, &bo->uuid); > + > + return 0; > +} > + > +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, > + int flags) > +{ > + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); > + struct virtio_gpu_device *vgdev = obj->dev->dev_private; > + struct virtio_gpu_object_array *objs; > + int ret = 0; > + > + if (vgdev->has_resource_assign_uuid) { > + objs = virtio_gpu_array_alloc(1); > + if (!objs) > + return ERR_PTR(-ENOMEM); > + virtio_gpu_array_add_obj(objs, &bo->base.base); > + > + ret = virtio_gpu_cmd_resource_assign_uuid(vgdev, objs); > + if (ret) > + return ERR_PTR(ret); > + } else { > + bo->uuid_state = UUID_INITIALIZATION_FAILED; > + } > + > + return drm_gem_prime_export(obj, flags); > +} > > struct drm_gem_object *virtgpu_gem_prime_import_sg_table( > struct drm_device *dev, struct dma_buf_attachment *attach, > diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c > index cfe9c54f87a3..b968eaa46bb0 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_vq.c > +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c > @@ -1111,3 +1111,58 @@ void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev, > memcpy(cur_p, &output->cursor, sizeof(output->cursor)); > virtio_gpu_queue_cursor(vgdev, vbuf); > } > + > +static void virtio_gpu_cmd_resource_uuid_cb(struct virtio_gpu_device *vgdev, > + struct virtio_gpu_vbuffer *vbuf) > +{ > + struct virtio_gpu_object *obj = > + gem_to_virtio_gpu_obj(vbuf->objs->objs[0]); > + struct virtio_gpu_resp_resource_uuid *resp = > + (struct virtio_gpu_resp_resource_uuid *)vbuf->resp_buf; > + uint32_t resp_type = le32_to_cpu(resp->hdr.type); > + > + spin_lock(&vgdev->resource_export_lock); > + WARN_ON(obj->uuid_state != UUID_INITIALIZING); > + > + if (resp_type == VIRTIO_GPU_RESP_OK_RESOURCE_UUID && > + obj->uuid_state == UUID_INITIALIZING) { > + memcpy(&obj->uuid.b, resp->uuid, sizeof(obj->uuid.b)); > + obj->uuid_state = UUID_INITIALIZED; > + } else { > + obj->uuid_state = UUID_INITIALIZATION_FAILED; > + } > + spin_unlock(&vgdev->resource_export_lock); > + > + wake_up_all(&vgdev->resp_wq); > +} > + > +int > +virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev, > + struct virtio_gpu_object_array *objs) > +{ > + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(objs->objs[0]); > + struct virtio_gpu_resource_assign_uuid *cmd_p; > + struct virtio_gpu_vbuffer *vbuf; > + struct virtio_gpu_resp_resource_uuid *resp_buf; > + > + resp_buf = kzalloc(sizeof(*resp_buf), GFP_KERNEL); > + if (!resp_buf) { > + spin_lock(&vgdev->resource_export_lock); > + bo->uuid_state = UUID_INITIALIZATION_FAILED; > + spin_unlock(&vgdev->resource_export_lock); > + virtio_gpu_array_put_free(objs); > + return -ENOMEM; > + } > + > + cmd_p = virtio_gpu_alloc_cmd_resp(vgdev, > + virtio_gpu_cmd_resource_uuid_cb, &vbuf, sizeof(*cmd_p), > + sizeof(struct virtio_gpu_resp_resource_uuid), resp_buf); > + memset(cmd_p, 0, sizeof(*cmd_p)); > + > + cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID); > + cmd_p->resource_id = cpu_to_le32(bo->hw_res_handle); > + > + vbuf->objs = objs; > + virtio_gpu_queue_ctrl_buffer(vgdev, vbuf); > + return 0; > +} > -- > 2.25.1.481.gfbce0eb801-goog ^ permalink raw reply [flat|nested] 71+ messages in thread
* [virtio-dev] Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-05-13 16:34 ` Michael S. Tsirkin 0 siblings, 0 replies; 71+ messages in thread From: Michael S. Tsirkin @ 2020-05-13 16:34 UTC (permalink / raw) To: David Stevens Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, linux-kernel, dri-devel, virtualization, linux-media, linaro-mm-sig, virtio-dev On Wed, Mar 11, 2020 at 08:20:04PM +0900, David Stevens wrote: > Add support for UUID-based resource sharing mechanism to virtgpu. This > implements the new virtgpu commands and hooks them up to dma-buf's > get_uuid callback. > > Signed-off-by: David Stevens <stevensd@chromium.org> > --- > drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++ > drivers/gpu/drm/virtio/virtgpu_drv.h | 18 +++++++++ > drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++ > drivers/gpu/drm/virtio/virtgpu_prime.c | 41 +++++++++++++++++-- > drivers/gpu/drm/virtio/virtgpu_vq.c | 55 ++++++++++++++++++++++++++ > 5 files changed, 118 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c > index ab4bed78e656..776e6667042e 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c > @@ -165,6 +165,7 @@ static unsigned int features[] = { > VIRTIO_GPU_F_VIRGL, > #endif > VIRTIO_GPU_F_EDID, > + VIRTIO_GPU_F_RESOURCE_UUID, > }; > static struct virtio_driver virtio_gpu_driver = { > .feature_table = features, > @@ -202,7 +203,9 @@ static struct drm_driver driver = { > .prime_handle_to_fd = drm_gem_prime_handle_to_fd, > .prime_fd_to_handle = drm_gem_prime_fd_to_handle, > .gem_prime_mmap = drm_gem_prime_mmap, > + .gem_prime_export = virtgpu_gem_prime_export, > .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table, > + .gem_prime_get_uuid = virtgpu_gem_prime_get_uuid, > > .gem_create_object = virtio_gpu_create_object, > .fops = &virtio_gpu_driver_fops, > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h > index af9403e1cf78..fab65f0f5a4d 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h > @@ -49,6 +49,10 @@ > #define DRIVER_MINOR 1 > #define DRIVER_PATCHLEVEL 0 > > +#define UUID_INITIALIZING 0 > +#define UUID_INITIALIZED 1 > +#define UUID_INITIALIZATION_FAILED 2 > + > struct virtio_gpu_object_params { > uint32_t format; > uint32_t width; > @@ -75,6 +79,9 @@ struct virtio_gpu_object { > > bool dumb; > bool created; > + > + int uuid_state; > + uuid_t uuid; > }; > #define gem_to_virtio_gpu_obj(gobj) \ > container_of((gobj), struct virtio_gpu_object, base.base) > @@ -196,6 +203,7 @@ struct virtio_gpu_device { > bool has_virgl_3d; > bool has_edid; > bool has_indirect; > + bool has_resource_assign_uuid; > > struct work_struct config_changed_work; > > @@ -206,6 +214,8 @@ struct virtio_gpu_device { > struct virtio_gpu_drv_capset *capsets; > uint32_t num_capsets; > struct list_head cap_cache; > + > + spinlock_t resource_export_lock; > }; > > struct virtio_gpu_fpriv { > @@ -338,6 +348,10 @@ void virtio_gpu_dequeue_fence_func(struct work_struct *work); > void virtio_gpu_disable_notify(struct virtio_gpu_device *vgdev); > void virtio_gpu_enable_notify(struct virtio_gpu_device *vgdev); > > +int > +virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev, > + struct virtio_gpu_object_array *objs); > + > /* virtio_gpu_display.c */ > void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev); > void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev); > @@ -366,6 +380,10 @@ int virtio_gpu_object_create(struct virtio_gpu_device *vgdev, > struct virtio_gpu_object **bo_ptr, > struct virtio_gpu_fence *fence); > /* virtgpu_prime.c */ > +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, > + int flags); > +int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj, > + uuid_t *uuid); > struct drm_gem_object *virtgpu_gem_prime_import_sg_table( > struct drm_device *dev, struct dma_buf_attachment *attach, > struct sg_table *sgt); > diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c > index 4009c2f97d08..5a2aeb6d2f35 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_kms.c > +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c > @@ -134,6 +134,7 @@ int virtio_gpu_init(struct drm_device *dev) > vgdev->dev = dev->dev; > > spin_lock_init(&vgdev->display_info_lock); > + spin_lock_init(&vgdev->resource_export_lock); > ida_init(&vgdev->ctx_id_ida); > ida_init(&vgdev->resource_ida); > init_waitqueue_head(&vgdev->resp_wq); > @@ -162,6 +163,9 @@ int virtio_gpu_init(struct drm_device *dev) > if (virtio_has_feature(vgdev->vdev, VIRTIO_RING_F_INDIRECT_DESC)) { > vgdev->has_indirect = true; > } > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > + vgdev->has_resource_assign_uuid = true; > + } Just a question: this relies on DMA bufs so I assume it is not really assumed to work when DMA API is bypassed, right? Rather than worry what does it mean, how about just disabling this feature without PLATFORM_DMA for now? > > DRM_INFO("features: %cvirgl %cedid\n", > vgdev->has_virgl_3d ? '+' : '-', > diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c > index 050d24c39a8f..7c6357f59877 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_prime.c > +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c > @@ -26,9 +26,44 @@ > > #include "virtgpu_drv.h" > > -/* Empty Implementations as there should not be any other driver for a virtual > - * device that might share buffers with virtgpu > - */ > +int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj, > + uuid_t *uuid) > +{ > + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); > + struct virtio_gpu_device *vgdev = obj->dev->dev_private; > + > + wait_event(vgdev->resp_wq, bo->uuid_state != UUID_INITIALIZING); > + if (bo->uuid_state != UUID_INITIALIZED) > + return -ENODEV; > + > + uuid_copy(uuid, &bo->uuid); > + > + return 0; > +} > + > +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, > + int flags) > +{ > + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); > + struct virtio_gpu_device *vgdev = obj->dev->dev_private; > + struct virtio_gpu_object_array *objs; > + int ret = 0; > + > + if (vgdev->has_resource_assign_uuid) { > + objs = virtio_gpu_array_alloc(1); > + if (!objs) > + return ERR_PTR(-ENOMEM); > + virtio_gpu_array_add_obj(objs, &bo->base.base); > + > + ret = virtio_gpu_cmd_resource_assign_uuid(vgdev, objs); > + if (ret) > + return ERR_PTR(ret); > + } else { > + bo->uuid_state = UUID_INITIALIZATION_FAILED; > + } > + > + return drm_gem_prime_export(obj, flags); > +} > > struct drm_gem_object *virtgpu_gem_prime_import_sg_table( > struct drm_device *dev, struct dma_buf_attachment *attach, > diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c > index cfe9c54f87a3..b968eaa46bb0 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_vq.c > +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c > @@ -1111,3 +1111,58 @@ void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev, > memcpy(cur_p, &output->cursor, sizeof(output->cursor)); > virtio_gpu_queue_cursor(vgdev, vbuf); > } > + > +static void virtio_gpu_cmd_resource_uuid_cb(struct virtio_gpu_device *vgdev, > + struct virtio_gpu_vbuffer *vbuf) > +{ > + struct virtio_gpu_object *obj = > + gem_to_virtio_gpu_obj(vbuf->objs->objs[0]); > + struct virtio_gpu_resp_resource_uuid *resp = > + (struct virtio_gpu_resp_resource_uuid *)vbuf->resp_buf; > + uint32_t resp_type = le32_to_cpu(resp->hdr.type); > + > + spin_lock(&vgdev->resource_export_lock); > + WARN_ON(obj->uuid_state != UUID_INITIALIZING); > + > + if (resp_type == VIRTIO_GPU_RESP_OK_RESOURCE_UUID && > + obj->uuid_state == UUID_INITIALIZING) { > + memcpy(&obj->uuid.b, resp->uuid, sizeof(obj->uuid.b)); > + obj->uuid_state = UUID_INITIALIZED; > + } else { > + obj->uuid_state = UUID_INITIALIZATION_FAILED; > + } > + spin_unlock(&vgdev->resource_export_lock); > + > + wake_up_all(&vgdev->resp_wq); > +} > + > +int > +virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev, > + struct virtio_gpu_object_array *objs) > +{ > + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(objs->objs[0]); > + struct virtio_gpu_resource_assign_uuid *cmd_p; > + struct virtio_gpu_vbuffer *vbuf; > + struct virtio_gpu_resp_resource_uuid *resp_buf; > + > + resp_buf = kzalloc(sizeof(*resp_buf), GFP_KERNEL); > + if (!resp_buf) { > + spin_lock(&vgdev->resource_export_lock); > + bo->uuid_state = UUID_INITIALIZATION_FAILED; > + spin_unlock(&vgdev->resource_export_lock); > + virtio_gpu_array_put_free(objs); > + return -ENOMEM; > + } > + > + cmd_p = virtio_gpu_alloc_cmd_resp(vgdev, > + virtio_gpu_cmd_resource_uuid_cb, &vbuf, sizeof(*cmd_p), > + sizeof(struct virtio_gpu_resp_resource_uuid), resp_buf); > + memset(cmd_p, 0, sizeof(*cmd_p)); > + > + cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID); > + cmd_p->resource_id = cpu_to_le32(bo->hw_res_handle); > + > + vbuf->objs = objs; > + virtio_gpu_queue_ctrl_buffer(vgdev, vbuf); > + return 0; > +} > -- > 2.25.1.481.gfbce0eb801-goog --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-05-13 16:34 ` Michael S. Tsirkin 0 siblings, 0 replies; 71+ messages in thread From: Michael S. Tsirkin @ 2020-05-13 16:34 UTC (permalink / raw) To: David Stevens Cc: dri-devel, virtio-dev, Thomas Zimmermann, David Airlie, Jason Wang, linux-kernel, virtualization, linaro-mm-sig, Gerd Hoffmann, linux-media On Wed, Mar 11, 2020 at 08:20:04PM +0900, David Stevens wrote: > Add support for UUID-based resource sharing mechanism to virtgpu. This > implements the new virtgpu commands and hooks them up to dma-buf's > get_uuid callback. > > Signed-off-by: David Stevens <stevensd@chromium.org> > --- > drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++ > drivers/gpu/drm/virtio/virtgpu_drv.h | 18 +++++++++ > drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++ > drivers/gpu/drm/virtio/virtgpu_prime.c | 41 +++++++++++++++++-- > drivers/gpu/drm/virtio/virtgpu_vq.c | 55 ++++++++++++++++++++++++++ > 5 files changed, 118 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c > index ab4bed78e656..776e6667042e 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c > @@ -165,6 +165,7 @@ static unsigned int features[] = { > VIRTIO_GPU_F_VIRGL, > #endif > VIRTIO_GPU_F_EDID, > + VIRTIO_GPU_F_RESOURCE_UUID, > }; > static struct virtio_driver virtio_gpu_driver = { > .feature_table = features, > @@ -202,7 +203,9 @@ static struct drm_driver driver = { > .prime_handle_to_fd = drm_gem_prime_handle_to_fd, > .prime_fd_to_handle = drm_gem_prime_fd_to_handle, > .gem_prime_mmap = drm_gem_prime_mmap, > + .gem_prime_export = virtgpu_gem_prime_export, > .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table, > + .gem_prime_get_uuid = virtgpu_gem_prime_get_uuid, > > .gem_create_object = virtio_gpu_create_object, > .fops = &virtio_gpu_driver_fops, > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h > index af9403e1cf78..fab65f0f5a4d 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h > @@ -49,6 +49,10 @@ > #define DRIVER_MINOR 1 > #define DRIVER_PATCHLEVEL 0 > > +#define UUID_INITIALIZING 0 > +#define UUID_INITIALIZED 1 > +#define UUID_INITIALIZATION_FAILED 2 > + > struct virtio_gpu_object_params { > uint32_t format; > uint32_t width; > @@ -75,6 +79,9 @@ struct virtio_gpu_object { > > bool dumb; > bool created; > + > + int uuid_state; > + uuid_t uuid; > }; > #define gem_to_virtio_gpu_obj(gobj) \ > container_of((gobj), struct virtio_gpu_object, base.base) > @@ -196,6 +203,7 @@ struct virtio_gpu_device { > bool has_virgl_3d; > bool has_edid; > bool has_indirect; > + bool has_resource_assign_uuid; > > struct work_struct config_changed_work; > > @@ -206,6 +214,8 @@ struct virtio_gpu_device { > struct virtio_gpu_drv_capset *capsets; > uint32_t num_capsets; > struct list_head cap_cache; > + > + spinlock_t resource_export_lock; > }; > > struct virtio_gpu_fpriv { > @@ -338,6 +348,10 @@ void virtio_gpu_dequeue_fence_func(struct work_struct *work); > void virtio_gpu_disable_notify(struct virtio_gpu_device *vgdev); > void virtio_gpu_enable_notify(struct virtio_gpu_device *vgdev); > > +int > +virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev, > + struct virtio_gpu_object_array *objs); > + > /* virtio_gpu_display.c */ > void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev); > void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev); > @@ -366,6 +380,10 @@ int virtio_gpu_object_create(struct virtio_gpu_device *vgdev, > struct virtio_gpu_object **bo_ptr, > struct virtio_gpu_fence *fence); > /* virtgpu_prime.c */ > +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, > + int flags); > +int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj, > + uuid_t *uuid); > struct drm_gem_object *virtgpu_gem_prime_import_sg_table( > struct drm_device *dev, struct dma_buf_attachment *attach, > struct sg_table *sgt); > diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c > index 4009c2f97d08..5a2aeb6d2f35 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_kms.c > +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c > @@ -134,6 +134,7 @@ int virtio_gpu_init(struct drm_device *dev) > vgdev->dev = dev->dev; > > spin_lock_init(&vgdev->display_info_lock); > + spin_lock_init(&vgdev->resource_export_lock); > ida_init(&vgdev->ctx_id_ida); > ida_init(&vgdev->resource_ida); > init_waitqueue_head(&vgdev->resp_wq); > @@ -162,6 +163,9 @@ int virtio_gpu_init(struct drm_device *dev) > if (virtio_has_feature(vgdev->vdev, VIRTIO_RING_F_INDIRECT_DESC)) { > vgdev->has_indirect = true; > } > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > + vgdev->has_resource_assign_uuid = true; > + } Just a question: this relies on DMA bufs so I assume it is not really assumed to work when DMA API is bypassed, right? Rather than worry what does it mean, how about just disabling this feature without PLATFORM_DMA for now? > > DRM_INFO("features: %cvirgl %cedid\n", > vgdev->has_virgl_3d ? '+' : '-', > diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c > index 050d24c39a8f..7c6357f59877 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_prime.c > +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c > @@ -26,9 +26,44 @@ > > #include "virtgpu_drv.h" > > -/* Empty Implementations as there should not be any other driver for a virtual > - * device that might share buffers with virtgpu > - */ > +int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj, > + uuid_t *uuid) > +{ > + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); > + struct virtio_gpu_device *vgdev = obj->dev->dev_private; > + > + wait_event(vgdev->resp_wq, bo->uuid_state != UUID_INITIALIZING); > + if (bo->uuid_state != UUID_INITIALIZED) > + return -ENODEV; > + > + uuid_copy(uuid, &bo->uuid); > + > + return 0; > +} > + > +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, > + int flags) > +{ > + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); > + struct virtio_gpu_device *vgdev = obj->dev->dev_private; > + struct virtio_gpu_object_array *objs; > + int ret = 0; > + > + if (vgdev->has_resource_assign_uuid) { > + objs = virtio_gpu_array_alloc(1); > + if (!objs) > + return ERR_PTR(-ENOMEM); > + virtio_gpu_array_add_obj(objs, &bo->base.base); > + > + ret = virtio_gpu_cmd_resource_assign_uuid(vgdev, objs); > + if (ret) > + return ERR_PTR(ret); > + } else { > + bo->uuid_state = UUID_INITIALIZATION_FAILED; > + } > + > + return drm_gem_prime_export(obj, flags); > +} > > struct drm_gem_object *virtgpu_gem_prime_import_sg_table( > struct drm_device *dev, struct dma_buf_attachment *attach, > diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c > index cfe9c54f87a3..b968eaa46bb0 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_vq.c > +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c > @@ -1111,3 +1111,58 @@ void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev, > memcpy(cur_p, &output->cursor, sizeof(output->cursor)); > virtio_gpu_queue_cursor(vgdev, vbuf); > } > + > +static void virtio_gpu_cmd_resource_uuid_cb(struct virtio_gpu_device *vgdev, > + struct virtio_gpu_vbuffer *vbuf) > +{ > + struct virtio_gpu_object *obj = > + gem_to_virtio_gpu_obj(vbuf->objs->objs[0]); > + struct virtio_gpu_resp_resource_uuid *resp = > + (struct virtio_gpu_resp_resource_uuid *)vbuf->resp_buf; > + uint32_t resp_type = le32_to_cpu(resp->hdr.type); > + > + spin_lock(&vgdev->resource_export_lock); > + WARN_ON(obj->uuid_state != UUID_INITIALIZING); > + > + if (resp_type == VIRTIO_GPU_RESP_OK_RESOURCE_UUID && > + obj->uuid_state == UUID_INITIALIZING) { > + memcpy(&obj->uuid.b, resp->uuid, sizeof(obj->uuid.b)); > + obj->uuid_state = UUID_INITIALIZED; > + } else { > + obj->uuid_state = UUID_INITIALIZATION_FAILED; > + } > + spin_unlock(&vgdev->resource_export_lock); > + > + wake_up_all(&vgdev->resp_wq); > +} > + > +int > +virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev, > + struct virtio_gpu_object_array *objs) > +{ > + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(objs->objs[0]); > + struct virtio_gpu_resource_assign_uuid *cmd_p; > + struct virtio_gpu_vbuffer *vbuf; > + struct virtio_gpu_resp_resource_uuid *resp_buf; > + > + resp_buf = kzalloc(sizeof(*resp_buf), GFP_KERNEL); > + if (!resp_buf) { > + spin_lock(&vgdev->resource_export_lock); > + bo->uuid_state = UUID_INITIALIZATION_FAILED; > + spin_unlock(&vgdev->resource_export_lock); > + virtio_gpu_array_put_free(objs); > + return -ENOMEM; > + } > + > + cmd_p = virtio_gpu_alloc_cmd_resp(vgdev, > + virtio_gpu_cmd_resource_uuid_cb, &vbuf, sizeof(*cmd_p), > + sizeof(struct virtio_gpu_resp_resource_uuid), resp_buf); > + memset(cmd_p, 0, sizeof(*cmd_p)); > + > + cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID); > + cmd_p->resource_id = cpu_to_le32(bo->hw_res_handle); > + > + vbuf->objs = objs; > + virtio_gpu_queue_ctrl_buffer(vgdev, vbuf); > + return 0; > +} > -- > 2.25.1.481.gfbce0eb801-goog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources 2020-05-13 16:34 ` Michael S. Tsirkin (?) (?) @ 2020-05-15 7:26 ` David Stevens -1 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-15 7:26 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, open list, ML dri-devel, open list:VIRTIO GPU DRIVER, Linux Media Mailing List, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > + vgdev->has_resource_assign_uuid = true; > > + } > > > Just a question: this relies on DMA bufs so I assume it is > not really assumed to work when DMA API is bypassed, right? > Rather than worry what does it mean, how about just > disabling this feature without PLATFORM_DMA for now? By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? Virtio-gpu depends on DRM, which selects that feature. So I think DMA bufs should always be available when virtio-gpu is present. -David ^ permalink raw reply [flat|nested] 71+ messages in thread
* [virtio-dev] Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-05-15 7:26 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-15 7:26 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, open list, ML dri-devel, open list:VIRTIO GPU DRIVER, Linux Media Mailing List, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > + vgdev->has_resource_assign_uuid = true; > > + } > > > Just a question: this relies on DMA bufs so I assume it is > not really assumed to work when DMA API is bypassed, right? > Rather than worry what does it mean, how about just > disabling this feature without PLATFORM_DMA for now? By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? Virtio-gpu depends on DRM, which selects that feature. So I think DMA bufs should always be available when virtio-gpu is present. -David --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-05-15 7:26 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-15 7:26 UTC (permalink / raw) To: Michael S. Tsirkin Cc: ML dri-devel, virtio-dev, Thomas Zimmermann, David Airlie, Jason Wang, open list, open list:VIRTIO GPU DRIVER, moderated list:DMA BUFFER SHARING FRAMEWORK, Gerd Hoffmann, Linux Media Mailing List > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > + vgdev->has_resource_assign_uuid = true; > > + } > > > Just a question: this relies on DMA bufs so I assume it is > not really assumed to work when DMA API is bypassed, right? > Rather than worry what does it mean, how about just > disabling this feature without PLATFORM_DMA for now? By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? Virtio-gpu depends on DRM, which selects that feature. So I think DMA bufs should always be available when virtio-gpu is present. -David _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-05-15 7:26 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-05-15 7:26 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, open list, ML dri-devel, open list:VIRTIO GPU DRIVER, Linux Media Mailing List, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > + vgdev->has_resource_assign_uuid = true; > > + } > > > Just a question: this relies on DMA bufs so I assume it is > not really assumed to work when DMA API is bypassed, right? > Rather than worry what does it mean, how about just > disabling this feature without PLATFORM_DMA for now? By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? Virtio-gpu depends on DRM, which selects that feature. So I think DMA bufs should always be available when virtio-gpu is present. -David ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources 2020-05-15 7:26 ` David Stevens (?) (?) @ 2020-06-08 9:43 ` Michael S. Tsirkin -1 siblings, 0 replies; 71+ messages in thread From: Michael S. Tsirkin @ 2020-06-08 9:43 UTC (permalink / raw) To: David Stevens Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, open list, ML dri-devel, open list:VIRTIO GPU DRIVER, Linux Media Mailing List, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote: > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > > + vgdev->has_resource_assign_uuid = true; > > > + } > > > > > > Just a question: this relies on DMA bufs so I assume it is > > not really assumed to work when DMA API is bypassed, right? > > Rather than worry what does it mean, how about just > > disabling this feature without PLATFORM_DMA for now? > > By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? Sorry, no. I mean VIRTIO_F_IOMMU_PLATFORM which in the future will be renamed to VIRTIO_F_PLATFORM_ACCESS. > Virtio-gpu > depends on DRM, which selects that feature. So I think DMA bufs should > always be available when virtio-gpu is present. > > -David ^ permalink raw reply [flat|nested] 71+ messages in thread
* [virtio-dev] Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-06-08 9:43 ` Michael S. Tsirkin 0 siblings, 0 replies; 71+ messages in thread From: Michael S. Tsirkin @ 2020-06-08 9:43 UTC (permalink / raw) To: David Stevens Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, open list, ML dri-devel, open list:VIRTIO GPU DRIVER, Linux Media Mailing List, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote: > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > > + vgdev->has_resource_assign_uuid = true; > > > + } > > > > > > Just a question: this relies on DMA bufs so I assume it is > > not really assumed to work when DMA API is bypassed, right? > > Rather than worry what does it mean, how about just > > disabling this feature without PLATFORM_DMA for now? > > By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? Sorry, no. I mean VIRTIO_F_IOMMU_PLATFORM which in the future will be renamed to VIRTIO_F_PLATFORM_ACCESS. > Virtio-gpu > depends on DRM, which selects that feature. So I think DMA bufs should > always be available when virtio-gpu is present. > > -David --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-06-08 9:43 ` Michael S. Tsirkin 0 siblings, 0 replies; 71+ messages in thread From: Michael S. Tsirkin @ 2020-06-08 9:43 UTC (permalink / raw) To: David Stevens Cc: ML dri-devel, virtio-dev, Thomas Zimmermann, David Airlie, Jason Wang, open list, open list:VIRTIO GPU DRIVER, moderated list:DMA BUFFER SHARING FRAMEWORK, Gerd Hoffmann, Linux Media Mailing List On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote: > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > > + vgdev->has_resource_assign_uuid = true; > > > + } > > > > > > Just a question: this relies on DMA bufs so I assume it is > > not really assumed to work when DMA API is bypassed, right? > > Rather than worry what does it mean, how about just > > disabling this feature without PLATFORM_DMA for now? > > By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? Sorry, no. I mean VIRTIO_F_IOMMU_PLATFORM which in the future will be renamed to VIRTIO_F_PLATFORM_ACCESS. > Virtio-gpu > depends on DRM, which selects that feature. So I think DMA bufs should > always be available when virtio-gpu is present. > > -David _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-06-08 9:43 ` Michael S. Tsirkin 0 siblings, 0 replies; 71+ messages in thread From: Michael S. Tsirkin @ 2020-06-08 9:43 UTC (permalink / raw) To: David Stevens Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, open list, ML dri-devel, open list:VIRTIO GPU DRIVER, Linux Media Mailing List, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote: > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > > + vgdev->has_resource_assign_uuid = true; > > > + } > > > > > > Just a question: this relies on DMA bufs so I assume it is > > not really assumed to work when DMA API is bypassed, right? > > Rather than worry what does it mean, how about just > > disabling this feature without PLATFORM_DMA for now? > > By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? Sorry, no. I mean VIRTIO_F_IOMMU_PLATFORM which in the future will be renamed to VIRTIO_F_PLATFORM_ACCESS. > Virtio-gpu > depends on DRM, which selects that feature. So I think DMA bufs should > always be available when virtio-gpu is present. > > -David ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources 2020-06-08 9:43 ` Michael S. Tsirkin (?) (?) @ 2020-06-08 10:36 ` David Stevens -1 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-06-08 10:36 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, open list, ML dri-devel, open list:VIRTIO GPU DRIVER, Linux Media Mailing List, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Mon, Jun 8, 2020 at 6:43 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote: > > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > > > + vgdev->has_resource_assign_uuid = true; > > > > + } > > > > > > > > > Just a question: this relies on DMA bufs so I assume it is > > > not really assumed to work when DMA API is bypassed, right? > > > Rather than worry what does it mean, how about just > > > disabling this feature without PLATFORM_DMA for now? > > > > By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? > > Sorry, no. I mean VIRTIO_F_IOMMU_PLATFORM which in the > future will be renamed to VIRTIO_F_PLATFORM_ACCESS. Shouldn't things work independent of whether or not that feature is set? If a virtio driver properly uses the dma_buf APIs (which virtgpu seems to), then that should take care of any mapping/synchronization related to VIRTIO_F_IOMMU_PLATFORM. If anything, the case where VIRTIO_F_IOMMU_PLATFORM isn't set is easier, since then we know that the "the device has same access [sic] to memory addresses supplied to it as the driver has", according to the specification. -David ^ permalink raw reply [flat|nested] 71+ messages in thread
* [virtio-dev] Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-06-08 10:36 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-06-08 10:36 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, open list, ML dri-devel, open list:VIRTIO GPU DRIVER, Linux Media Mailing List, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Mon, Jun 8, 2020 at 6:43 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote: > > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > > > + vgdev->has_resource_assign_uuid = true; > > > > + } > > > > > > > > > Just a question: this relies on DMA bufs so I assume it is > > > not really assumed to work when DMA API is bypassed, right? > > > Rather than worry what does it mean, how about just > > > disabling this feature without PLATFORM_DMA for now? > > > > By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? > > Sorry, no. I mean VIRTIO_F_IOMMU_PLATFORM which in the > future will be renamed to VIRTIO_F_PLATFORM_ACCESS. Shouldn't things work independent of whether or not that feature is set? If a virtio driver properly uses the dma_buf APIs (which virtgpu seems to), then that should take care of any mapping/synchronization related to VIRTIO_F_IOMMU_PLATFORM. If anything, the case where VIRTIO_F_IOMMU_PLATFORM isn't set is easier, since then we know that the "the device has same access [sic] to memory addresses supplied to it as the driver has", according to the specification. -David --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-06-08 10:36 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-06-08 10:36 UTC (permalink / raw) To: Michael S. Tsirkin Cc: ML dri-devel, virtio-dev, Thomas Zimmermann, David Airlie, Jason Wang, open list, open list:VIRTIO GPU DRIVER, moderated list:DMA BUFFER SHARING FRAMEWORK, Gerd Hoffmann, Linux Media Mailing List On Mon, Jun 8, 2020 at 6:43 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote: > > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > > > + vgdev->has_resource_assign_uuid = true; > > > > + } > > > > > > > > > Just a question: this relies on DMA bufs so I assume it is > > > not really assumed to work when DMA API is bypassed, right? > > > Rather than worry what does it mean, how about just > > > disabling this feature without PLATFORM_DMA for now? > > > > By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? > > Sorry, no. I mean VIRTIO_F_IOMMU_PLATFORM which in the > future will be renamed to VIRTIO_F_PLATFORM_ACCESS. Shouldn't things work independent of whether or not that feature is set? If a virtio driver properly uses the dma_buf APIs (which virtgpu seems to), then that should take care of any mapping/synchronization related to VIRTIO_F_IOMMU_PLATFORM. If anything, the case where VIRTIO_F_IOMMU_PLATFORM isn't set is easier, since then we know that the "the device has same access [sic] to memory addresses supplied to it as the driver has", according to the specification. -David _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-06-08 10:36 ` David Stevens 0 siblings, 0 replies; 71+ messages in thread From: David Stevens @ 2020-06-08 10:36 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, open list, ML dri-devel, open list:VIRTIO GPU DRIVER, Linux Media Mailing List, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Mon, Jun 8, 2020 at 6:43 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote: > > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > > > + vgdev->has_resource_assign_uuid = true; > > > > + } > > > > > > > > > Just a question: this relies on DMA bufs so I assume it is > > > not really assumed to work when DMA API is bypassed, right? > > > Rather than worry what does it mean, how about just > > > disabling this feature without PLATFORM_DMA for now? > > > > By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? > > Sorry, no. I mean VIRTIO_F_IOMMU_PLATFORM which in the > future will be renamed to VIRTIO_F_PLATFORM_ACCESS. Shouldn't things work independent of whether or not that feature is set? If a virtio driver properly uses the dma_buf APIs (which virtgpu seems to), then that should take care of any mapping/synchronization related to VIRTIO_F_IOMMU_PLATFORM. If anything, the case where VIRTIO_F_IOMMU_PLATFORM isn't set is easier, since then we know that the "the device has same access [sic] to memory addresses supplied to it as the driver has", according to the specification. -David ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources 2020-06-08 10:36 ` David Stevens (?) (?) @ 2020-06-08 15:17 ` Michael S. Tsirkin -1 siblings, 0 replies; 71+ messages in thread From: Michael S. Tsirkin @ 2020-06-08 15:17 UTC (permalink / raw) To: David Stevens Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, open list, ML dri-devel, open list:VIRTIO GPU DRIVER, Linux Media Mailing List, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Mon, Jun 08, 2020 at 07:36:55PM +0900, David Stevens wrote: > On Mon, Jun 8, 2020 at 6:43 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote: > > > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > > > > + vgdev->has_resource_assign_uuid = true; > > > > > + } > > > > > > > > > > > > Just a question: this relies on DMA bufs so I assume it is > > > > not really assumed to work when DMA API is bypassed, right? > > > > Rather than worry what does it mean, how about just > > > > disabling this feature without PLATFORM_DMA for now? > > > > > > By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? > > > > Sorry, no. I mean VIRTIO_F_IOMMU_PLATFORM which in the > > future will be renamed to VIRTIO_F_PLATFORM_ACCESS. > > Shouldn't things work independent of whether or not that feature is > set? If a virtio driver properly uses the dma_buf APIs (which virtgpu > seems to), then that should take care of any mapping/synchronization > related to VIRTIO_F_IOMMU_PLATFORM. If anything, the case where > VIRTIO_F_IOMMU_PLATFORM isn't set is easier, since then we know that > the "the device has same access [sic] to memory addresses supplied to > it as the driver has", according to the specification. > > -David I don't know much about drm so I can't tell, I was hoping Gerd can explain. -- MST ^ permalink raw reply [flat|nested] 71+ messages in thread
* [virtio-dev] Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-06-08 15:17 ` Michael S. Tsirkin 0 siblings, 0 replies; 71+ messages in thread From: Michael S. Tsirkin @ 2020-06-08 15:17 UTC (permalink / raw) To: David Stevens Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, open list, ML dri-devel, open list:VIRTIO GPU DRIVER, Linux Media Mailing List, moderated list:DMA BUFFER SHARING FRAMEWORK, virtio-dev On Mon, Jun 08, 2020 at 07:36:55PM +0900, David Stevens wrote: > On Mon, Jun 8, 2020 at 6:43 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote: > > > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > > > > + vgdev->has_resource_assign_uuid = true; > > > > > + } > > > > > > > > > > > > Just a question: this relies on DMA bufs so I assume it is > > > > not really assumed to work when DMA API is bypassed, right? > > > > Rather than worry what does it mean, how about just > > > > disabling this feature without PLATFORM_DMA for now? > > > > > > By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? > > > > Sorry, no. I mean VIRTIO_F_IOMMU_PLATFORM which in the > > future will be renamed to VIRTIO_F_PLATFORM_ACCESS. > > Shouldn't things work independent of whether or not that feature is > set? If a virtio driver properly uses the dma_buf APIs (which virtgpu > seems to), then that should take care of any mapping/synchronization > related to VIRTIO_F_IOMMU_PLATFORM. If anything, the case where > VIRTIO_F_IOMMU_PLATFORM isn't set is easier, since then we know that > the "the device has same access [sic] to memory addresses supplied to > it as the driver has", according to the specification. > > -David I don't know much about drm so I can't tell, I was hoping Gerd can explain. -- MST --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-06-08 15:17 ` Michael S. Tsirkin 0 siblings, 0 replies; 71+ messages in thread From: Michael S. Tsirkin @ 2020-06-08 15:17 UTC (permalink / raw) To: David Stevens Cc: ML dri-devel, virtio-dev, Thomas Zimmermann, David Airlie, Jason Wang, open list, open list:VIRTIO GPU DRIVER, moderated list:DMA BUFFER SHARING FRAMEWORK, Gerd Hoffmann, Linux Media Mailing List On Mon, Jun 08, 2020 at 07:36:55PM +0900, David Stevens wrote: > On Mon, Jun 8, 2020 at 6:43 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote: > > > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > > > > + vgdev->has_resource_assign_uuid = true; > > > > > + } > > > > > > > > > > > > Just a question: this relies on DMA bufs so I assume it is > > > > not really assumed to work when DMA API is bypassed, right? > > > > Rather than worry what does it mean, how about just > > > > disabling this feature without PLATFORM_DMA for now? > > > > > > By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? > > > > Sorry, no. I mean VIRTIO_F_IOMMU_PLATFORM which in the > > future will be renamed to VIRTIO_F_PLATFORM_ACCESS. > > Shouldn't things work independent of whether or not that feature is > set? If a virtio driver properly uses the dma_buf APIs (which virtgpu > seems to), then that should take care of any mapping/synchronization > related to VIRTIO_F_IOMMU_PLATFORM. If anything, the case where > VIRTIO_F_IOMMU_PLATFORM isn't set is easier, since then we know that > the "the device has same access [sic] to memory addresses supplied to > it as the driver has", according to the specification. > > -David I don't know much about drm so I can't tell, I was hoping Gerd can explain. -- MST _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources @ 2020-06-08 15:17 ` Michael S. Tsirkin 0 siblings, 0 replies; 71+ messages in thread From: Michael S. Tsirkin @ 2020-06-08 15:17 UTC (permalink / raw) To: David Stevens Cc: ML dri-devel, virtio-dev, Thomas Zimmermann, David Airlie, Maarten Lankhorst, open list, Maxime Ripard, open list:VIRTIO GPU DRIVER, moderated list:DMA BUFFER SHARING FRAMEWORK, Daniel Vetter, Sumit Semwal, Linux Media Mailing List On Mon, Jun 08, 2020 at 07:36:55PM +0900, David Stevens wrote: > On Mon, Jun 8, 2020 at 6:43 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote: > > > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > > > > + vgdev->has_resource_assign_uuid = true; > > > > > + } > > > > > > > > > > > > Just a question: this relies on DMA bufs so I assume it is > > > > not really assumed to work when DMA API is bypassed, right? > > > > Rather than worry what does it mean, how about just > > > > disabling this feature without PLATFORM_DMA for now? > > > > > > By PLATFORM_DMA, do you mean CONFIG_DMA_SHARED_BUFFER? > > > > Sorry, no. I mean VIRTIO_F_IOMMU_PLATFORM which in the > > future will be renamed to VIRTIO_F_PLATFORM_ACCESS. > > Shouldn't things work independent of whether or not that feature is > set? If a virtio driver properly uses the dma_buf APIs (which virtgpu > seems to), then that should take care of any mapping/synchronization > related to VIRTIO_F_IOMMU_PLATFORM. If anything, the case where > VIRTIO_F_IOMMU_PLATFORM isn't set is easier, since then we know that > the "the device has same access [sic] to memory addresses supplied to > it as the driver has", according to the specification. > > -David I don't know much about drm so I can't tell, I was hoping Gerd can explain. -- MST ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 0/4] Support virtio cross-device resources 2020-03-11 11:20 ` David Stevens (?) @ 2020-03-20 6:48 ` Gerd Hoffmann -1 siblings, 0 replies; 71+ messages in thread From: Gerd Hoffmann @ 2020-03-20 6:48 UTC (permalink / raw) To: David Stevens Cc: David Airlie, Daniel Vetter, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, linux-kernel, dri-devel, virtualization, linux-media, linaro-mm-sig, virtio-dev On Wed, Mar 11, 2020 at 08:20:00PM +0900, David Stevens wrote: > This patchset implements the current proposal for virtio cross-device > resource sharing [1], with minor changes based on recent comments. It > is expected that this will be used to import virtio resources into the > virtio-video driver currently under discussion [2]. > > This patchset adds a new hook to dma-buf, for querying the dma-buf's > underlying virtio UUID. This hook is then plumbed through DRM PRIME > buffers, and finally implemented in virtgpu. Looks all fine to me. We should wait for the virtio protocol update (patch 3/4) being accepted into the virtio specification. When this is done I'll go commit this to drm-misc-next. cheers, Gerd ^ permalink raw reply [flat|nested] 71+ messages in thread
* [virtio-dev] Re: [PATCH v3 0/4] Support virtio cross-device resources @ 2020-03-20 6:48 ` Gerd Hoffmann 0 siblings, 0 replies; 71+ messages in thread From: Gerd Hoffmann @ 2020-03-20 6:48 UTC (permalink / raw) To: David Stevens Cc: David Airlie, Daniel Vetter, Michael S . Tsirkin, Jason Wang, Sumit Semwal, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, linux-kernel, dri-devel, virtualization, linux-media, linaro-mm-sig, virtio-dev On Wed, Mar 11, 2020 at 08:20:00PM +0900, David Stevens wrote: > This patchset implements the current proposal for virtio cross-device > resource sharing [1], with minor changes based on recent comments. It > is expected that this will be used to import virtio resources into the > virtio-video driver currently under discussion [2]. > > This patchset adds a new hook to dma-buf, for querying the dma-buf's > underlying virtio UUID. This hook is then plumbed through DRM PRIME > buffers, and finally implemented in virtgpu. Looks all fine to me. We should wait for the virtio protocol update (patch 3/4) being accepted into the virtio specification. When this is done I'll go commit this to drm-misc-next. cheers, Gerd --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v3 0/4] Support virtio cross-device resources @ 2020-03-20 6:48 ` Gerd Hoffmann 0 siblings, 0 replies; 71+ messages in thread From: Gerd Hoffmann @ 2020-03-20 6:48 UTC (permalink / raw) To: David Stevens Cc: virtio-dev, Thomas Zimmermann, Michael S . Tsirkin, David Airlie, Jason Wang, linux-kernel, virtualization, linaro-mm-sig, dri-devel, linux-media On Wed, Mar 11, 2020 at 08:20:00PM +0900, David Stevens wrote: > This patchset implements the current proposal for virtio cross-device > resource sharing [1], with minor changes based on recent comments. It > is expected that this will be used to import virtio resources into the > virtio-video driver currently under discussion [2]. > > This patchset adds a new hook to dma-buf, for querying the dma-buf's > underlying virtio UUID. This hook is then plumbed through DRM PRIME > buffers, and finally implemented in virtgpu. Looks all fine to me. We should wait for the virtio protocol update (patch 3/4) being accepted into the virtio specification. When this is done I'll go commit this to drm-misc-next. cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 71+ messages in thread
end of thread, other threads:[~2020-06-09 7:35 UTC | newest] Thread overview: 71+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-11 11:20 [PATCH v3 0/4] Support virtio cross-device resources David Stevens 2020-03-11 11:20 ` [virtio-dev] " David Stevens 2020-03-11 11:20 ` David Stevens 2020-03-11 11:20 ` [PATCH v3 1/4] dma-buf: add support for virtio exported objects David Stevens 2020-03-11 11:20 ` [virtio-dev] " David Stevens 2020-03-11 11:20 ` David Stevens 2020-05-13 15:45 ` Daniel Vetter 2020-05-13 15:45 ` Daniel Vetter 2020-05-13 15:45 ` Daniel Vetter 2020-05-14 2:08 ` David Stevens 2020-05-14 2:08 ` [virtio-dev] " David Stevens 2020-05-14 2:08 ` David Stevens 2020-05-14 2:08 ` David Stevens 2020-05-14 12:28 ` Daniel Vetter 2020-05-14 12:28 ` Daniel Vetter 2020-05-14 12:28 ` Daniel Vetter 2020-05-14 7:59 ` Gerd Hoffmann 2020-05-14 7:59 ` [virtio-dev] " Gerd Hoffmann 2020-05-14 7:59 ` Gerd Hoffmann 2020-05-14 7:59 ` Gerd Hoffmann 2020-05-14 12:31 ` Daniel Vetter 2020-05-14 12:31 ` Daniel Vetter 2020-05-14 12:31 ` Daniel Vetter 2020-05-14 8:19 ` David Stevens 2020-05-14 8:19 ` [virtio-dev] " David Stevens 2020-05-14 8:19 ` David Stevens 2020-05-14 8:19 ` David Stevens 2020-05-14 12:30 ` Daniel Vetter 2020-05-14 12:30 ` Daniel Vetter 2020-05-14 12:30 ` Daniel Vetter 2020-05-15 5:07 ` David Stevens 2020-05-15 5:07 ` [virtio-dev] " David Stevens 2020-05-15 5:07 ` David Stevens 2020-05-15 5:07 ` David Stevens 2020-05-15 14:03 ` Daniel Vetter 2020-05-15 14:03 ` Daniel Vetter 2020-05-15 14:03 ` Daniel Vetter 2020-05-18 11:17 ` Sumit Semwal 2020-05-18 11:17 ` Sumit Semwal 2020-05-18 11:17 ` Sumit Semwal 2020-03-11 11:20 ` [PATCH v3 2/4] drm/prime: " David Stevens 2020-03-11 11:20 ` [virtio-dev] " David Stevens 2020-03-11 11:20 ` David Stevens 2020-03-11 11:20 ` [PATCH v3 3/4] virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature David Stevens 2020-03-11 11:20 ` [virtio-dev] " David Stevens 2020-03-11 11:20 ` David Stevens 2020-03-11 11:20 ` [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources David Stevens 2020-03-11 11:20 ` [virtio-dev] " David Stevens 2020-03-11 11:20 ` David Stevens 2020-05-13 16:34 ` Michael S. Tsirkin 2020-05-13 16:34 ` [virtio-dev] " Michael S. Tsirkin 2020-05-13 16:34 ` Michael S. Tsirkin 2020-05-15 7:26 ` David Stevens 2020-05-15 7:26 ` [virtio-dev] " David Stevens 2020-05-15 7:26 ` David Stevens 2020-05-15 7:26 ` David Stevens 2020-06-08 9:43 ` Michael S. Tsirkin 2020-06-08 9:43 ` [virtio-dev] " Michael S. Tsirkin 2020-06-08 9:43 ` Michael S. Tsirkin 2020-06-08 9:43 ` Michael S. Tsirkin 2020-06-08 10:36 ` David Stevens 2020-06-08 10:36 ` [virtio-dev] " David Stevens 2020-06-08 10:36 ` David Stevens 2020-06-08 10:36 ` David Stevens 2020-06-08 15:17 ` Michael S. Tsirkin 2020-06-08 15:17 ` [virtio-dev] " Michael S. Tsirkin 2020-06-08 15:17 ` Michael S. Tsirkin 2020-06-08 15:17 ` Michael S. Tsirkin 2020-03-20 6:48 ` [PATCH v3 0/4] Support virtio cross-device resources Gerd Hoffmann 2020-03-20 6:48 ` [virtio-dev] " Gerd Hoffmann 2020-03-20 6:48 ` Gerd Hoffmann
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.