[jgoyvaerts]

The asahi VM takes GpuVm::exec_lock() (drm_gpuvm_exec_lock()) for read-only VM queries and for every map and unmap. That locks the VM reservation plus the reservation of every external object, so each call costs O(external objects).

Under virtio-gpu (muvm/libkrun) every guest BO is external, because blobs are mapped through dma-buf export. With a game holding ~15k BOs, each submit spent 12-20 ms in drm_gpuvm_prepare_objects() validating its ranges, and each bind about a millisecond more. CS2 under FEX/muvm was capped at single-digit fps by that alone.

This VM is IMMEDIATE_MODE and DRM_GPUVM_RESV_PROTECTED. VA updates need the VM reservation (extobj list, VM data) and each object's gpuva lock (which the link and unlink paths take). The driver never validates, adds fences through GPUVM, or calls drm_gpuvm_bo_evict(), the paths that need an object's own reservation.

1. Read-only queries (covers_range*, translate_offset, vm_context_mask, new_execution_context, capacity) take GpuVm::lock_inner(), the VM reservation alone. Every page-table and mapping change holds it, so readers see a consistent snapshot.
2. VA updates (map_in_range_with_mode, map_at, bind_object, map_io, unmap_range_commit, drop_mappings_now, the user bind batch) take the new GpuVm::exec_lock_vm(). It is the drm_exec_until_all_locked() loop of drm_gpuvm_exec_lock() without drm_gpuvm_prepare_objects(): the VM reservation, plus obj if it is external. Backing is pinned and its segments copied before any reservation is taken. The low-memory unmap path already ran under the VM reservation alone.

Residency restoration and the other lock_vm() users keep the full lock.

Testing

J616s (T6040, 25G83). Both commits have been in our daily kernel since 2026-10-26, on integration 9cbdd0734d9 and then 5ca226e3c40 (patch-identical; this branch is on e3a9c0a58):

• CS2 under FEX/muvm: submits no longer stall in drm_gpuvm_prepare_objects(). Without these commits the game was capped in single digits; with them the menu is GPU-bound (~22 fps at 1440p, the GPU queue busy 97% of the time).
• Desktop compositor, GL and Vulkan clients; glmark2 60 s and the vk-default 1/2000 slice (769 pass / 0 fail), with 0 firmware recoveries.
• Each commit builds on its own; asahi KUnit 163/163 on each. No new warnings.

Not tested with lockdep enabled.

Assisted-by: LLM

[RyanTheTide]

Merged into integration/aurora. Hardware: passed on the M2, M1 Pro and Neo in the integration candidate (integration/aurora with this, #556 and the ISP recovery series), GPU compute and readback plus glmark2 clean and no new err-level lines. J616s on aurora-wip with the same three: 4 glmark2 runs around 7000 with a second client submitting a hanging dispatch alongside, no GPU faults, journalctl -k -p 3 empty, no WARN or DART faults. Thanks!