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/f443e374ae131c168a065ea1748feac6b2e76...
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!
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) http://roscidus.com/blog/