search for: virtio_dma_buf

...gned-off-by: David Stevens <stevensd at chromium.org> Is this just for graphics? If yes I'd rather we put it in the graphics driver. We can always move it later ... > --- > drivers/virtio/Makefile | 2 +- > drivers/virtio/virtio.c | 6 +++ > drivers/virtio/virtio_dma_buf.c | 89 +++++++++++++++++++++++++++++++++ > include/linux/virtio.h | 1 + > include/linux/virtio_dma_buf.h | 58 +++++++++++++++++++++ > 5 files changed, 155 insertions(+), 1 deletion(-) > create mode 100644 drivers/virtio/virtio_dma_buf.c > create mode 100644 include/li...

...gned-off-by: David Stevens <stevensd at chromium.org> Is this just for graphics? If yes I'd rather we put it in the graphics driver. We can always move it later ... > --- > drivers/virtio/Makefile | 2 +- > drivers/virtio/virtio.c | 6 +++ > drivers/virtio/virtio_dma_buf.c | 89 +++++++++++++++++++++++++++++++++ > include/linux/virtio.h | 1 + > include/linux/virtio_dma_buf.h | 58 +++++++++++++++++++++ > 5 files changed, 155 insertions(+), 1 deletion(-) > create mode 100644 drivers/virtio/virtio_dma_buf.c > create mode 100644 include/li...

...hromium.org> This makes VIRTIO dependent on DMA_SHARED_BUFFER. That means "select DMA_SHARED_BUFFER" will have to be added to "config VIRTIO". Guenter > --- > drivers/virtio/Makefile | 2 +- > drivers/virtio/virtio.c | 6 +++ > drivers/virtio/virtio_dma_buf.c | 85 +++++++++++++++++++++++++++++++++ > include/linux/virtio.h | 1 + > include/linux/virtio_dma_buf.h | 37 ++++++++++++++ > 5 files changed, 130 insertions(+), 1 deletion(-) > create mode 100644 drivers/virtio/virtio_dma_buf.c > create mode 100644 include/linux/vir...

...which imports these dma-bufs (slightly out of data, uses v3 > of this patch set): https://markmail.org/thread/j4xlqaaim266qpks > > > > --- > > > drivers/virtio/Makefile | 2 +- > > > drivers/virtio/virtio.c | 6 +++ > > > drivers/virtio/virtio_dma_buf.c | 89 +++++++++++++++++++++++++++++++++ > > > include/linux/virtio.h | 1 + > > > include/linux/virtio_dma_buf.h | 58 +++++++++++++++++++++ > > > 5 files changed, 155 insertions(+), 1 deletion(-) > > > create mode 100644 drivers/virtio/virtio_dma_b...

...sary if we're only talking > about a single virtio subsystem. Thanks for the explanation! Regards Guennadi > > > > --- > > > > drivers/virtio/Makefile | 2 +- > > > > drivers/virtio/virtio.c | 6 +++ > > > > drivers/virtio/virtio_dma_buf.c | 89 +++++++++++++++++++++++++++++++++ > > > > include/linux/virtio.h | 1 + > > > > include/linux/virtio_dma_buf.h | 58 +++++++++++++++++++++ > > > > 5 files changed, 155 insertions(+), 1 deletion(-) > > > > create mode 100644 drivers...

...3 > > > of this patch set): https://markmail.org/thread/j4xlqaaim266qpks > > > > > > > > --- > > > > > drivers/virtio/Makefile | 2 +- > > > > > drivers/virtio/virtio.c | 6 +++ > > > > > drivers/virtio/virtio_dma_buf.c | 89 +++++++++++++++++++++++++++++++++ > > > > > include/linux/virtio.h | 1 + > > > > > include/linux/virtio_dma_buf.h | 58 +++++++++++++++++++++ > > > > > 5 files changed, 155 insertions(+), 1 deletion(-) > > > > > create...

...emu-next drm-misc ee194dc222ae virtio: add dma-buf support for exported objects -:29: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #29: new file mode 100644 -:65: CHECK:OPEN_ENDED_LINE: Lines should not end with a '(' #65: FILE: include/linux/virtio_dma_buf.h:32: +struct dma_buf *virtio_dma_buf_export( -:112: CHECK:OPEN_ENDED_LINE: Lines should not end with a '(' #112: FILE: drivers/virtio/virtio_dma_buf.c:19: +struct dma_buf *virtio_dma_buf_export( -:115: CHECK:OPEN_ENDED_LINE: Lines should not end with a '(' #115: FILE: drivers/vir...

...ail.org/thread/j4xlqaaim266qpks > > > > > > > > > > > > --- > > > > > > > drivers/virtio/Makefile | 2 +- > > > > > > > drivers/virtio/virtio.c | 6 +++ > > > > > > > drivers/virtio/virtio_dma_buf.c | 89 +++++++++++++++++++++++++++++++++ > > > > > > > include/linux/virtio.h | 1 + > > > > > > > include/linux/virtio_dma_buf.h | 58 +++++++++++++++++++++ > > > > > > > 5 files changed, 155 insertions(+), 1 deletion(-) &g...

...Besides that, for virtio parts: Acked-by: Michael S. Tsirkin <mst at redhat.com> > [1] https://markmail.org/thread/2ypjt5cfeu3m6lxu > [2] https://markmail.org/thread/p5d3k566srtdtute > [3] https://markmail.org/thread/j4xlqaaim266qpks > > v4 -> v5 changes: > - Remove virtio_dma_buf_export_info. > > David Stevens (3): > virtio: add dma-buf support for exported objects > virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature > drm/virtio: Support virtgpu exported resources > > drivers/gpu/drm/virtio/virtgpu_drv.c | 3 + > drivers/gpu/drm/virtio/v...

...ent 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...

...341f078a34 100644 > --- a/drivers/virtio/Makefile > +++ b/drivers/virtio/Makefile > @@ -12,3 +12,4 @@ obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o > obj-$(CONFIG_VIRTIO_VDPA) += virtio_vdpa.o > obj-$(CONFIG_VIRTIO_MEM) += virtio_mem.o > obj-$(CONFIG_VIRTIO_DMA_SHARED_BUFFER) += virtio_dma_buf.o > +obj-$(CONFIG_VIRTIO_VCPU_WATCHDOG) += virtio_vcpu_stall_detector.o > diff --git a/drivers/virtio/virtio_vcpu_stall_detector.c b/drivers/virtio/virtio_vcpu_stall_detector.c > new file mode 100644 > index 000000000000..58344ca528be > --- /dev/null > +++ b/drivers/virtio/virtio_...

...f 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...

...f 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...

...341f078a34 100644 > --- a/drivers/virtio/Makefile > +++ b/drivers/virtio/Makefile > @@ -12,3 +12,4 @@ obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o > obj-$(CONFIG_VIRTIO_VDPA) += virtio_vdpa.o > obj-$(CONFIG_VIRTIO_MEM) += virtio_mem.o > obj-$(CONFIG_VIRTIO_DMA_SHARED_BUFFER) += virtio_dma_buf.o > +obj-$(CONFIG_VIRTIO_VCPU_WATCHDOG) += virtio_vcpu_stall_detector.o > diff --git a/drivers/virtio/virtio_vcpu_stall_detector.c b/drivers/virtio/virtio_vcpu_stall_detector.c > new file mode 100644 > index 000000000000..58344ca528be > --- /dev/null > +++ b/drivers/virtio/virtio_...