[arslanrakh]

Fixes the guest side of omacom/omarchy#18111: on M3 (G15S), Vulkan inside muvm finds no GPU, so nothing run through muvm + FEX (Steam, x86 games) gets acceleration.

Cause

The retained G15 kernel speaks the Mesa-751 wire. On the native path, agx_open_device normalizes its feature word (agx_g15_wire_features) and agx_submit repacks every command buffer (agx_g15_wire_pack). Both are skipped under virtio (if (!dev->is_virtio && ...), from 97a65d8: "Preserve the canonical paths for other devices and virtio").

virglrenderer forwards GET_PARAMS (group 0) and the SUBMIT command buffer to the same G15 kernel unchanged (asahi_ccmd_get_params / asahi_ccmd_submit). So the guest sees the raw 0x3e features and fails agx_params_native_kernel_abi_supported:

Incompatible native AGX3 kernel contract (features 0x3e); use the kernel matched to this Mesa build; ...

asahi_proto.h is identical to virglrenderer 1.3.0's, so the guest and host protocol already agree.

Change

• agx_device.c: apply the G15 feature normalization under virtio too, but mask VM_STATUS and VM_STATUS_MIRROR for virtio guests. virglrenderer rejects param_group != 0, and hk_check_status / hk_init_vm_status_mirror issue raw DRM_IOCTL_ASAHI_GET_PARAMS on the guest virtio-gpu fd, which would turn every wait into a device loss.
• agx_device_virtio.c: when g15_legacy_wire is set, translate the command buffer with agx_g15_wire_pack straight into the ccmd payload (the output is never larger than the input), and shrink cmdbuf_size and hdr.len. Also check the request calloc.

The native host path is unchanged.

Testing

On a 16" M3 Pro (Mac15,7, G15S B1), linux-aurora 7.2.11.aurora14-1, muvm 0.7.0, libkrun 1.19.6, virglrenderer 1.3.0. I used a Vulkan-only build loaded through VK_ICD_FILENAMES, with system packages untouched.

	before	after
aarch64 guest vulkaninfo	Incompatible native AGX3 kernel contract	Apple M3 Pro (G15S B1), Borealis
aarch64 guest vkmark headless 1080p, full suite	—	score 3789–3848, 13/13 scenes
x86_64 guest via FEX vulkaninfo	no x86 driver	Apple M3 Pro (G15S B1), Borealis
x86_64 guest via FEX vkmark headless 1080p, full suite	—	score 4011, 13/13 scenes
host vkmark cube 1080p (native path)	7224 fps	unchanged

The aarch64 results were first measured on a196911, then rebuilt and retested on this branch (integration/aurora b7b03c5). I built the x86_64 driver from the same patch on a196911 under FEX, with the aarch64-built mesa_clc / vtn_bindgen2 / asahi_clc as --native-file binaries, as in the mesa-aurora PKGBUILD tools stage. There were no asahi kernel errors on the host during any run.

Not tested: i386, GL/Zink in the guest, real games, and the unit test suite (-Dbuild-tests=false).

Packaging follow-up (outside this repo): x86_64 and i386 builds of mesa-aurora with this patch, shipped as a FEX overlay in place of the stock mesa-fex-emu-overlay-*.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge.

Summary

Enables retained G15 wire support for virtio guests without changing the native submission path.

• G15 Vulkan guests can use the retained GPU through virtio.

No actionable issues found. No builds or tests were run.

Author arslanrakh explicitly identifies disabled VM status checks as intentional: those queries cannot reach the host through the current virtio path.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Read GPU parameters] --> B{Retained G15 signature?}
  B -->|No| C[Keep existing path]
  B -->|Yes| D[Normalize features]
  D --> E{Virtio guest?}
  E -->|No| F[Keep native packing path]
  E -->|Yes| G[Mask unsupported VM status features]
  G --> H[Pack commands into request]
  H --> I[Append external resources after packed commands]
  I --> J[Send request with updated length]

Loading

_{Reviews (1) · Last reviewed commit: "asahi: translate the retained G15 wire u..." · Reviewed by Greptile}