similar to: [PATCH] drm/virtio: kick vq outside of the vq lock

Replace virtqueue_kick by virtqueue_kick_prepare, which requires serialization, and virtqueue_notify, which does not. Repurpose the return values to indicate whether the vq should be notified. This fixes a bad spinlock contention when the host is qemu. When the guest calls virtqueue_notify, the qemu vcpu thread exits the guest and waits for the qemu iothread to perform the MMIO. If the qemu

Drop the virtio_gpu_{disable,enable}_notify(). Add a new virtio_gpu_notify() call instead, which must be called whenever the driver wants make sure the host is notified needed. Drop notification from command submission. Add virtio_gpu_notify() calls everywhere instead. This results in more batching because we now notify only once for a series of commands. We already had that for page flips,

Drop the virtio_gpu_{disable,enable}_notify(). Add a new virtio_gpu_notify() call instead, which must be called whenever the driver wants make sure the host is notified needed. Drop notification from command submission. Add virtio_gpu_notify() calls everywhere instead. This results in more batching because we now notify only once for a series of commands. We already had that for page flips,

Rework fencing workflow, starting with virtio_gpu_execbuffer_ioctl. Stop using ttm helpers, use the virtio_gpu_array_* helpers (which work on the reservation objects directly) instead. New workflow: (1) All gem objects needed by a command are added to a virtio_gpu_object_array. (2) All reservation objects will be locked (virtio_gpu_array_lock_resv). (3) virtio_gpu_fence_emit() completes

Rework fencing workflow, starting with virtio_gpu_execbuffer_ioctl. Stop using ttm helpers, use the virtio_gpu_array_* helpers (which work on the reservation objects directly) instead. New workflow: (1) All gem objects needed by a command are added to a virtio_gpu_object_array. (2) All reservation objects will be locked (virtio_gpu_array_lock_resv). (3) virtio_gpu_fence_emit() completes

Only call virtio_gpu_array_add_fence if we actually have a fence. Fixes: da758d51968a ("drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing") Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c

Only call virtio_gpu_array_add_fence if we actually have a fence. Fixes: da758d51968a ("drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing") Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c

Split virtqueue_kick() call into virtqueue_kick_prepare(), which requires serialization, and virtqueue_notify(), which does not. Move the virtqueue_notify() call out of the critical section protected by the queue lock. This avoids triggering a vmexit while holding the lock and thereby fixes a rather bad spinlock contention. Suggested-by: Chia-I Wu <olvaffe at gmail.com> Signed-off-by:

Userspace requested command buffer allocations could be too large to make as a contiguous allocation. Use vmalloc if necessary to satisfy those allocations. Signed-off-by: David Riley <davidriley at chromium.org> --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 114 ++++++++++++++++++++----- 2 files changed, 96 insertions(+), 22 deletions(-)

Userspace requested command buffer allocations could be too large to make as a contiguous allocation. Use vmalloc if necessary to satisfy those allocations. Signed-off-by: David Riley <davidriley at chromium.org> --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 114 ++++++++++++++++++++----- 2 files changed, 96 insertions(+), 22 deletions(-)

Wait until we have enough space in the virt queue to actually queue up our request. Avoids the guest spinning in case we have a non-zero amount of free entries but not enough for the request. Cc: stable at vger.kernel.org Reported-by: Alain Magloire <amagloire at blackberry.com> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++-- 1

Wait until we have enough space in the virt queue to actually queue up our request. Avoids the guest spinning in case we have a non-zero amount of free entries but not enough for the request. Cc: stable at vger.kernel.org Reported-by: Alain Magloire <amagloire at blackberry.com> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++-- 1

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 ++-

Hi, this work is based on the virtio_wl driver in the ChromeOS kernel by Zach Reizner, currently at: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c There's one feature missing currently, which is letting clients write directly to the host part of a resource, so the extra copy in TRANSFER_TO_HOST isn't needed. Have pushed the

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

Use gem reservation helpers and direct reservation_object_* calls instead of ttm. v5: fix fencing (Chia-I Wu). v3: Also attach the array of gem objects to the virtio command buffer, so we can drop the object references in the completion callback. Needed because ttm fence helpers grab a reference for us, but gem helpers don't. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>

Use gem reservation helpers and direct reservation_object_* calls instead of ttm. v5: fix fencing (Chia-I Wu). v3: Also attach the array of gem objects to the virtio command buffer, so we can drop the object references in the completion callback. Needed because ttm fence helpers grab a reference for us, but gem helpers don't. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>

Use gem reservation helpers and direct reservation_object_* calls instead of ttm. v3: Also attach the array of gem objects to the virtio command buffer, so we can drop the object references in the completion callback. Needed because ttm fence helpers grab a reference for us, but gem helpers don't. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Acked-by: Daniel Vetter