Running x86/x86-64 applications on Fedora Asahi Remix

As this project is still in its early stages, we aimed for correctness for the initial release. Performance optimization will happen over time. We’re aware of several changes that should bring significant performance improvements, and we’re actively working on it!

For Windows DX8-DX11 games under Proton in particular, you might want to try WineD3D instead of DXVK. WineD3D uses OpenGL instead of Vulkan as its backend, and it may have better performance thanks to optimizations in our OpenGL driver that are not available on Vulkan. To enable it, change the Steam launch options to PROTON_USE_WINED3D=1 %command%. Note that DXVK tends to have better compatibility, so this is a trade-off. Let us know what games work better using either backend!

These are known issues caused by bugs/limitations in Sommelier. We recommend using our x86/x86_64 stack only to run fullscreen applications (games, Steam in Big Picture mode) at this time. We’re working on a solution to this issue by replacing Sommelier with a more lightweight alternative.

To allow guest apps to use a large amount of RAM (as some modern games require), by default muvm allows the guest to use up to 80% of the system RAM. This also means that some of that will be taken up by guest page cache. Especially on lower RAM size machines (16GB or lower), we recommend not running any heavy host applications while the VM is in use. We don’t recommend gaming on 8GB machines.

You can configure the guest RAM allocation with the muvm --mem=SIZE parameter.

This will be less of an issue in the future, when we enable virtiofs-DAX in muvm. This directly maps host filesystem cache pages into the guest, and therefore relieves memory pressure.

This does not work (not even via /run/muvm-host/run/media) due to missing POSIX ACL support in libkrun at this time. You must manually mount any disks that you wish to use within the VM, e.g. under /mnt.

This is as close to Rosetta as we can get! The main difference is that Rosetta side-steps the page size issue by instead relying on the XNU kernel’s multiple page size support for user processes, so it doesn’t need a VM. While making Linux support mixed page sizes would not be completely impossible in theory, it would be an enormous project that would likely take years to complete, and it isn’t at all clear whether such a change would be accepted upstream (Linux doesn’t even have boot-time page size selection within a single kernel yet!).

Other than the page size issue, FEX and Rosetta are comparable technologies (both are emulators, despite what Apple marketing might have you believe). Both FEX and Rosetta use the unique Apple Silicon CPU feature that is most important for x86/x86_64 emulation performance: TSO mode. Thanks to this feature, FEX can offer fast and accurate x86/x86_64 emulation on Apple Silicon systems.

While Apple Silicon systems support 4K CPU pages, the rest of the hardware (IOMMUs, GPU) runs with 16K pages only. The Linux kernel does not play nicely in this environment, as it generally assumes that the CPU page size is at least as large or larger than the IOMMU page size. In the past we had some kernel patches to make this partially work, but they were buggy and incomplete, so we abandoned the approach. Even if it did work well, running the whole system using 4K pages has a measurable performance impact, so we would never ship 4K kernels by default. Therefore, running x86/x86_64 would require that users manually change their kernel and reboot, which is quite cumbersome.

box64 and FEX-Emu have different approaches to emulation, with FEX-Emu aiming for better correctness by default (but requiring a more complex setup) while box64 aims to cover more "out of the box" use cases (like running a subset of applications directly on a 16K kernel without a VM using some tricks). We have chosen FEX-Emu for our stack because we believe it will have higher compatibility with its approach, but both have their uses. box64 is packaged in Fedora, so we encourage users to try it (both natively and within muvm) and let us know how it compares!

Just let it restart, and it should work on the second try. Steam has a timeout for steamwebhelper, and when running under emulation, startup is slow enough that the timeout expires. This usually only happens on a cold startup.

This is caused by the "Disable while typing" touchpad feature. You can turn it off in the touchpad/input settings for your desktop environment.

At this point, we do not support running Windows apps outside of Steam for two reasons:

Once these issues are resolved, you will be able to use wine under muvm to run Windows apps.

Native Linux games should generally work under muvm, as long as they are self-contained and do not depend on complex host system libraries (we ship a large selection of common dependencies, but not everything under the sun).

Non-game productivity apps may work, but window management will probably be quite broken due to Sommelier bugs (see the previous answer).

Wayland is not supported inside the VM at this time (Sommelier is a Wayland compositor, but it is used in an XWayland-exclusive mode). As most of the legacy x86/x86_64 applications people want to run are X11 applications, we are focusing on X11 support first. This means that you cannot run native Wayland apps inside the VM at this time. Of course, the host desktop is still a Wayland desktop, and X11 support is provided by XWayland.

As the VM does not pass through any host hardware other than the GPU and the virtual filesystem, you will not be able to use applications that require direct hardware access. We use software passthrough for the following interfaces:

No, muvm does not work like a traditional whole-system VM. While it does also use KVM as a backend for efficient virtualization, the concept is very different to traditional VMs running entirely separate guest operating systems. The guest kernel is a special kernel optimized to start up in a fraction of a second, and the VM monitor passes through the host filesystem mostly as-is. There is no low-level hardware passthrough (USB, etc.) and instead we focus on higher-level software protocol passthrough, like X11/Wayland. The VM does not run its own standalone init system, only some minimal startup code. This means that the environment within the VM should "feel" the same as the host OS from the point of view of applications, just with a 4K page size instead of a 16K page size.

Since the VM monitor runs as your own user identity, it cannot gain root privileges. "root" inside the VM still only has the privileges of your own user, so sudo doesn’t make much sense (and in fact doesn’t work). We recommend installing software that you want to use with muvm+FEX under your home directory. For software that is designed to be installed under /opt or similar, we recommend performing the installation steps manually on the host OS, and then just running the app under muvm.

Communication is mostly limited to the host filesystem. The VM shares your home directory (and in fact most of the filesystem) with the host, so any files you create on one side will be visible on the other.

In the future, we will enable virtiofs-DAX, which will allow for shared memory communication (/dev/shm) between guest apps and host apps, but this isn’t quite ready yet.

It is also possible to share audio between host and guest apps by using the PulseAudio forwarding support. For example, you can record guest audio by using a recording app on the host and recording from the system "Monitor" device. You can also configure virtual sinks/sources in the host using the normal PipeWire mechanisms, and direct guest apps to use those for audio I/O to have custom audio routing and processing. Note that the native PipeWire protocol is not passed through, only the PulseAudio protocol which is more limited (but more commonly used by applications). ALSA applications are supported via the pulse plug-in.

By default, muvm passes through as many CPUs as there are performance cores on your host machine, and pins those vCPUs to the physical performance cores. Since the host CPU scheduler has no visibility into the guest CPU scheduler, this ensures that performance is consistent. You can modify this behavior with the muvm --cpu-list=CPU_LIST option.