similar to: [PATCH 3/3] virtio-gpu: add locking for vbuf pool

Just use kmem_cache instead of rolling our own, limited implementation. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +-- drivers/gpu/drm/virtio/virtgpu_vq.c | 57 +++++++----------------------------- 2 files changed, 11 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h

Just use kmem_cache instead of rolling our own, limited implementation. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +-- drivers/gpu/drm/virtio/virtgpu_vq.c | 57 +++++++----------------------------- 2 files changed, 11 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h

From: Dave Airlie <airlied at gmail.com> This patch adds a kms driver for the virtio gpu. The xorg modesetting driver can handle the device just fine, the framebuffer for fbcon is there too. Qemu patches for the host side are under review currently. The pci version of the device comes in two variants: with and without vga compatibility. The former has a extra memory bar for the vga

From: Dave Airlie <airlied at gmail.com> This patch adds a kms driver for the virtio gpu. The xorg modesetting driver can handle the device just fine, the framebuffer for fbcon is there too. Qemu patches for the host side are under review currently. The pci version of the device comes in two variants: with and without vga compatibility. The former has a extra memory bar for the vga

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

Split virtio_gpu_deinit(), move the drm shutdown and release to virtio_gpu_release(). Drop vqs_ready variable, instead use drm_dev_{enter,exit,unplug} to avoid touching hardware after device removal. Tidy up here and there. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++- drivers/gpu/drm/virtio/virtgpu_display.c | 1 -

On Tue, Feb 11, 2020 at 02:58:04PM +0100, Gerd Hoffmann wrote: > Split virtio_gpu_deinit(), move the drm shutdown and release to > virtio_gpu_release(). Drop vqs_ready variable, instead use > drm_dev_{enter,exit,unplug} to avoid touching hardware after > device removal. Tidy up here and there. > > v4: add changelog. > v3: use drm_dev_*(). > > Signed-off-by: Gerd

Split virtio_gpu_deinit(), move the drm shutdown and release to virtio_gpu_release(). Drop vqs_ready variable, instead use drm_dev_{enter,exit,unplug} to avoid touching hardware after device removal. Tidy up here and there. v4: add changelog. v3: use drm_dev_*(). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++-

Split virtio_gpu_deinit(), move the drm shutdown and release to virtio_gpu_release(). Drop vqs_ready variable, instead use drm_dev_{enter,exit,unplug} to avoid touching hardware after device removal. Tidy up here and there. v4: add changelog. v3: use drm_dev_*(). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++-

From: Dave Airlie <airlied at gmail.com> This patch adds a kms driver for the virtio gpu. The xorg modesetting driver can handle the device just fine, the framebuffer for fbcon is there too. Qemu patches for the host side are under review currently. The pci version of the device comes in two variants: with and without vga compatibility. The former has a extra memory bar for the vga

From: Dave Airlie <airlied at gmail.com> This patch adds a kms driver for the virtio gpu. The xorg modesetting driver can handle the device just fine, the framebuffer for fbcon is there too. Qemu patches for the host side are under review currently. The pci version of the device comes in two variants: with and without vga compatibility. The former has a extra memory bar for the vga

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

When virtio_gpu_free_vbufs exits due to list empty, it does not drop the free_vbufs lock that it took. list empty is not expected to happen anyway, but it can't hurt to fix this and drop the lock. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > Hi, > > I can relatively easily reproduce this bug: > BUG: 'list_empty(&vgdev->free_vbufs)' is true! > ------------[ cut here ]------------ > kernel BUG at /home/latest/linux/drivers/gpu/drm/virtio/virtgpu_vq.c:130! > invalid opcode: 0000 [#1] PREEMPT SMP KASAN > Modules linked in: > CPU: 1

kmem_cache_alloc returns NULL on error, not ERR_PTR. Fixes: f5985bf9cadd4e3ed8d5d9a9cbbb2e39cdb81cd9 Reported-by: Jiri Slaby <jslaby at suse.cz> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c

kmem_cache_alloc returns NULL on error, not ERR_PTR. Fixes: f5985bf9cadd4e3ed8d5d9a9cbbb2e39cdb81cd9 Reported-by: Jiri Slaby <jslaby at suse.cz> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c

On Tue, Mar 24, 2015 at 05:07:18PM +0100, Gerd Hoffmann wrote: > From: Dave Airlie <airlied at gmail.com> > > This patch adds a kms driver for the virtio gpu. The xorg modesetting > driver can handle the device just fine, the framebuffer for fbcon is > there too. > > Qemu patches for the host side are under review currently. > > The pci version of the device