On Wed, 18 May 2022 at 09:55, Thomas Leonard email@example.com wrote:
On Mon, 16 May 2022 at 11:55, Alyssa Ross firstname.lastname@example.org wrote:
Do you have a Nix expression somewhere for crosvm with all this stuff fixed? I'd like to integrate it into my draft Nixpkgs PR. (If you didn't do it with Nix, I can make the changes myself.)
No, sorry. I've just been hacking on it in nix-shell.
I've now collected things together and pushed all my scripts here:
I've got quite a few patches to crosvm now (and NixOS 22.05 brought some new problems), but they're hacks and not suitable for upstreaming. They might be a useful starting point for someone else though. They're in the crosvm subdirectory:
Adds some Nix paths to the jail to allow virtio-gpu to start. Otherwise, the mesa libraries can't be loaded. Note that mesa libraries are loaded dynamically by glvnd using dlopen. If that returns NULL to indicate an error, glvnd just ignores the error and doesn't load any drivers, causing crosvm to segfault later on a NULL pointer. That also hit me when I was accidentally compiling crosvm with a different version of glibc.
Sway/wlroots now sends read-only keymaps, but crosvm wants to map them read/write, which fails. This hack gets crosvm to try a read-only mmap if a read/write one fails. A better solution would be to remember that the resource is a keymap and map it read-only first.
After the host resumes from suspend, the disk driver gets EINTR from uring and stops handling disk requests. My previous trick of setting the locked memory limit to zero no longer works for some reason, so this stops uring in the source. A better fix would be to get crosvm to retry on EINTR.
When using virtio-gpu, crosvm opens a pointless console window. This patch forces the use of the Stub backend, which hides it. Possibly this still wastes resources though; maybe disabling the display completely would be better.
The shared filesystem driver runs in a jail where everything appears to be owned by root, and so this is how it appears in the Linux guest. This patch makes all files appear to be owned by user 1000, and performs all operations as user 0. This allows the regular user in the VM to access shared files. A better fix might be to stop using user namespaces here, but I'm not sure how to make that work.
While there are GPU operations outstanding, crosvm wakes up 1000 times a second to check whether they're done, which is very wasteful. This patch makes it wake only once per second, which doesn't seem to have any ill effects. I'm not sure why there are outstanding requests all the time - possibly "wait for a user action" counts as an in-progress request?