kernel/linux.git/drivers/gpu/drm/virtio/virtgpu_kms.c, branch v6.12.80

virtio: rename virtio_find_vqs_info() to virtio_find_vqs()

2024-07-17T09:20:58+00:00

Since the original virtio_find_vqs() is no longer present, rename virtio_find_vqs_info() back to virtio_find_vqs(). Signed-off-by: Jiri Pirko Message-Id: <20240708074814.1739223-20-jiri@resnulli.us> Signed-off-by: Michael S. Tsirkin

virtio: convert the rest virtio_find_vqs() users to virtio_find_vqs_info()

2024-07-17T09:20:58+00:00

Instead of passing separate names and callbacks arrays to virtio_find_vqs(), have one of virtual_queue_info structs and pass it to virtio_find_vqs_info(). Suggested-by: Xuan Zhuo Signed-off-by: Jiri Pirko Message-Id: <20240708074814.1739223-18-jiri@resnulli.us> Signed-off-by: Michael S. Tsirkin

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

drm/virtio: kms: use drm managed resources

2022-07-19T12:40:59+00:00

Allocate driver structures with drm managed resource allocators in order to cleanup/simplify the drm driver .release callback. Signed-off-by: Danilo Krummrich Link: http://patchwork.freedesktop.org/patch/msgid/20220714130028.2127858-3-dakr@redhat.com Signed-off-by: Gerd Hoffmann

drm/virtio: Improve DMA API usage for shmem BOs

2022-07-19T12:40:58+00:00

DRM API requires the DRM's driver to be backed with the device that can be used for generic DMA operations. The VirtIO-GPU device can't perform DMA operations if it uses PCI transport because PCI device driver creates a virtual VirtIO-GPU device that isn't associated with the PCI. Use PCI's GPU device for the DRM's device instead of the VirtIO-GPU device and drop DMA-related hacks from the VirtIO-GPU driver. Signed-off-by: Dmitry Osipenko Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-8-dmitry.osipenko@collabora.com Signed-off-by: Gerd Hoffmann

virtio: wrap config->reset calls

2022-01-14T23:50:52+00:00

This will enable cleanups down the road. The idea is to disable cbs, then add "flush_queued_cbs" callback as a parameter, this way drivers can flush any work queued after callbacks have been disabled. Signed-off-by: Michael S. Tsirkin Link: https://lore.kernel.org/r/20211013105226.20225-1-mst@redhat.com Signed-off-by: Michael S. Tsirkin

drm/virtio: implement context init: probe for feature

2021-09-29T07:22:30+00:00

Let's probe for VIRTIO_GPU_F_CONTEXT_INIT. Create a new DRM_INFO(..) line since the current one is getting too long. Signed-off-by: Anthoine Bourgeois Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: implement context init: track valid capabilities in a mask

2021-09-29T07:22:30+00:00

The valid capability IDs are between 1 to 63, and defined in the virtio gpu spec. This is used for error checking the subsequent patches. We're currently only using 2 capability IDs, so this should be plenty for the immediate future. Signed-off-by: Gurchetan Singh Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-4-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

drm/virtio: Fix double free on probe failure

2021-05-18T08:55:30+00:00

The virtio_gpu_init() will free vgdev and vgdev->vbufs on failure. But such failure will be caught by virtio_gpu_probe() and then virtio_gpu_release() will be called to do some cleanup which will free vgdev and vgdev->vbufs again. So let's set dev->dev_private to NULL to avoid double free. Signed-off-by: Xie Yongji Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-2-xieyongji@bytedance.com Signed-off-by: Gerd Hoffmann