Performance Research A05 APU Lock Contention

APU frame-lock contention

A05 — Implementation and validation notes

Field	Value
Evidence state	Source-backed ownership boundary; contention value unmeasured here
Inspected source	322986f4c5502b3fa887a9605ac8cd88e9b2c579
First experiment	Measure vCPU-blocking wait, then isolate one immutable work unit
Scope	Addendum dated September 15, 2026; not a current-main benchmark or implementation status

Unproven performance research · Performance research — common test protocol · Performance research — reproducible checks

Evidence and implementation reasoning

Source evidence. The frame thread holds the APU lock while performing the frame sequence; GP/EP writes also acquire it. Reset and snapshot paths explicitly address BQL/APU-lock inversion and wait for the APU to become idle. These are real ownership constraints, not optional synchronization. APU thread and lifecycle, DSP MMIO writes.

Research direction. Measure lock hold time, acquisition wait, ownership transitions, and the vCPU's lost critical-path time. A useful redesign might prepare an immutable work description under the lock, perform independent computation outside it, then publish at a defined boundary. However, guest voice-control data is also RAM-backed: taking this mutex does not freeze every possible guest memory mutation. A correct snapshot protocol must account for that separately. Voice accessors.

In-the-wild support. QEMU's IOThread design explicitly separates suitable work from the BQL and uses drained sections for lifecycle operations. This supports the architectural direction, not copying a lock-removal pattern verbatim into the APU. QEMU IOThreads.

Expected gain. Potentially improves game throughput even when audio itself is on time, if guest accesses block behind audio work. If there is no meaningful contention, splitting ownership adds complexity without a demonstrated benefit.

Acceptance. Include simultaneous guest control writes, pause, reset, save/load, shutdown, blocked voices, and IRQ publication. Compare externally visible ordering, not just total lock time.

First patch boundary

Do not remove a lock until its protected state and publication boundary are listed. RAM-backed guest controls require a separate observation contract.

lock -> capture owned work -> eligible computation -> validated publication; lifecycle still drains owners

Locate the inspected seam before editing; names or ownership may have changed since the pinned review:

git grep -n -E 'mcpx_apu_frame_thread|wait_for_idle|gp_write|ep_write|bql_lock' -- hw/xbox/mcpx/apu

Proposed focused tests

These are implementation gates to add or exercise, not claims that production tests already exist or passed. Retained standalone checks are on the checks page.

Test ID	Setup / deliberate control	Required oracle
A05.01	Delay a worker while the guest changes relevant controls and RAM-backed voice state.	A defined old/new observation boundary is retained; no mixed-state frame is published.
A05.02	Pause, reset, save/load and shutdown at capture, compute and publication boundaries.	Owners drain without deadlock or use-after-free; no stale result survives a generation change.
A05.03	Run a workload with no meaningful lock contention.	The redesign must not be reported as useful solely because hold time falls; account for its added scheduling cost.

Counters and rejection criteria

Collect: apu_lock_hold_ns, apu_lock_wait_ns, vcpu_blocked_ns, bql_wait_ns, frame_cpu_ns, publish_retries. Keep exact counts separate from sampled durations; use an uninstrumented build for performance qualification.

Reject or hold: Reject ordering/lifecycle defects and lock inversion. Reduced hold time is insufficient without reduced critical-path blocking or a justified latency benefit.

Follow the common protocol for source identities, previous-main/fixed-baseline controls, raw results, confidence and retail/XISO qualification. No gain becomes proven from a model, cache hit, local operation count, or shifted wait label alone.