Regression 7.0.13 → 7.1.5: muvm GPU acceleration dies with KVM EFAULT on dmabuf-backed native-context blobs (M1 Max)

[iwillnotbecomeu]

Summary

Any GPU-accelerated client inside muvm destroys the entire microVM on kernel
7.1.5-400.asahi.fc44.aarch64+16k. libkrun's vcpu takes an EFAULT from KVM_RUN immediately
after the asahi DRM native-context path maps its dmabuf-backed host-visible blobs.

Booting 7.0.13-400.asahi.fc44.aarch64+16k fixes it completely, with byte-identical userspace.

This breaks all Steam / FEX / x86 gaming use, since every one of those paths goes through muvm.

Reproducer

muvm -- glxinfo -B

• 7.0.13: prints Device: Apple M1 Max (G13C C0), Accelerated: yes.
• 7.1.5: prints name of display: :1, then the entire guest process tree ceases to exist and
  muvm exits 1.

No FEX, no x86, no Steam involved — this is a native aarch64 client. Software rendering
(LIBGL_ALWAYS_SOFTWARE=1) succeeds on both kernels, so only the accelerated path is affected.

What actually happens

The guest does not crash — the VM is destroyed. With RUST_LOG=krun_vmm=debug,krun_rutabaga_gfx=debug,krun_devices::virtio::gpu=debug:

DEBUG krun_rutabaga_gfx::virgl_renderer]  drm: asahi_renderer_get_blob:259: blob_id=2, res_id=6, blob_size=16384, blob_flags=0x3
DEBUG krun_devices::virtio::gpu::virtio_gpu] mapping: host_addr=ffe2b2000000, addr=ffe2b2020000, size=16384
DEBUG krun_rutabaga_gfx::virgl_renderer]  drm: asahi_renderer_attach_resource:169: obj=0xffe278000d00, res_id=6
ERROR krun_vmm::linux::vstate]  Failure during vcpu run: Bad address (os error 14)
INFO  krun_vmm]  Vmm is stopping.

Deterministic — fails at the identical point (blob_id=2, blob_flags=0x3) on every run.

Syscall-level detail

strace -f -e trace=mmap,ioctl -yy shows the mappings all succeed; the fault is KVM failing
to resolve them afterwards:

mmap(0xffe2a6000000, 16384, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 516</memfd:asahi-shmem>, 0) = 0xffe2a6000000
mmap(0xffe2a6010000, 16384, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 518</dmabuf:>, 0)          = 0xffe2a6010000
mmap(0xffe2a6020000, 16384, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 520</dmabuf:>, 0)          = 0xffe2a6020000
ioctl(19<anon_inode:kvm-vcpu:0>, KVM_RUN, 0)                                                       = -1 EFAULT

• blob 0 (blob_flags=0x1, MAPPABLE) is backed by a plain memfd — fine.
• blobs 1 and 2 (blob_flags=0x3, MAPPABLE|SHAREABLE) are backed by dmabuf fds obtained via
  DRM_IOCTL_PRIME_HANDLE_TO_FD on /dev/dri/renderD128. The EFAULT follows immediately.

So the mapping is established, but KVM cannot resolve a guest stage-2 fault against those
dmabuf-backed VMAs on 7.1.5. My guess is a change in the VMA flags/lifetime the asahi dmabuf
exporter sets up, but I have not bisected the source.

The kernel logs nothing during the failure (journalctl -k shows zero entries across the
fault window) — consistent with KVM simply returning EFAULT from the ioctl rather than logging
a driver fault.

Userspace is not involved

Each component was independently swapped and the failure is bit-identical on 7.1.5:

Component	Versions tested
Mesa	26.1.5-1.fc44 (Fedora) and 26.0.6-2.fc44 (@asahi copr), via LIBGL_DRIVERS_PATH
virglrenderer	1.3.0-1.fc44 (Fedora) and 1.2.0-1.6.fc44 (@asahi copr), via LD_LIBRARY_PATH
libkrun + libkrunfw	1.19.0 + 5.5.0, and 1.17.4 + 5.2.1, via LD_LIBRARY_PATH

The working (7.0.13) and failing (7.1.5) cases run the same userspace: Mesa 26.1.5-1.fc44,
virglrenderer 1.3.0-1.fc44, libkrun 1.19.0-1.fc44, libkrunfw 5.5.0-1.fc44, muvm 0.6.0-3.fc44.
The kernel is the only difference.

Forcing the classic virgl path instead of native context
(MESA_LOADER_DRIVER_OVERRIDE=virtio_gpu) is not a workaround — virtio_gpu_dri.so fails to
load (glx: failed to create dri3 screen) and the VM dies regardless.

Environment

• Apple M1 Max MacBook Pro
• Fedora Asahi Remix 44
• Bad kernel: 7.1.5-400.asahi.fc44.aarch64+16k (page size 16384)
• Good kernel: 7.0.13-400.asahi.fc44.aarch64+16k
• muvm 0.6.0-3.fc44, libkrun 1.19.0-1.fc44, libkrunfw 5.5.0-1.fc44
• Mesa 26.1.5-1.fc44, virglrenderer 1.3.0-1.fc44
• Guest: kernel 6.12.91 (libkrunfw), page size 4096
• Host GPU works normally outside muvm on both kernels: glxinfo -B reports
  Apple M1 Max (G13C C0), Accelerated: yes

The @asahi kernel copr has no builds between 7.0.13 and 7.1.5, so I could not narrow the range
further with packaged kernels. Happy to test patches or intermediate builds.