On Thu, 14 Apr 2022 at 13:57, Alyssa Ross <hi@alyssa.is> wrote:
On Wed, Apr 13, 2022 at 05:12:13PM +0000, Thomas Leonard wrote:
On Wed, 6 Apr 2022 at 12:19, Thomas Leonard <talex5@gmail.com> wrote: [ converting from virtwl to virtio-gpu ]
I tried, but failed, to figure out the protocol. I did manage to get a test application showing a little animation, but it crashes after a few seconds.
OK, I found a solution to this: you can just open the device file twice and use one instance for Wayland messages and the other for allocating images. This avoids the first race. With that, I got the proxy converted:
https://github.com/talex5/wayland-proxy-virtwl/pull/28
Though I'm not sure it's an improvement: +1,819 −577 lines!
Instructions for configuring crosvm to use it:
https://github.com/talex5/wayland-proxy-virtwl#virtio-gpu-support
And I wrote up my guesses about the protocol here:
https://github.com/talex5/wayland-proxy-virtwl/blob/master/virtio-spec.md
That's extremely helpful, thanks for writing it up!
A small update on this: First, I got virtio-gpu working with the jail. It just needs a couple of extra paths for NixOS: diff --git a/src/linux.rs b/src/linux.rs index ad031749..52d3142f 100644 --- a/src/linux.rs +++ b/src/linux.rs @@ -790,6 +790,8 @@ fn gpu_jail(cfg: &Config, policy: &str) -> Result<Option<Minijail>> { jail_mount_bind_if_exists( &mut jail, &[ + "/run/opengl-driver", + "/nix/store", "/usr/lib", "/usr/lib64", "/lib", Secondly, I realised that the "video" memory returned by virtio-gpu was just regular host memory (from stracing crosvm). This is because crosvm is compiled without minigbm support and falls back to this. After enabling minigbm and its amdgpu support (which also required adding a dependency on mesa) it started allocating vram. However, this broke the proxy because vram can't be used with the Wl_shm protocol. I updated the proxy's test.ml code (which opens a window with a scrolling pattern) to use Linux_dmabuf_unstable_v1, and that almost worked. But some of the pixels are wrong and it often crashes the whole VM. Possibly some of the output is getting stuck in a cache somewhere and is not actually flushed to the graphics card in time? Unfortunately, I don't know anything about GPUs. Anyway, I merged the changes I had, in case anyone else wants to try to get it working: https://github.com/talex5/wayland-proxy-virtwl/pull/33 If it did work, it should make things a bit more efficient by avoiding one copy. At the moment, I think the process is: 1. Application renders to guest memory. 2. Proxy copies to host memory. 3. Compositor copies to graphics card. If the mingbm stuff worked, the proxy could copy directly to the graphics card. And possibly the application could render there directly in the first place, but that would need more work. -- talex5 (GitHub/Twitter) http://roscidus.com/blog/