When submitting a fenced command we must lock the object reservations
because virtio_gpu_queue_fenced_ctrl_buffer() unlocks after adding the
fence.
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Jann Horn <jannh@google.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200110094535.23472-1-kraxel@redhat.com
When the driver submits multiple commands in a row it makes sense to
notify the host only after submitting the last one, so the host can
process them all at once, with a single vmexit.
Add functions to enable/disable notifications to allow that. Use the
new functions for primary plane updates.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20191212125346.8334-3-kraxel@redhat.com
Return early for the no framebuffer (or disabled output) case.
Results in a simpler code flow for the remaining cases.
No functional change.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20191023062539.11728-3-kraxel@redhat.com
Be consistent with the rest of the code base.
No functional change.
v2:
- fix sparse warnings for virtio_gpu_cmd_transfer_to_host_2d call.
- move convert_to_hw_box helper function.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20191023062539.11728-2-kraxel@redhat.com
Switch gem shmem helper to the new mmap() workflow,
from &gem_driver.fops.mmap to &drm_gem_object_funcs.mmap.
v2: Fix vm_flags and vm_page_prot handling.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-3-kraxel@redhat.com
Move object release into a separate worker. Releasing objects requires
sending commands to the host. Doing that in the dequeue worker will
cause deadlocks in case the command queue gets filled up, because the
dequeue worker is also the one which will free up slots in the command
queue.
Reported-by: Chia-I Wu <olvaffe@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Chia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190830060116.10476-1-kraxel@redhat.com
virtio-gpu basically needs a sg_table for the bo, to tell the host where
the backing pages for the object are. So the gem shmem helpers are a
perfect fit. Some drm_gem_object_funcs need thin wrappers to update the
host state, but otherwise the helpers handle everything just fine.
Once the fencing was sorted the switch was surprisingly easy and for the
most part just removing the ttm code.
v4: fix drm_gem_object_funcs name.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-15-kraxel@redhat.com
Rework fencing workflow. Stop using ttm helpers, use the
virtio_gpu_array_* helpers instead.
Due to using the gem reservation object it is initialized and ready for
use before calling ttm_bo_init. So we can simply use the standard
fencing workflow and drop the tricky logic which checks whenever the
command is in flight still.
v6: rewrite most of the patch.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-10-kraxel@redhat.com
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.
Also store the object array in struct virtio_gpu_vbuffer, so we
explicitly keep a reference of all buffers used instead of depending
on ttm_bo_put() checking whenever the object is actually idle before
releasing it.
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 fence initialization.
(4) fence gets added to the objects, reservation objects are unlocked
(virtio_gpu_array_add_fence, virtio_gpu_array_unlock_resv).
(5) virtio command is submitted to the host.
(6) The completion callback (virtio_gpu_dequeue_ctrl_func)
will drop object references and free virtio_gpu_object_array.
v6: rewrite most of the patch.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-9-kraxel@redhat.com
Some helper functions to manage an array of gem objects.
v9: use dma_resv_lock_interruptible.
v6:
- add ticket to struct virtio_gpu_object_array.
- add virtio_gpu_array_{lock,unlock}_resv helpers.
- add virtio_gpu_array_add_fence helper.
v5: some small optimizations (Chia-I Wu).
v4: make them virtio-private instead of generic helpers.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-8-kraxel@redhat.com
Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl().
This also makes the ioctl run lockless.
v9: fix return value.
v5: handle lookup failure.
v2: use reservation_object_test_signaled_rcu for VIRTGPU_WAIT_NOWAIT.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-3-kraxel@redhat.com
With this gem and ttm will use the same reservation object,
so mixing and matching ttm / gem reservation helpers should
work fine.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-2-kraxel@redhat.com
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@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190813082509.29324-3-kraxel@redhat.com
