Demi Marie Obenour <demiobenour@gmail.com> writes:
On 1/29/26 09:10, Alyssa Ross wrote:
Worth marking patches like this as RFC or similar in future, so everybody looking at it is on the same page about its status. (I'm assuming this was meant as a proof of concept and not meant to be applied as is.)
With the hash change, I was hoping it could be applied. I forgot to run scripts/genfiles.sh, though, and completely missed the missing fallback in crosvm.
Demi Marie Obenour <demiobenour@gmail.com> writes:
This exposes GPU acceleration to VMs via virtio-GPU native contexts on AMD and Qualcomm GPUs. Apple GPU support also exists but might require patches to virglrenderer that are not upstream yet.
On a system with an AMD GPU, this has been tested by running vkcube in the VM. It reports that the AMD GPU is being used for rendering.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com> --- I used an empty string for the hashes in 'gitfetch' and 'buildRustPackage'. This is, of course, incorrect. The correct value according to my own testing is "sha256-EOMkQ0aPRjsowdGuZjy5K1yKyKEzd5AVYxaECTz7n6k=" (git hash) and "sha256-k3dmxIuCQoOrn/VwauTdzuRw/XKQB6LPLgO5ql0rE7E=" (cargoHash). However, these should be validated before applying them, which is why I didn't include them in the patch themselves. This is a security precaution: anyone who wants to inject malicious content must serve it to multiple people, not just one. --- .../template/data/service/vhost-user-gpu/run | 2 +- img/app/Makefile | 2 +- img/app/default.nix | 14 ++++++++++++-- img/app/image/etc/mdev.conf | 1 + .../notification-fd | 0 .../notification-fd.license | 0 .../{wayland-proxy-virtwl => wl-cross-domain-proxy}/run | 17 +++++------------ .../type | 0 .../type.license | 0 9 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/vhost-user-gpu/run b/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/vhost-user-gpu/run index fb9ac9971aef82dabe0b54c1299ac8c66d133eb5..87d72f55e293ea81b6f4aa12786a993bafc623e2 100755 --- a/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/vhost-user-gpu/run +++ b/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/vhost-user-gpu/run @@ -42,4 +42,4 @@ bwrap crosvm --no-syslog device gpu --fd 0 --wayland-sock $WAYLAND_DISPLAY - --params "{\"context-types\":\"cross-domain\"}" + --params "{\"context-types\":\"cross-domain:drm\"}"
I suppose we'll need to get some sort of graceful fallback into crosvm/rutabaga, or to somehow detect native contexts support in this script before we enable it on the crosvm command line?
2026-01-29 14:06:30.082434936 [2026-01-29T14:06:30.082073581+00:00 ERROR rutabaga_gfx::virgl_renderer] failed to initialize drm renderer 2026-01-29 14:06:30.082842461 [2026-01-29T14:06:30.082652949+00:00 WARN rutabaga_gfx::rutabaga_core] error initializing gpu backend=virglrenderer, falling back to 2d. 2026-01-29 14:06:30.099779984 [2026-01-29T14:06:30.099379669+00:00 WARN devices::virtio::gpu::virtio_gpu] virtio-gpu get_capset_info(index=1) failed. intentionally poisoning response
Ideally crosvm would fallback automatically, but on ChromeOS it never needs to because it is built specifically for its target hardware.
Okay, but crosvm is open to contributions. They're willing to accept affordances for non-Chrome OS use. Even Google doesn't use it exclusively on Chrome OS…
It should be sufficient to detect if an AMD or Qualcomm GPU is available and the user has enabled GPU acceleration.
That doesn't sound very good, because then we'll have to keep updating it as new GPUs are supported.