kernel/linux.git/drivers/gpu/drm/virtio, branch v6.5.12

drm/virtio: clean out_fence on complete_submit

2023-10-06T11:15:58+00:00

[ Upstream commit 4556b93f6c026c62c93e7acc22838224ac2e2eba ] The removed line prevents the following cleanup function to execute a dma_fence_put on the out_fence to free its memory, producing the following output in kmemleak: unreferenced object 0xffff888126d8ee00 (size 128): comm "kwin_wayland", pid 981, jiffies 4295380296 (age 390.060s) hex dump (first 32 bytes): c8 a1 c2 27 81 88 ff ff e0 14 a9 c0 ff ff ff ff ...'............ 30 1a e1 2e a6 00 00 00 28 fc 5b 17 81 88 ff ff 0.......(.[..... backtrace: [<0000000011655661>] kmalloc_trace+0x26/0xa0 [<0000000055f15b82>] virtio_gpu_fence_alloc+0x47/0xc0 [virtio_gpu] [<00000000fa6d96f9>] virtio_gpu_execbuffer_ioctl+0x1a8/0x800 [virtio_gpu] [<00000000e6cb5105>] drm_ioctl_kernel+0x169/0x240 [drm] [<000000005ad33e27>] drm_ioctl+0x399/0x6b0 [drm] [<00000000a19dbf65>] __x64_sys_ioctl+0xc5/0x100 [<0000000011fa801e>] do_syscall_64+0x5b/0xc0 [<0000000065c76d8a>] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 unreferenced object 0xffff888121930500 (size 128): comm "kwin_wayland", pid 981, jiffies 4295380313 (age 390.096s) hex dump (first 32 bytes): c8 a1 c2 27 81 88 ff ff e0 14 a9 c0 ff ff ff ff ...'............ f9 ec d7 2f a6 00 00 00 28 fc 5b 17 81 88 ff ff .../....(.[..... backtrace: [<0000000011655661>] kmalloc_trace+0x26/0xa0 [<0000000055f15b82>] virtio_gpu_fence_alloc+0x47/0xc0 [virtio_gpu] [<00000000fa6d96f9>] virtio_gpu_execbuffer_ioctl+0x1a8/0x800 [virtio_gpu] [<00000000e6cb5105>] drm_ioctl_kernel+0x169/0x240 [drm] [<000000005ad33e27>] drm_ioctl+0x399/0x6b0 [drm] [<00000000a19dbf65>] __x64_sys_ioctl+0xc5/0x100 [<0000000011fa801e>] do_syscall_64+0x5b/0xc0 [<0000000065c76d8a>] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [...] This memleak will grow quickly, being possible to see the following line in dmesg after few minutes of life in the virtual machine: [ 706.217388] kmemleak: 10731 new suspected memory leaks (see /sys/kernel/debug/kmemleak) The patch will remove the line to allow the cleanup function do its job. Signed-off-by: José Pekkarinen Fixes: e4812ab8e6b1 ("drm/virtio: Refactor and optimize job submission code path") Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20230912060824.5210-1-jose.pekkarinen@foxhound.fi Signed-off-by: Sasha Levin

drm/virtio: Conditionally allocate virtio_gpu_fence

2023-09-19T10:30:08+00:00

commit 70d1ace56db6c79d39dbe9c0d5244452b67e2fde upstream. We don't want to create a fence for every command submission. It's only necessary when userspace provides a waitable token for submission. This could be: 1) bo_handles, to be used with VIRTGPU_WAIT 2) out_fence_fd, to be used with dma_fence apis 3) a ring_idx provided with VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK + DRM event API 4) syncobjs in the future The use case for just submitting a command to the host, and expecting no response. For example, gfxstream has GFXSTREAM_CONTEXT_PING that just wakes up the host side worker threads. There's also CROSS_DOMAIN_CMD_SEND which just sends data to the Wayland server. This prevents the need to signal the automatically created virtio_gpu_fence. In addition, VIRTGPU_EXECBUF_RING_IDX is checked when creating a DRM event object. VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK is already defined in terms of per-context rings. It was theoretically possible to create a DRM event on the global timeline (ring_idx == 0), if the context enabled DRM event polling. However, that wouldn't work and userspace (Sommelier). Explicitly disallow it for clarity. Signed-off-by: Gurchetan Singh Reviewed-by: Dmitry Osipenko Tested-by: Dmitry Osipenko Signed-off-by: Dmitry Osipenko # edited coding style Link: https://patchwork.freedesktop.org/patch/msgid/20230707213124.494-1-gurchetansingh@chromium.org Signed-off-by: Alyssa Ross Signed-off-by: Greg Kroah-Hartman

drm/virtio: Wait for each dma-fence of in-fence array individually

2023-06-03T01:50:50+00:00

Use dma-fence-unwrap API for waiting each dma-fence of the in-fence array individually. Sync file's in-fence array always has a non-matching fence context ID, which doesn't allow to skip waiting of fences with a matching context ID in a case of a merged sync file fence. Suggested-by: Rob Clark Reviewed-by: Emil Velikov Tested-by: Pierre-Eric Pelloux-Prayer Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20230416115237.798604-3-dmitry.osipenko@collabora.com

drm/virtio: Refactor and optimize job submission code path

2023-06-03T01:50:40+00:00

Move virtio_gpu_execbuffer_ioctl() into separate virtgpu_submit.c file, refactoring and optimizing the code along the way to ease addition of new features to the ioctl. The optimization is done by using optimal ordering of the job's submission steps, reducing code path from the start of the ioctl to the point of pushing job to virtio queue. Job's initialization is now performed before in-fence is awaited and out-fence setup is made after sending out job to virtio. Reviewed-by: Rob Clark Reviewed-by: Emil Velikov Tested-by: Pierre-Eric Pelloux-Prayer Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20230416115237.798604-2-dmitry.osipenko@collabora.com

Merge v6.3-rc4 into drm-next

2023-03-29T14:00:23+00:00

I just landed the fence deadline PR from Rob that a bunch of drivers want/need to apply driver-specific patches. Backmerge -rc4 so that they don't have to be stuck on -rc2 for no reason at all. Signed-off-by: Daniel Vetter

drm/virtio: Enable fb damage clips property for the primary plane

2023-03-13T17:22:24+00:00

Christian Hergert reports that the driver doesn't enable the property and that leads to always doing a full plane update, even when the driver does support damage clipping for the primary plane. Don't enable it for the cursor plane, because its .atomic_update callback doesn't handle damage clips. Reported-by: Christian Hergert Signed-off-by: Javier Martinez Canillas Reviewed-by: Thomas Zimmermann Acked-by: Gerd Hoffmann Link: https://patchwork.freedesktop.org/patch/msgid/20230310125943.912514-1-javierm@redhat.com

Merge drm/drm-fixes into drm-misc-fixes

2023-03-13T09:14:05+00:00

Backmerging to get latest upstream. Signed-off-by: Thomas Zimmermann

Merge drm/drm-next into drm-misc-next

2023-03-13T08:27:50+00:00

Backmerging to get v6.3-rc1 and sync with the other DRM trees. Signed-off-by: Thomas Zimmermann

drm/virtio: Fix handling CONFIG_DRM_VIRTIO_GPU_KMS option

2023-03-06T17:32:17+00:00

VirtIO-GPU got a new config option for disabling KMS. There were two problems left unnoticed during review when the new option was added: 1. The IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS) check in the code was inverted, hence KMS was disabled when it should be enabled and vice versa. 2. The disabled KMS crashed kernel with a NULL dereference in drm_kms_helper_hotplug_event(), which shall not be invoked with a disabled KMS. Fix the inverted config option check in the code and skip handling the VIRTIO_GPU_EVENT_DISPLAY sent by host when KMS is disabled in guest to fix the crash. Acked-by: Gerd Hoffmann Reviewed-by: Emil Velikov Fixes: 72122c69d717 ("drm/virtio: Add option to disable KMS support") Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20230306163916.1595961-1-dmitry.osipenko@collabora.com

drm/virtio: Add option to disable KMS support

2023-03-03T20:29:54+00:00

Add a build option to disable modesetting support. This is useful in cases where the guest only needs to use the GPU in a headless mode, or (such as in the CrOS usage) window surfaces are proxied to a host compositor. As the modesetting ioctls are a big surface area for potential security bugs to be found (it's happened in the past, we should assume it will again in the future), it makes sense to have a build option to disable those ioctls in cases where they serve no legitimate purpose. v2: Use more if (IS_ENABLED(...)) v3: Also permit the host to advertise no scanouts v4: Spiff out commit msg v5: Make num_scanouts==0 and DRM_VIRTIO_GPU_KMS=n behave the same v6: Drop conditionally building virtgpu_display.c and early-out of it's init/fini fxns instead Signed-off-by: Rob Clark Reviewed-by: Dmitry Osipenko Reviewed-by: Javier Martinez Canillas Reviewed-by: Gerd Hoffmann Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20230302233506.3146290-1-robdclark@gmail.com