Allow easier usage on x64 hosts

[gotlougit]

muvm is a great idea, and is a very nice tool for running graphical applications in a microVM. Other implementations are too general and need a lot of configuration, most of which is brittle and undocumented.

I would like to use muvm on an x64 host to run native (ie, x64) Wayland Linux applications inside the VM with full Vulkan support via venus and rutabaga.

Currently, muvm is specialized for running graphical x64 Linux games (via box or FEX) on ARM Linux. When I try running it on my machine with following command I get:

Command: muvm bash
Output:

Error setting up FEX in binfmt_misc: Failed to find `FEXInterpreter` in PATH
Failed to find or configure FEX, falling back to Box
Error setting up Box in binfmt_misc: Failed to find `box64` in PATH
No emulators were configured, x86 emulation may not work
Using default interface naming scheme 'v257'.
Failed to find syscall instruction in vDSO

From what I can tell, muvm can gracefully handle the lack of FEX or box emulators, but it seems there's no real guarantees after that. Are there any pointers as to what is going wrong here?

[teohhanhui]

I think maybe we could detect x86_64 host and just not use any emulator by default...

[valpackett]

I've included not auto-trying emulators on non-aarch64 in #192.

See #8 (comment) for running Wayland applications.

via venus

vDRM / native contexts should always be preferred and you can already use them with amdgpu (see same comment above) and i915 (with virglrenderer!1384 on the host + mesa!29870 in the guest).

Sure we still would like to have a fallback for unsupported drivers (for now, most importantly new Intel xe and any NVIDIA) but all the API-forwarding methods have their own strange requirements: Venus needs the out-of-process virglrenderer binary mode, and gfxstream (IIUC) takes over as an entire "backend" in rutabaga instead of virglrenderer. I'll keep investigating them, but right now I can only confirm that amdgpu native context works well.