Re: Using virtio-gpu instead of virtwl

Thomas Leonard
2022-03-22T20:05:53Z

On Tue, 22 Mar 2022 at 11:16, Alyssa Ross <hi@alyssa.is> wrote:
>
> 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)
[...]
> >
> > 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.

It's not very easy because --disable-sandbox seems to conflict with
--shared-dir, which I use for lots of things. But I've now compiled a
Linux kernel with "DRM_VIRTIO_GPU = yes" so I don't need the shared
/nix to get the kernel module. With that, running with
--disabled-sandbox seems to initialise the card successfully! I see:

[ 1.447535] [drm] Host memory window: 0x200000000 +0x200000000
[ 1.447821] [drm] features: +virgl -edid +resource_blob +host_visible
[ 1.447821] [drm] features: +context_init
[ 1.449292] [drm] number of scanouts: 1
[ 1.449495] [drm] number of cap sets: 4
[DEBUG:rutabaga_gfx/src/virgl_renderer.rs:113] gl_version 32 - es
profile enabled
[ 1.473662] [drm] cap set 0: id 1, max-version 1, max-size 308
[ 1.474027] [drm] cap set 1: id 2, max-version 2, max-size 764
[ 1.474386] [drm] cap set 2: id 4, max-version 0, max-size 0
[ 1.474702] [drm] cap set 3: id 5, max-version 0, max-size 16
[ 1.475158] [drm] Initialized virtio_gpu 0.1.0 0 for virtio6 on minor 0
[ 1.480946] virtio_gpu virtio6: [drm]
drm_plane_enable_fb_damage_clips() not called
[ 1.484018] Console: switching to colour frame buffer device 160x64
[ 1.487021] virtio_gpu virtio6: [drm] fb0: virtio_gpudrmfb frame
buffer device

Without --disabled-sandbox, it crashes after the "number of cap sets: 4" line.

--
talex5 (GitHub/Twitter)