muvm under 7.1.5 - issue with --gpu-mode=drm

[siffredinho]

Muvm seems to act different under kernel 7.1.5 compared to 7.0.13. I use wine (app-emulation/wine-staging under gentoo with +arm64ec and +wow64). The same happens with steam under FEX-Emu and I'm quite positive that it's the same with other software running under muvm.

So let's start with the first try (the --passt option is necessary, because passt doesn't like IP Aliases).

boris@morrigu ~ $ RUST_BACKTRACE=full RUST_LOG=info muvm --passt-args "-a 192.168.0.21" bash
No IPv6 nameserver available for NDP/DHCPv6
Using default interface naming scheme 'v260'.
boris@morrigu ~ $ rm -rf .wine
boris@morrigu ~ $ wineboot -i
wine: created the configuration directory '/home/boris/.wine'
002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
002c:fixme:winediag:loader_init wine-staging 11.14 is a testing version containing experimental patches.
002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org.
004c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0054:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
004c:fixme:keyboard:klid_from_xkb_layout Unknown variant "de_mac"
[2026-07-27T22:51:36.829533Z ERROR krun_vmm::linux::vstate] Failure during vcpu run: Bad address (os error 14)
      [2026-07-27T22:51:36.829561Z INFO  krun_vmm] Vmm is stopping.

Let's use all three --gpu-mode options. First one (the default again) is drm (not necessary to paste this, but anyway...).

boris@morrigu ~ $ RUST_BACKTRACE=full RUST_LOG=info muvm --gpu-mode=drm --passt-args "-a 192.168.0.21" bash
No IPv6 nameserver available for NDP/DHCPv6
Using default interface naming scheme 'v260'.
boris@morrigu ~ $ rm -rf .wine
boris@morrigu ~ $ wineboot -i
wine: created the configuration directory '/home/boris/.wine'
002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
002c:fixme:winediag:loader_init wine-staging 11.14 is a testing version containing experimental patches.
002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org.
004c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0054:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
004c:fixme:keyboard:klid_from_xkb_layout Unknown variant "de_mac"
[2026-07-27T22:54:04.144580Z ERROR krun_vmm::linux::vstate] Failure during vcpu run: Bad address (os error 14)
      [2026-07-27T22:54:04.144610Z INFO  krun_vmm] Vmm is stopping.

Now venus, which works (more or less) fine.

boris@morrigu ~ $ RUST_BACKTRACE=full RUST_LOG=info muvm --gpu-mode=venus --passt-args "-a 192.168.0.21" bash
No IPv6 nameserver available for NDP/DHCPv6
Using default interface naming scheme 'v260'.
boris@morrigu ~ $ rm -rf .wine
boris@morrigu ~ $ wineboot -i
wine: created the configuration directory '/home/boris/.wine'
002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
002c:fixme:winediag:loader_init wine-staging 11.14 is a testing version containing experimental patches.
002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org.
004c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0054:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
004c:fixme:keyboard:klid_from_xkb_layout Unknown variant "de_mac"
could not connect vdrm
Error opening virtio-gpu device for Asahi native context
004c:err:vulkan:init_physical_devices Failed to enumerate physical devices, res -3
0054:fixme:keyboard:klid_from_xkb_layout Unknown variant "de_mac"
could not connect vdrm
Error opening virtio-gpu device for Asahi native context
0054:err:vulkan:init_physical_devices Failed to enumerate physical devices, res -3
libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
0054:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002
0054:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
0054:err:ole:apartment_get_local_server_stream Failed: 0x80004002
0054:err:ole:start_rpcss Failed to open RpcSs service
004c:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002
004c:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
004c:err:ole:apartment_get_local_server_stream Failed: 0x80004002
0044:fixme:keyboard:klid_from_xkb_layout Unknown variant "de_mac"
002c:fixme:keyboard:klid_from_xkb_layout Unknown variant "de_mac"
<...>
0024:fixme:winediag:loader_init wine-staging 11.14 is a testing version containing experimental patches.
0024:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org.

For a comparison, --gpu software.

boris@morrigu ~ $ RUST_BACKTRACE=full RUST_LOG=info muvm --gpu-mode=software --passt-args "-a 192.168.0.21" bash
No IPv6 nameserver available for NDP/DHCPv6
Using default interface naming scheme 'v260'.
boris@morrigu ~ $ rm -rf .wine
wboris@morrigu ~ $ wineboot -i
wine: created the configuration directory '/home/boris/.wine'
002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
002c:fixme:winediag:loader_init wine-staging 11.14 is a testing version containing experimental patches.
002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org.
004c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0054:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
004c:fixme:keyboard:klid_from_xkb_layout Unknown variant "de_mac"
could not connect vdrm
Error opening virtio-gpu device for Asahi native context
004c:err:vulkan:init_physical_devices Failed to enumerate physical devices, res -3
0054:fixme:keyboard:klid_from_xkb_layout Unknown variant "de_mac"
could not connect vdrm
Error opening virtio-gpu device for Asahi native context
0054:err:vulkan:init_physical_devices Failed to enumerate physical devices, res -3
could not connect vdrm
Error opening virtio-gpu device for Asahi native context
libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
could not connect vdrm
Error opening virtio-gpu device for Asahi native context
libEGL warning: egl: failed to create dri2 screen
could not connect vdrm
Error opening virtio-gpu device for Asahi native context
libEGL warning: egl: failed to create dri2 screen
could not connect vdrm
Error opening virtio-gpu device for Asahi native context
libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
could not connect vdrm
Error opening virtio-gpu device for Asahi native context
libEGL warning: egl: failed to create dri2 screen
could not connect vdrm
Error opening virtio-gpu device for Asahi native context
libEGL warning: egl: failed to create dri2 screen
004c:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002
004c:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
004c:err:ole:apartment_get_local_server_stream Failed: 0x80004002
0054:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002
0054:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
0054:err:ole:apartment_get_local_server_stream Failed: 0x80004002
002c:fixme:keyboard:klid_from_xkb_layout Unknown variant "de_mac"
<...>
0024:fixme:winediag:loader_init wine-staging 11.14 is a testing version containing experimental patches.
0024:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org.

So, let's ask strace about it...

boris@morrigu ~ $ RUST_BACKTRACE=full RUST_LOG=info muvm --passt-args "-a 192.168.0.21" bash
No IPv6 nameserver available for NDP/DHCPv6
Using default interface naming scheme 'v260'.
boris@morrigu ~ $ rm -rf .wine
strace -f -e trace=ioctl,memory,mmap,munmap,mprotect wineboot -i
<...>
[pid   289] mmap(NULL, 27012, PROT_READ, MAP_SHARED, 17, 0) = 0xffff99443000
[pid   289] ioctl(16, DRM_IOCTL_VERSION, 0x7dad50c470) = 0
[pid   289] ioctl(16, DRM_IOCTL_VERSION, 0x7dad50c470) = 0
[pid   289] ioctl(16, DRM_IOCTL_VERSION, 0x7dad50c470) = 0
[pid   289] ioctl(16, DRM_IOCTL_VERSION, 0x7dad50c470) = 0
[pid   289] ioctl(16, DRM_IOCTL_VIRTGPU_GET_CAPS, 0x1001099d0) = 0
[pid   289] ioctl(16, DRM_IOCTL_TEGRA_GEM_GET_TILING or DRM_IOCTL_VC4_GEM_MADVISE or DRM_IOCTL_VIRTGPU_CONTEXT_INIT, 0x100109920) = 0
[pid   289] ioctl(16, DRM_IOCTL_VIRTGPU_RESOURCE_CREATE_BLOB, 0x1001099d0) = 0
[pid   289] ioctl(16, DRM_IOCTL_EXYNOS_GEM_MAP or DRM_IOCTL_LIMA_GEM_CREATE or DRM_IOCTL_NOVA_GEM_CREATE or DRM_IOCTL_QAIC_CREATE_BO or DRM_IOCTL_QXL_MAP or DRM_IOCTL_TEGRA_GEM_MMAP or DRM_IOCTL_V3D_WAIT_BO or DRM_IOCTL_VC4_WAIT_SEQNO or DRM_IOCTL_VGEM_FENCE_ATTACH or DRM_IOCTL_VIRTGPU_MAP, 0x1001098c8) = 0
[pid   289] mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_SHARED, 16, 0x100002000) = 0xffff99402000
[pid   289] ioctl(16, DRM_IOCTL_ETNAVIV_GEM_INFO or DRM_IOCTL_OMAP_GEM_NEW or DRM_IOCTL_PANFROST_MMAP_BO or DRM_IOCTL_V3D_MMAP_BO or DRM_IOCTL_VC4_CREATE_BO or DRM_IOCTL_VIRTGPU_GETPARAM, 0x1001098e0) = 0
[pid   289] ioctl(16, DRM_IOCTL_VIRTGPU_EXECBUFFER, 0x1001098e8) = 0
[pid   289] ioctl(16, DRM_IOCTL_VIRTGPU_EXECBUFFER, 0x1001098c8) = 0
[pid   289] ioctl(16, DRM_IOCTL_VIRTGPU_RESOURCE_CREATE_BLOB, 0x1001098f8) = 0
[pid   289] ioctl(16, DRM_IOCTL_PANFROST_GET_BO_OFFSET or DRM_IOCTL_TEGRA_OPEN_CHANNEL or DRM_IOCTL_VIRTGPU_RESOURCE_INFO, 0x100109968) = 0
[pid   289] ioctl(16, DRM_IOCTL_VIRTGPU_EXECBUFFER, 0x100109878) = 0
[pid   289] ioctl(16, DRM_IOCTL_VIRTGPU_RESOURCE_CREATE_BLOB, 0x1001098f8) = 0
[pid   289] ioctl(16, DRM_IOCTL_PANFROST_GET_BO_OFFSET or DRM_IOCTL_TEGRA_OPEN_CHANNEL or DRM_IOCTL_VIRTGPU_RESOURCE_INFO, 0x100109968) = 0
[pid   289] ioctl(16, DRM_IOCTL_EXYNOS_GEM_MAP or DRM_IOCTL_LIMA_GEM_CREATE or DRM_IOCTL_NOVA_GEM_CREATE or DRM_IOCTL_QAIC_CREATE_BO or DRM_IOCTL_QXL_MAP or DRM_IOCTL_TEGRA_GEM_MMAP or DRM_IOCTL_V3D_WAIT_BO or DRM_IOCTL_VC4_WAIT_SEQNO or DRM_IOCTL_VGEM_FENCE_ATTACH or DRM_IOCTL_VIRTGPU_MAP, 0x1001099d8) = 0
[pid   289] mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_SHARED, 16, 0x10000a000) = 0xffff993dc000
[2026-07-27T23:18:16.182171Z ERROR krun_vmm::linux::vstate] Failure during vcpu run: Bad address (os error 14)
      [2026-07-27T23:18:16.182197Z INFO  krun_vmm] Vmm is stopping.

The last 2 lines of strace look fishy. Maybe it's just a Layer 8 (aka PEBCAK) issue, then I'm sorry. Just wanted to open this issue in case there are other people running into the same issue.

PS: Thank you for all the stuff you did for all of us "Asahi User".

[hubleyku]

I'm just chiming in that I'm also having this problem. Steam refuses to launch unless I use --gpu-mode=software. If I revert to the previous kernel, it works fine.

[ccharon]

I think i hit the same problem, (gentoo asahi, chadmed overlay)
worked around it by:

https://github.com/ccharon/muvm-steam-fixes/blob/main/muvm-dmabuf-fixup.c

its about making readonly mmap areas read write, an so that gets added to the ld libray path.

I was wondering on reddit if i found something or if its just my problem, someone hinted me to this issue

[siffredinho]

Ccharon: I also use the same distribution and overlay and tested your .so hotfix under wine and steam (arm64 version) with a $random game. All worked fine.

Thank you!!

[ccharon]

Ccharon: I also use the same distribution and overlay and tested your .so hotfix under wine and steam (arm64 version) with a $random game. All worked fine.

Thank you!!

having spent some more time, I came up with a better workaround that does not need the so. its a patch for libkrun
put https://github.com/ccharon/muvm-steam-fixes/blob/main/libkrun-dmabuf-prefault.patch into: /etc/portage/patches/dev-libs/libkrun/ then rebuild libkrun (emerge -1 libkrun)

after that the workaround with the so is not needed.

[Mershl]

Ccharon: I also use the same distribution and overlay and tested your .so hotfix under wine and steam (arm64 version) with a $random game. All worked fine.
Thank you!!

having spent some more time, I came up with a better workaround that does not need the so. its a patch for libkrun put https://github.com/ccharon/muvm-steam-fixes/blob/main/libkrun-dmabuf-prefault.patch into: /etc/portage/patches/dev-libs/libkrun/ then rebuild libkrun (emerge -1 libkrun)

after that the workaround with the so is not needed.

can confirm. the libkrun patch fixes the issue on NixOS as well.

  nixpkgs.overlays = [
    (
      final: prev:
      let
        libkrunPatch = builtins.fetchurl {
          url = "https://github.com/ccharon/muvm-steam-fixes/raw/main/libkrun-dmabuf-prefault.patch";
          sha256 = "0xb9wz6vsw9vp2gi239pblbcg4jy8g26zyprnpp2a57g2ysdy7ja";
        };
      in
      {
        libkrun = prev.libkrun.overrideAttrs (oldAttrs: {
          patches = (oldAttrs.patches or [ ]) ++ [ libkrunPatch ];
        });
      }
    )
  ];

[ccharon]

made a pullrequest. lets see, even if its not a good solution its a reminder :P

https://github.com/libkrun/libkrun/pull/803/changes

[DryfterX]

I think i hit the same problem, (gentoo asahi, chadmed overlay) worked around it by:

https://github.com/ccharon/muvm-steam-fixes/blob/main/muvm-dmabuf-fixup.c

its about making readonly mmap areas read write, an so that gets added to the ld libray path.

I was wondering on reddit if i found something or if its just my problem, someone hinted me to this issue

I'm running Fedora Asahi with Steam locally since it's just me using the laptop. I had some issues with the instructions you have in your repo, namely because the aarch64 version is installed locally (exact error when trying to start steam was /home/dryfter/.local/bin/steam-aarch64: line 9: /usr/bin/steam-aarch64: No such file or directory , so wanted to put what I did here for reference if anyone is only using Steam locally and not system-wide. I did also try the libkrun patch but the location isn't the same and cloning your github was easier.

1. Clone https://github.com/ccharon/muvm-steam-fixes into a directory of your choice, I have a dedicated git clone directory.
   git clone https://github.com/ccharon/muvm-steam-fixes

2. Run the following:
   make
   then
   make install
   then
   command -v steam-aarch64 # must print ~/.local/bin/steam-aarch64

3. Edit the executable to point to local install:
   nano ~/.local/bin/steam-aarch64
   replace every instance of /user/bin/steam-aarch64 in this file with ~/.local/share/Steam/steamrtarm64/steam
   replace /user/bin/steam with ~/.local/share/Steam/steamrtarm64/steam

   This is what it should look like after editing, or just copy this whole thing and paste over the contents of the executable:

#!/bin/sh
# Generated by muvm-steam-fixes (make install). Remove: make uninstall
FIXUP=/home/dryfter/.local/lib/muvm-dmabuf-fixup.so
DBUS=/home/dryfter/.local/lib/muvm-guest-dbus.sh
[ -e "$FIXUP" ] && export LD_PRELOAD="${FIXUP}${LD_PRELOAD:+:$LD_PRELOAD}"
if [ -x "$DBUS" ] && [ -x ~/.local/share/Steam/steamrtarm64/steam ]; then
   exec muvm -x "$DBUS" ~/.local/share/Steam/steamrtarm64/steam "$@"
else
   exec ~/.local/share/Steam/steamrtarm64/steam "$@"
fi

4. Save the executable
5. Start Steam normally

I tested a couple of games and they all seem to work so far. Please let me know if my instructions are incorrect or confusing, I know just enough to get myself into trouble and most of the time not OUT of trouble 🤦🏻‍♂

[slp]

As stated in the libkrun PR (libkrun/libkrun#803), I believe this to be kernel bug. Userspace shouldn't need to pre-fault memory regions, and doing so could have a significant impact on both performance and memory usage. I've proposed this patch for the kernel (the commit description includes an explanation of the root cause): https://lore.kernel.org/kvm/20260729014223.17937-1-slp@redhat.com/T/#u