#
216d86b9 |
|
15-Sep-2023 |
Huang Rui <ray.huang@amd.com> |
drm/virtio: add definition for venus capset 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 <ray.huang@amd.com> [dmitry.osipenko@collabora.com: edit commit message] Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230915105918.3763061-1-ray.huang@amd.com
|
#
34268c9d |
|
21-Sep-2021 |
Gurchetan Singh <gurchetansingh@chromium.org> |
virtio-gpu api: multiple context types with explicit initialization 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 <gurchetansingh@chromium.org> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-2-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
#
c1209608 |
|
18-Nov-2020 |
Anthoine Bourgeois <anthoine.bourgeois@gmail.com> |
virtio-gpu api: Add a comment on VIRTIO_GPU_SHM_ID_HOST_VISIBLE This provides a description of how the kernel driver uses the shmid to determine capabilities. Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201119010809.528-3-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
#
91e515c2 |
|
29-Sep-2020 |
Alistair Delva <adelva@google.com> |
virtio-gpu api: fix 64/32 compat issue with blob implementation 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 <adelva@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200929215333.1241-1-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
#
e5cd6cbe |
|
23-Sep-2020 |
Gerd Hoffmann <kraxel@redhat.com> |
virtio-gpu api: host visible feature 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 <kraxel@redhat.com> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-4-gurchetansingh@chromium.org Co-developed-by: Gurchetan Singh <gurchetansingh@chromium.org> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
|
#
ff886cbd |
|
23-Sep-2020 |
Gerd Hoffmann <kraxel@redhat.com> |
virtio-gpu api: blob resources 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 <kraxel@redhat.com> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Chia-I Wu <olvaffe@gmail.com> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-3-gurchetansingh@chromium.org Co-developed-by: Gurchetan Singh <gurchetansingh@chromium.org> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
|
#
592d9fba |
|
18-Aug-2020 |
David Stevens <stevensd@chromium.org> |
virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature 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 <stevensd@chromium.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200818071343.3461203-3-stevensd@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
#
f378444b |
|
10-Jul-2020 |
Michael S. Tsirkin <mst@redhat.com> |
virtio_gpu: correct tags for config space fields Since gpu is a modern-only device, tag config space fields as having little endian-ness. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
|
#
beb941b9 |
|
10-Apr-2019 |
Gerd Hoffmann <kraxel@redhat.com> |
virtio-gpu api: comment feature flags Add comments to the existing feature flags, documenting which commands belong to them. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190410114227.25846-2-kraxel@redhat.com
|
#
610c0c2b |
|
30-Oct-2018 |
Gerd Hoffmann <kraxel@redhat.com> |
virtio-gpu: add VIRTIO_GPU_F_EDID feature The feature allows the guest request an EDID blob (describing monitor capabilities) for a given scanout (aka virtual monitor connector). It brings a new command message, which has just a scanout field (beside the standard virtio-gpu header) and a response message which carries the EDID data. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181030063206.19528-2-kraxel@redhat.com
|
#
110ab11d |
|
02-May-2018 |
Dave Airlie <airlied@redhat.com> |
drm/virtio: add define for second capset to the virgl code. Although the kernel doesn't use this, qemu imports these headers and it's best to keep them consistent. This define is also something userspace may want to use. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180503021021.10694-1-airlied@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
#
89545d6d |
|
02-Dec-2015 |
Mikko Rapeli <mikko.rapeli@iki.fi> |
include/uapi/linux/virtio_gpu.h: use __u8 from <linux/types.h> Kernel headers exported to userspace are should these types. Fixes userspace compilation error: error: unknown type name ‘uint8_t’ Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
|
#
62fb7a5e |
|
27-Oct-2014 |
Gerd Hoffmann <kraxel@redhat.com> |
virtio-gpu: add 3d/virgl support Add the bits needed for opengl rendering support: query capabilities, new virtio commands, drm ioctls. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
#
ae455773 |
|
04-Jun-2015 |
Dave Airlie <airlied@redhat.com> |
virtgpu: include linux/types.h to avoid warning. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
dc5698e8 |
|
08-Sep-2013 |
Dave Airlie <airlied@gmail.com> |
Add virtio gpu driver. This patch adds a kms driver for the virtio gpu. The xorg modesetting driver can handle the device just fine, the framebuffer for fbcon is there too. Qemu patches for the host side are under review currently. The pci version of the device comes in two variants: with and without vga compatibility. The former has a extra memory bar for the vga framebuffer, the later is a pure virtio device. The only concern for this driver is that in the virtio-vga case we have to kick out the firmware framebuffer. Initial revision has only 2d support, 3d (virgl) support requires some more work on the qemu side and will be added later. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com>
|