Re: Using virtio-gpu instead of virtwl

Thomas Leonard
2022-05-15T14:20:45Z

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)