This is NOT used in Qubes YET. Xen support is in early development. Vendoring and dependency reduction might also be coming. Sandboxing will also be added before it is used in Qubes.

Qubes Virtio-GPU Device Server (qubes-virtgpu-host)

This is a vhost-user backend server implementing the subset of virtio-gpu relevant for desktop integration:

• only CROSS_DOMAIN and DRM context types are supported, none of the legacy ones;
• only blob resources are supported, not transfer-based 2d/3d resources;
• absolutely no virtual monitors (scanout/cursors).

The codebase is derived from vhost-device's vhost-device-gpu, simplified and pivoted towards a completely different subset of features. The bulk of the actual implementation lives in rutabaga_gfx, which implements CROSS_DOMAIN internally but calls into virglrenderer for DRM. As the goal is to provide decent security, we're likely to "inline" and simplify some of that stack in order to reduce the TCB and make it more auditable.

The supported guest/client counterpart is wl-cross-domain-proxy. (You probably could use one of its predecessors but… why?!)

Running on KVM

qubes-virtgpu-host works with KVM-based VMMs that support a recent-enough vhost-user protocol, namely the SHMEM_MAP feature must be implemented (and its flag must have the final agreed-upon value of 0x0040_0000!)

crosvm (at least the latest git version) works well:

cargo run -- --socket-path /tmp/gpu.sock --capset cross-domain,drm &
crosvm run --vhost-user gpu,max-queue-size=1024,socket=/tmp/gpu.sock # ...

License

qubes-virtgpu-host is available under a dual MIT/Apache-2 license.