[RyanTheTide]

omacom sync, lane m3. This brings the three independent GPUVM and deferred close fixes from the omacom M3 series and records a verdict for all 20 commits in the lane. The T8122 (M3 MacBook Air) GPU runtime itself is held, for the reasons below.

What this brings

• drm/gpuvm: initialize BO unmap result. drm_gpuvm_bo_unmap() returned an uninitialised ret when a VM BO had no mappings left. Our deferred close path can reach that case, and a garbage error marks the cleanup failed.
• rust: drm: gpuvm: add filtered object unmap. Adds unmap_object_where(), an allocation-free walk that removes only the mappings of one GEM that a filter selects.
• drm/asahi: keep new bindings after deferred GEM close. A dma-buf reimport can return the same GEM while the cleanup for a closed handle is still queued. Before, that cleanup removed every mapping of the GEM, including ones bound after the close. Each binding now carries a sequence number, and the deferred cleanup removes only what the close covered. Adapted for our SG lease setup (prepare_sgt_segments()).

The deferred close path (mmu/lifetime.rs) runs on VMs created with_status (G17, Neo) or with_tracked_status (G15, G16 on the J616s). G13/G14 VMs have no lifetime and keep drop_mappings_now(), which is unchanged. The only new work on M1/M2 is one atomic increment per map step.

Per-commit verdicts

omacom	author	subject	verdict	reason	ours
e51f1082fa23	Scott Jones	drm/asahi: m3: restore the 7.1.12 T8122 runtime sources, unwired	HELD	Runtime source (about 14,600 lines, Generated-by: LLM). Lands only with the parameter layer replaced by identity constants, see below
ad52c9b317f6	Scott Jones	drm/asahi: m3: start the T8122 runtime on 7.2	HELD	The wiring is sound in outline (registration, RTKit-owned completion worker, shared VM lifetime, adopted UAT) but it adds 34 module parameters through a raw __param macro, starts only through the asahi.t8122_start experiment, and on 7.3 conflicts in driver.rs, file.rs, gpu.rs, mmu.rs; after resolving those it still fails to build (16 rustc errors, see Gates)
d8ecb2e70637	Scott Jones	pmdomain: apple: pmp-report: keep the T8122 14.x GPU readiness for the M3 runtime	HELD	Correct and harmless for other SoCs (T8122 machine check, -ENODEV without the config), but APPLE_T8122_GPU_PMP_LINK is only selected by DRM_ASAHI_M3_T8122, so it is dead code until the runtime lands. Conflicts with our T8132 report branch (trivial)
8e864a57c40e	Scott Jones	drm/asahi: m3: map each VM's dummy page where the firmware expects it	HELD	Adds gpu::Gpu::unknown_page() whose only non-default user is the runtime
75c5823f60b3	Scott Jones	drm/asahi: m3: quarantine a failed job's VM before signalling its fence	HELD	Runtime only (m3_submit.rs)
d2666d8ca7a5	Scott Jones	drm/asahi: m3: keep the adopted UAT until ASC stops on a failed start	HELD	Runtime only (m3_runtime.rs)
e8023bba60e6	Scott Jones	drm/asahi: m3: don't let the compute stream debug read fail a job	HELD	Runtime only (m3_compute.rs)
4888ad0a0fa6	Scott Jones	tools/asahi: test the T8122 14.x PMP wait in the supplier suite	HELD	Tests d8ecb2e70637; goes in with it
9dff537d1732	Scott Jones	drm/asahi: build the T8122 runtime without the G15 backend	HELD	Gates the shared UAT adoption on a new DRM_ASAHI_UAT_ADOPTION; ours gates the same items on any(G15, G16) for the J616s handoff, so every hunk in mmu.rs/pgtable.rs needs rework to keep G16. Needs its build fix follow-up (omacom PR 256) and touches g15/ (g15 lane)
2151a3442ee9	Eryk Wieliczko	drm/gpuvm: initialize BO unmap result	PORTED	Real bug: drm_gpuvm_bo_unmap() returns uninitialised ret for a VM BO with no mappings; our tree had it	3fa56dc
a8f459d96480	Eryk Wieliczko	rust: drm: gpuvm: add filtered object unmap	PORTED	Additive unmap_object_where(), needed by the next commit; existing callers keep their behaviour	6b00531
13c3371ce23d	Eryk Wieliczko	drm/asahi: keep new bindings after deferred GEM close	PORTED	Deferred close removed bindings made after the close of a reimported GEM. Adapted to our SG lease setup; a Ryan fixup moves it to exec_lock_vm() after the aurora-wip merge	bbe1524 + 2d5d141
61eccdbbee80	Scott Jones	drm/asahi: m3: start the GPU firmware once per boot	HELD	Runtime only (the policy helper it adds to our m3_batch_policy.rs has no other caller)
6246daaee9d2	Scott Jones	drm/asahi: m3: don't quarantine VMs for packets the firmware never saw	HELD	Runtime only
80958cd5a495	Scott Jones	drm/asahi: m3: take the start pin with try_module_get	HELD	Runtime only
8a31fe185686	Chris Kearney	drm/asahi: prepare supported M3 native GPU defaults	REJECTED	No commit body. Turns on DRM_ASAHI_M3_T8122 and DRM_ASAHI_G15 in asahi.config (DJ's file; G15 is the g15 lane's call) and makes the start a board default through the knob layer (start_for_board) while keeping asahi.t8122_start=0 and the state 2 of 5 cap. The intent (start by identity on J613/J615) is what we want, but it has to come from the knob-free rewrite
fc5391123e5a	Chris Kearney	drm/asahi: align M3 Air startup diagnostics with board defaults	REJECTED	Text follow-up describing 8a31fe185686's knob semantics
18c64047548c	DjDeveloperr	drm/asahi: m3: admit clients that ask for the parameters up to the HAL generation	HELD	Correct (our GET_PARAMS also grew past 600 bytes with 632e467, so the whole-struct check would refuse older Mesa). Only m3_client.rs of the runtime uses it; take it with the runtime
1032928116c1	DjDeveloperr	drm/asahi: apply the GPU memory limits and RSS attribution to G17 only	HELD	Policy decision. Our 464cb2e deliberately set the limits for every Mac from the main probe, and 632e467 exports them in GET_PARAMS. DJ's point stands that G15/G16 (separate probes) get RSS attribution but no limits, which is inconsistent either way. Ryan and DJ should pick one rule; this commit would remove the M1/M2 limits
6c66b41af3e7	DjDeveloperr	drm/asahi: restore the DRM driver's module owner	SUPERSEDED	Our Rust DRM layer sets fops.owner from the driver's OwnerModule (3ef9758, rust/kernel/drm/device.rs:211); drm::Driver::MODULE does not exist here, so the commit would not build	3ef9758

Why the T8122 runtime is held

Our tree dropped the runtime on purpose during the unified 7.2.10 port (2026-10-18). The M3-only split commits (for example 700bfca, 1de2dbd, 997a7db) say the backend is compile-only and that registration and the shared GPUVM and event wiring remain pending. 80797e4 gates the four M3 compatibles to -ENODEV before any resource setup. The port report stopped at the mechanical port boundary and listed four open design points: an event and runtime owner that works across optional render node registration, current GPUVM retained backing, replacement fault and I/O map interfaces, and the shared UAPI. The T8122 register list and InitData provenance hold was cleared later (bc0a841, ed90e7b, 278d0ab, 7231c0b, 6ad3570, 1e8f813). So this was a deferral waiting for a redesign, not an accident of the rebase, and nothing replaced it.

omacom ad52c9b317f6 is that redesign done on 7.2, and it answers most of the open points (registration through drm::Registration, the completion worker owned by the RTKit state, the shared VM job lifetime, Uat::new_adopted). It still cannot come in as it is:

1. Knobs. The runtime registers 34 module parameters through its own m3_param! macro, which writes raw kernel_param entries into __param and bypasses module!. Four of them are writable at run time. The T8122 start is an "experiment" (t8122_knobs.rs, t8122_start.rs) armed by asahi.t8122_start, with asahi.t8122_* overrides for InitData version, Fender size, clock generator, SGX setup, both unit masks and a performance state cap that defaults to 2 of 5. Aurora selects behaviour from DT, chip and firmware identity and Kconfig, so this layer has to become identity-selected constants first. That rewrite touches most of the roughly 15,000 lines the runtime adds, and we have no M3 to check that a rewritten start still starts.
2. Config. DRM_ASAHI_M3_T8122 is default n and depends on DRM_ASAHI_G15, which our universal config leaves off. Turning it on means editing asahi.config (DJ's file), which omacom 8a31fe185686 does together with turning G15 on. That is a decision for DJ and Ryan, and the G15 part belongs to the g15 lane.
3. Shared code drift. On our 7.3 tree the series conflicts in driver.rs, file.rs, gpu.rs, mmu.rs, pmp-report.c, Kconfig, Makefile, asahi_core.rs and pgtable.rs. omacom 9dff537d1732 gates the shared UAT adoption on a new DRM_ASAHI_UAT_ADOPTION, while ours gates it on any(G15, G16) for the J616s handoff, so it needs a rework that also covers G16. Its follow-up (omacom PR 256, three more cfg fixes) is not in this lane.
4. Build on 7.3. With the series applied on our tree (conflicts resolved, 9dff537d1732 left out, CONFIG_DRM_ASAHI_G15=y CONFIG_DRM_ASAHI_M3_T8122=y), rustc stops at 16 errors in its first pass, so more may follow once these are fixed. Three are m3_params.rs asking for the asahi.t8122_hwdata_418c parser that our 229652c removed on purpose because it was a knob. Four are crate::THIS_MODULE, which our module layer no longer provides. The rest is API drift: gpu::Gpu::new_queue and map_timestamp_buffer signatures, a duplicate F32::to_bits, Coherent::dma_handle, and type changes in m3_device.rs, m3_submit.rs and mmu/m3.rs. The pmp-report part builds. The trial ref is kept locally on the buildbox and is not pushed.

What has to happen for the runtime to land: rewrite the parameter layer as T8122 identity constants (keep the values of today's defaults), decide the performance state cap, rework the UAT adoption gate to include G16, get a clean W=1 build with DRM_ASAHI_M3_T8122=y and G15=n, agree the asahi.config change with DJ, and boot it on a J613 or J615. The commits that only make sense with the runtime (the pmp-report T8122 wait, the dummy page hook, the quarantine and start fixes, DJ's client admission size fix) go in with it.

Gates

Base for every comparison: aurora-wip e4b030d (the tip this branch merges). Head 2d5d141.

gate	base	branch
1. Fleet config build (Fedora Asahi base + asahi.config, survival check, distro gates, Image modules dtbs)	rc 0, 0 warnings	rc 0, 0 warnings; asahi.config 136 requested, 0 mismatches; 18/18 distro gates
2. W=1 of drivers/gpu/drm/drm_gpuvm.o and drivers/gpu/drm/asahi/ (rebuilds rust/kernel)	0 warnings	0 warnings
3. KUnit, arm64/LLVM, asahi + DRM config	999 run, 949 pass, 48 fail, 2 skip	999 run, 949 pass, 48 fail, 2 skip, identical per-test results. All 42 asahi suites pass. The 48 failures are DRM HDMI and TTM tests that fail the same on base
4. Host tests run-host-tests.py	158 ok, 0 fail	158 ok, 0 fail
4. apple-dcp selftests	83 ok, 0 not ok	83 ok, 0 not ok

Before the aurora-wip merge the same three commits on 3f53cb3 also gave 0/0 warnings, identical KUnit (995 run) and identical host tests (148 ok and the same 10 pre-existing avd-av1-tail failures that #754 has since fixed). There is no KUnit suite for drm_gpuvm.c or the Rust gpuvm binding in this config.

Hardware plan (not run here)

Artifacts: buildbox /srv/aurora/fast/o/omacom-sync-20261101/m3/out-final/ (release 7.3.0-aurora-omsync-m3: Image, modules tar.zst, dtbs, release.config, SHA256SUMS).

The changed code is the shared GPUVM unmap and the deferred close path. It runs on every machine; the deferred close part only on VMs with job lifetime tracking (G17, G15, G16).

• Neo (J700, T8140, G17): main target. Compare baseline and candidate dmesg -p3 | wc -l, aurora-diag check --expect. Run the GPU regression gate and gpubench-stress --all --kernel-log (exit and kill with work in flight cover deferred close). Then a dma-buf reimport workload: GNOME session with screenshots and screen recording, Firefox video, close and reopen apps repeatedly; look for GPU faults, MMU: deferred object unmap failed, or VMs left with cleanup failed.
• J616s (M4 Pro, T6041, G16): same dmesg and aurora-diag comparison, desktop session plus the same reimport workload; G16 VMs use with_tracked_status, so deferred close runs here too.
• M1 Pro (T6000, headless) and M2 (T8112): G13/G14 VMs have no job lifetime and keep drop_mappings_now(). Check dmesg and aurora-diag, and run a short headless GPU job loop (for example the CTS smoke set or vkcube offscreen) to cover the drm_gpuvm_bo_unmap() change and the new per-map sequence counter.
• Nothing in this PR is T8122 or T603x only.

What only omacom hardware can prove

Nothing in this PR runs only on M3 hardware. The deferred close fix was reported by its author against an M3 Pro (G15) with KWin (50/50 GPU regression cases, 10 Settings launches, 10 theme cycles, no faults). That claim is theirs and we did not reproduce it. On our machines the same code runs on the J616s (G16) and the Neo (G17).

🤖 Generated with Claude Code

[RyanTheTide]

Folded into the single omacom up-port branch omacom-sync/all (head b463cf8), which carries this lane unchanged as a merge. One PR for the whole up-port follows once the combined kernel has passed the hardware regression run. Per-commit verdicts above stay as the record.