Support for opt-in GPU acceleration via virtio-GPU native contexts

[DemiMarie]

How to file a helpful issue

The problem you're addressing (if any)

All rendering happens in software. This is fast enough for many uses, but some users need better performance, even at the expense of increased attack surface.

The solution you'd like

Opt-in GPU acceleration via virtio-GPU native contexts.

The value to a user, and who that user might be

Users for whom software rendering has unacceptable performance will be able to use Qubes OS, without resorting to PCI pass-through.

Dependency tree

Any issue in this list should have C: GPU acceleration and, if it relates to Wayland support, C: Wayland Support for Wayland as well.

Basic GPU acceleration

This is sufficient for GPU compute but not for rendering.

Cross-vendor

• Select a virtio-GPU implementation #8983

Intel-specific

• Wait for Intel virtio-GPU native contexts to be merged upstream.
  • Optional: Wait for them to be shipped in Google ChromeOS, which would make them in-scope for Google’s Vulnerability Rewards Program.

AMD-specific

• Wait for AMD virtio-GPU native contexts to be merged upstream.
  • Optional: Wait for them to be shipped in Google ChromeOS, which would make them in-scope for Google’s Vulnerability Rewards Program.

Wayland support

virtio-GPU will use Wayland to pass GPU buffers to the host display server, so Wayland support is required.

• Cross-VM GPU buffer sharing #8973
• Use Wayland instead of X11 to increase performance and improve security #3366
• Support KDE Wayland Session #8515

User control over GPU acceleration

Users need to be in control over which VMs have GPU acceleration

• Admin API for GPU acceleration control #8962

Security hardening

Qubes OS must remain reasonably secure even if GPU acceleration is in use.

• Ensure that non-native virtio-GPU contexts are disabled #8969
• Ensure that dom0 kernel is kept up to date if GPU acceleration is used #8972
• Rewrite host part of virgl-renderer in Rust #8974
• Ensure that guests cannot communicate with GPU media engines #8984

Testing

Shipping an untested feature is quite ill-advised.

• “Fake” (llvmpipe-based, non-native) virtio-GPU for integration testing #8554
• Test that GPU acceleration actually works #8968

Fault detection and recovery

GPUs can have problems and users need to be able to recover.

• Notify the user when a VM crashes the GPU #8963
• Ensure system recovers from GPU crashes #8971
• If a VM crashes the GPU, prevent it from using the GPU again until the user re-allows it. #8982

[rwiesbach]

https://github.com/orgs/QubesOS/projects/17 bundles efforts regarding GPU acceleration in Qubes OS

[DemiMarie]

Removing my assignment as this is blocked on third-party Xen patches being upstreamed.

[WesleyAC]

@DemiMarie, could you link to those upstream patches?

[DemiMarie]

@WesleyAC I don’t think they are public yet.

[ILOVEPIE]

Any way I can assist with development?