On Tue, Mar 22, 2022 at 11:08:15AM +0000, Thomas Leonard wrote:
> On Mon, 21 Mar 2022 at 16:05, Alyssa Ross <hi@alyssa.is> wrote:
> >
> > On Mon, Mar 21, 2022 at 12:10:43PM +0000, Thomas Leonard wrote:
> > > Looking at the Linux virtio_gpu driver, it seems that using contexts
> > > requires virgl:
> > >
> > > static int virtio_gpu_context_init_ioctl(struct drm_device *dev, void
> > > *data, struct drm_file *file)
> > > {
> > >   ...
> > >   if (!vgdev->has_context_init || !vgdev->has_virgl_3d)
> > >     return -EINVAL;
> > >
> > > https://github.com/torvalds/linux/blob/f443e374ae131c168a065ea1748feac6b2e76613/drivers/gpu/drm/virtio/virtgpu_ioctl.c#L732
> > >
> > > I think perhaps that crosvm is compiled without the "virgl_renderer"
> > > feature (it's not in the default set), and this is causing it to crash
> > > because that's also "self.default_component". I don't know how to
> > > compile crosvm with virgl enabled, though.
> >
> > It wasn't easy, but I got it to build[1].  I hope that helps.  It adds
> > both virgl_renderer and virgl_renderer_next.  I think virgl_renderer
> > is on by default with --gpu, and virgl_renderer_next is used with the
> > --gpu-render-server argument.  Hopefully at least one of those does the
> > right thing — let me know!
> >
> > [1]: https://github.com/NixOS/nixpkgs/pull/165128
>
> Thanks, that is very helpful!
>
> I gave it a try, and it got a little further. But now, doing `modprobe
> virtio_gpu` in the VM crashes crosvm with:
>
> Stack trace of thread 2:
> #0  0x00007fa5fd0915f6 abort (libc.so.6 + 0x265f6)
> #1  0x00007fa5fcfc6bfd get_dlopen_handle.part.0 (libepoxy.so.0 + 0xc7bfd)
> #2  0x00007fa5fcfc7366 epoxy_egl_dlsym (libepoxy.so.0 + 0xc8366)
> #3  0x00007fa5fcfbf870 egl_single_resolver (libepoxy.so.0 + 0xc0870)
> #4  0x00007fa5fcfc1d2f epoxy_eglQueryString_global_rewrite_ptr
> (libepoxy.so.0 + 0xc2d2f)
> #5  0x0000561703e72ca1 virgl_egl_init (crosvm + 0x3deca1)
> #6  0x0000561703e72221 vrend_winsys_init (crosvm + 0x3de221)
> #7  0x0000561703e380dc virgl_renderer_init (crosvm + 0x3a40dc)
> #8  0x0000561703e35e44
> _ZN12rutabaga_gfx14virgl_renderer13VirglRenderer4init17h96573d71589e47fcE
> (crosvm + 0x3a1e44)
> #9  0x0000561703e23124
> _ZN12rutabaga_gfx13rutabaga_core15RutabagaBuilder5build17h694f3c234f8787ffE
> (crosvm + 0x38f124)
> #10 0x0000561703cdfb0f
> _ZN7devices6virtio3gpu10virtio_gpu9VirtioGpu3new17h43dded1b3497b0f1E
> (crosvm + 0x24bb0f)
> #11 0x0000561703d0feb2
> _ZN7devices6virtio3gpu5build17hc6e82daf2d41f5feE (crosvm + 0x27beb2)
> #12 0x0000561703cbee32
> _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h8f078e46fd25a72dE
> (crosvm + 0x22ae32)
> #13 0x0000561703cf5e0d
> _ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17h5605b62669a02b38E
> (crosvm + 0x261e0d)
> #14 0x0000561703ee8b43
> _ZN3std3sys4unix6thread6Thread3new12thread_start17h3f45e1fefa031d31E
> (crosvm + 0x454b43)
> #15 0x00007fa5fceb6d40 start_thread (libpthread.so.0 + 0x8d40)
> #16 0x00007fa5fd16703f __clone (libc.so.6 + 0xfc03f)
>
> Stack trace of thread 1:
> #0  0x00007fa5fd1684b2 recvfrom (libc.so.6 + 0xfd4b2)
> #1  0x0000561703ec7b0c
> _ZN8sys_util3net13UnixSeqpacket20recv_as_vec_with_fds17hcc9cb638a4fdbca9E
> (crosvm + 0x433b0c)
> #2  0x0000561703b85b87 _ZN4base4tube4Tube4recv17hd85339bce7434d11E
> (crosvm + 0xf1b87)
> #3  0x0000561703b90395
> _ZN7devices5proxy10child_proc17hde9579314b1fc020E (crosvm + 0xfc395)
> #4  0x0000000103001400 n/a (n/a + 0x0)
>
> It looks like it should be printing a message to stderr before calling
> abort, but I don't see it
> (https://github.com/anholt/libepoxy/blob/1.5.9/src/dispatch_common.c#L315).

Did you try --disable-sandbox, like I suggested in my other mail?
The sandbox blocks writing error messages, and is something I frequently
trip over when trying to use crosvm.