[erykwieliczko]

Depends on https://github.com//pull/233; stacked on its branch.

Report T6030 GPU power to PMP so memory bandwidth scales with GPU load.
Setting the report before firmware startup is acknowledged but leaves
bandwidth low. Clear and reassert it after firmware/backend initialization.
Validate the report before taking the power vote and handle failed releases.

Also hold the VM exec lock once during G15 submission validation instead of
relocking the VM and external BOs for every range check and stream read.

Earlier measurement on M3 Pro (J514S), same 10-second vkQuake demo at
1920x1080, same settings and
Mesa git-ea2c18f45c:

Measurement	Before	After
vkQuake	104.5 FPS	372.5 FPS
Compute-copy bandwidth	32.7 GB/s	136.3 GB/s

Memory speed returns to idle after the game. In separate profiled 10-second
runs, the locking change alone reduced kernel CPU time from 3.30 to 1.01 s.

Tested as an Arch kernel package on J514S. Final edits only change comments
and commit messages. Validation: 76 Rust host checks, the C vote fixture,
50/50 hardware GEM cases, and focused/broader Vulkan samples (561 and 7,054
passes), with no failures, crashes or GPU faults. Full CTS was not rerun for that earlier measurement.

Rebased onto #233 at 8525dd8e380a708356ec1ffaef0bbdf266cb328b, which now
starts at kernel integration 937b727ef9a3a9ff09489d597ef4b28f3b6fdbfa.
New head 8824dd6a7aaa2b302ca7b3a77c2022bacc0fbdc8 is installed and booted
with Mesa git-eaf69705c3 from omacom/mesa#17.
The two patches are unchanged by the rebase. 80 host checks, 50 GEM cases,
descriptor readbacks, Settings/theme cycles and the broader/16-set CTS
samples pass. One case in the seven-case group returned a wrong result
once and passed retry (uaddcarry.uint_highp_geometry); cause unresolved.
The owner is running full CTS on this stack. No current Quake measurement
is used as a benchmark because it overlapped that run.

[chriskearney]

Reviewed 8824dd6a7aaa2b302ca7b3a77c2022bacc0fbdc8 on 8525dd8e380a708356ec1ffaef0bbdf266cb328b.

The source assessment is positive: VmReadGuard preserves admission checks while holding the exec lock once, with the guard dropped before the last timestamp mapping can unmap on error. The added PMP report vote is scoped to T6030, the expected supplier and AGX table; failed power-off replies conservatively reassert the report. Our bounded CPU controls exercised the production vote functions with mocked firmware/report operations; those passed. This is distinct from MMIO or scheduler qualification.

We also completed an independent hardware comparison of the combined kernel stack (#233 + this PR on 937b727e) with omacom/mesa#17 at 7c9db520. Original → candidate, medians of five measured runs:

Workload	M3 Pro J516S	M1 MacBook Pro J293	M1 Air J313
vkQuake FPS	186.5 → 658.7	506.9 → 507.4	509.9 → 503.0
vk-work compute, ms	31.507 → 23.817	25.278 → 25.124	24.749 → 24.572
vk-work single-submit, ms	19.026 → 18.905	25.567 → 24.438	25.193 → 25.001
vk-work batched-submit, ms	2.684 → 2.165	3.602 → 3.599	3.460 → 3.502

Each arm has two warmups and five measured runs per case: 28 valid runs, with raw metrics, native-provider bindings, fault records and process drains checked. Quake used the same executable/PAK, 1920×1080 windowed, demo1/969 frames within each comparison. The M3 baseline is its genuine previous custom 7876c8e8 kernel with Mesa 147a62f6190; both M1 baselines use their original 6-1 kernel and Mesa 147a62f6190. Kernel and Mesa changed together, so the M3 3.53× result belongs to the complete tested stack, not this PR alone. These are single A/B observations, without a significance or pacing-cause claim.

Native GL/VK job checks passed. M1/Air OMT individual statuses were unchanged, but their existing failures remain; M3 OMT used a separate packaged-kernel baseline, not fresh custom-kernel OMT. The M1 candidate job also recorded new SPI-HID/magicmouse diagnostics (status mismatch and -110 report/dimensions timeouts), retained as REVIEW_REQUIRED with attribution unresolved. No blanket kernel-regression-free claim follows from these benchmarks.

Our focused CTS attempt provides zero qualified cases: an initial executable-permission failure was followed by a run with eight QPA-reported Pass results whose mapped-provider attribution failed; 444 cases were not run. That is harness failure/unqualified evidence, not a CTS pass or a demonstrated GPU wrong result. Original systems were restored and verified after testing.

I am leaving this as a source-positive comment, with approval pending the dependency's current host-test failures being fixed, the stack retargeted appropriately, and current merge checks passing. #233 is still red in run 40312690407. This review does not waive those gates or the unresolved correctness/feature-coverage limits documented in the stack's PRs.

[chriskearney]

Superseded by #253, now merged as 213f627205d9fe64b2f41607ca21266a5bb8ee2f after Marcelo's approval and passing PR and merge-queue CI.

Eryk's four commits from this #233/#238 stack retain their original authorship, sign-offs, provenance and unchanged stable patch IDs. The carry repairs the host fixtures that blocked CI. The original combined-stack hardware/benchmark review stays here; the carry binary itself has not been hardware-booted. The PMP power fix remains T6030-specific, while the shared G15 correctness/locking changes retain their supported-path scope. Closing this original PR to avoid merging the same work twice. Thanks, Eryk.