kernel/linux.git/include/uapi/linux/virtio_gpu.h, branch v6.19.11

drm/virtio: Add capset definitions to UAPI

2025-03-28T01:53:51+00:00

Since the context-type additions to the virtio-gpu spec, these have been defined locally in guest user-space, and virtio-gpu backend library code. Now, these capsets have been stabilized, and should be defined in a common space, in both the virtio_gpu header, and alongside the virtgpu_drm interface that they apply to. Reviewed-by: Gurchetan Singh Signed-off-by: Aaron Ruby Signed-off-by: Dmitry Osipenko [dmitry.osipenko@collabora.com: edit commit title] Link: https://patchwork.freedesktop.org/patch/msgid/YT3PR01MB5857E808EDF6949F2DF517FDAFA12@YT3PR01MB5857.CANPRD01.PROD.OUTLOOK.COM

drm/virtio: Add DRM capset definition

2024-07-24T17:49:42+00:00

Define DRM native context capset in the VirtIO-GPU protocol header. Signed-off-by: Dmitry Osipenko Reviewed-by: Rob Clark Reviewed-by: Pierre-Eric Pelloux-Prayer Link: https://patchwork.freedesktop.org/patch/msgid/20240714205502.3409718-1-dmitry.osipenko@collabora.com

drm/virtio: add definition for venus capset

2023-12-15T16:30:00+00:00

This Venus capset definition is used by Qemu, and Qemu imports the kernel protocol header file. Add Venus capset to the VirtIO-GPU protocol. Signed-off-by: Huang Rui [dmitry.osipenko@collabora.com: edit commit message] Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20230915105918.3763061-1-ray.huang@amd.com

virtio-gpu api: multiple context types with explicit initialization

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

This feature allows for each virtio-gpu 3D context to be created with a "context_init" variable. This variable can specify: - the type of protocol used by the context via the capset id. This is useful for differentiating virgl, gfxstream, and venus protocols by host userspace. - other things in the future, such as the version of the context. In addition, each different context needs one or more timelines, so for example a virgl context's waiting can be independent on a gfxstream context's waiting. VIRTIO_GPU_FLAG_INFO_RING_IDX is introduced to specific to tell the host which per-context command ring (or "hardware queue", distinct from the virtio-queue) the fence should be associated with. The new capability sets (gfxstream, venus etc.) are only defined in the virtio-gpu spec and not defined in the header. Signed-off-by: Gurchetan Singh Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-2-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

virtio-gpu api: Add a comment on VIRTIO_GPU_SHM_ID_HOST_VISIBLE

2020-11-20T09:44:41+00:00

This provides a description of how the kernel driver uses the shmid to determine capabilities. Signed-off-by: Anthoine Bourgeois Link: http://patchwork.freedesktop.org/patch/msgid/20201119010809.528-3-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

virtio-gpu api: fix 64/32 compat issue with blob implementation

2020-09-30T06:31:08+00:00

We encountered this issue when booting blob with a 32-bit kernel. The implementation doesn't match v6 of the virtio-spec change, so fix this. Fixes: ff886cbdcc44 ("virtio-gpu api: blob resources") Signed-off-by: Alistair Delva Link: http://patchwork.freedesktop.org/patch/msgid/20200929215333.1241-1-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann

virtio-gpu api: host visible feature

2020-09-29T09:23:00+00:00

This patch adds a new virtgpu feature that allows directly mapping host allocated resources. This is based on virtio shared memory regions, which allows querying for memory regions using PCI transport. Each shared memory region has an associated "shmid", the meaning of which is device specific. For virtio-gpu, we can define the shared memory region with id VIRTIO_GPU_SHM_ID_HOST_VISIBLE to be the "host visible memory region". The presence of the host visible memory region means the following hypercalls are supported: 1) VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB This hypercall tells the host to inject the host resource's mapping in an offset into virtio-gpu's PCI address space. This is typically done via KVM_SET_USER_MEMORY_REGION on Linux hosts. On success, VIRTIO_GPU_RESP_OK_MAP_INFO is returned, which specifies the host buffer's caching type and possibly in the future performance hints about the buffer.. 2) VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB This hypercall tells the host to remove the host resource's mapping from the guest VM. Signed-off-by: Gerd Hoffmann Acked-by: Tomeu Vizoso Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-4-gurchetansingh@chromium.org Co-developed-by: Gurchetan Singh Signed-off-by: Gurchetan Singh

virtio-gpu api: blob resources

2020-09-29T09:22:49+00:00

A blob resource is a container for: - VIRTIO_GPU_BLOB_MEM_GUEST: a guest memory allocation (referred to as a "guest-only blob resource") - VIRTIO_GPU_BLOB_MEM_HOST3D: a host3d memory allocation (referred to as a "host-only blob resource") - VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST: a guest + host3d memory allocation (referred to as a "default blob resource"). The memory properties of the blob resource must be described by `blob_mem`. For default and guest only blob resources set, `nents` guest system pages are assigned to the resource. For default blob resources, these guest pages are used for transfer operations. Attach/detach is also possible to allow swap-in/swap-out, but isn't required since it may not be applicable to future blob mem types (shared guest/guest vram). Host allocations depend on whether the 3D is supported. If 3D is not supported, the only valid field for `blob_mem` is VIRTIO_GPU_BLOB_MEM_GUEST. If 3D is supported, the virtio-gpu resource is created from the context local object identified by the `blob_id`. The actual host allocation done by the CMD_SUBMIT_3D. Userspace must specify if the blob resource is intended to be used for userspace mapping, sharing between virtio-gpu contexts and/or sharing between virtio devices. This is done via `blob_flags`. For 3D hosts, both VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D and VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D may be used to update the host resource. There is no restriction on the image/buffer view the guest/host userspace has on the blob resource. VIRTIO_GPU_CMD_SET_SCANOUT_BLOB / VIRTIO_GPU_CMD_RESOURCE_FLUSH may be used with blob resources as well. The modifier is intentionally left out of SCANOUT_BLOB, and auxilary blobs are also left out as a simplification. The use case for blob resources is zero-copy, needed for coherent memory in virglrenderer. Host only blob resources are not mappable without the feature described in the next patch, but are shareable. Future work: - Emulated coherent `blob_mem` type for QEMU/vhost-user - A `blob_mem` type for guest-only resources imported in cache-coherent FOSS GPU/display drivers. - Display integration involving the blob model using seamless Wayland windows. Signed-off-by: Gerd Hoffmann Acked-by: Tomeu Vizoso Acked-by: Chia-I Wu Acked-by: Lingfeng Yang Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-3-gurchetansingh@chromium.org Co-developed-by: Gurchetan Singh Signed-off-by: Gurchetan Singh

Merge v5.9-rc1 into drm-misc-next

2020-08-18T12:14:25+00:00

Sam needs 5.9-rc1 to have dev_err_probe in to merge some patches. Signed-off-by: Maxime Ripard

virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature

2020-08-18T08:01:49+00:00

This feature allows the guest to request a UUID from the host for a particular virtio_gpu resource. The UUID can then be shared with other virtio devices, to allow the other host devices to access the virtio_gpu's corresponding host resource. Signed-off-by: David Stevens Acked-by: Michael S. Tsirkin Link: http://patchwork.freedesktop.org/patch/msgid/20200818071343.3461203-3-stevensd@chromium.org Signed-off-by: Gerd Hoffmann