[PATCH v9 00/14] ALSA: virtio: staged capture recovery and PCM RESET synchronization
flat view
HOTtoday
From: Joonho Lee <hidden>
Date: 2026-10-29 08:50:39
Also in:
linux-doc, linux-sound, lkml
Subsystem:
documentation, sound, the rest, virtio sound driver · Maintainers:
Jonathan Corbet, Jaroslav Kysela, Takashi Iwai, Linus Torvalds, Anton Yakovlev, "Michael S. Tsirkin"
Revision v9 (2 revisions archived).
Revisions (2)
- v8
- v9 current [diff against previous]
Hi Takashi, This revision supersedes v8 and includes its unmerged prerequisites. It applies directly to sound.git for-next at a4311e9447bbb219044db38897f95be112f46a8a. Please apply it to that base. Targeting 7.5 or later still works for me. Previous revision: https://lore.kernel.org/all/20261029054354.2931-1-mynameisjune111@gmail.com/T/ (local) The series adds staged capture accounting for shared capture users such as dsnoop, with lifecycle recovery and synchronized RESET accounting. The capture compatibility options remain opt-in and disabled by default. Changes since v8 I removed the generic PAUSED-to-STOP change. Existing ALSA drivers retain the upstream STOP condition; virtio-snd now tracks its device running state and RELEASE obligation independently from runtime readiness. A successful RELEASE clears that obligation before the RX wait, allowing a wait timeout to resume cleanup without sending RELEASE twice. A known STOP rejection can be retried before RELEASE. An uncertain control result requires device reset before the transition can be trusted again. The control requests keep their originating PCM epoch through enqueue, where the queue and PCM locks protect the final generation check. Period geometry and message ranges are checked before transfer construction. The aligned control response allocation now appears in patch 5, where INTEGER64 values first need it. Patch 8 adds snd_pcm_progress_under_stream_lock() as a separate ALSA core change. Partial capture progress needs a reader wakeup before a complete period is available. A delayed notification through the period-interrupt path can infer a false wrap. The helper uses the ordinary pointer update and reader/fasync notification without ticking the PCM timer. The caller holds the stream lock and releases driver pointer and trigger locks. Synthetic tests in both locking modes reproduced the missing-wakeup and false-wrap alternatives and passed with the helper. Its API shape still needs ALSA maintainer review. The staged RESET path reclaims RX space at the common pointer observation and updates its notified-period position there. Completions arriving after that observation remain available. Ordinary capture also completes the core rebase after a late refill failure, including paused streams. Layout and dependencies 1-6: ACK errors, START/RELEASE recovery and request/DMA lifetime. Patch 2 tracks RELEASE completion; patch 4 checks period ranges. 7: Mark core stop-threshold accesses used by capture policy sampling. 8: ALSA partial-progress notification under the stream lock. 9: Staged capture, dsnoop policy and lifecycle recovery; uses 1-8. 10: Staged capture period-work priority; uses 9. 11: Capture compatibility option documentation. 12: Optional PCM reset operation under the stream lock. 13: Staged capture RESET accounting; uses 9 and 12. 14: Ordinary indirect capture RESET accounting; follows 12-13. The RELEASE completion bookkeeping is included from patch 2 onward. Whole-byte period geometry and message bounds checks are included from patch 4 onward, so these fixes also cover partial application. The previous v8 patch 8 is dropped and replaced by the new helper patch. The RESET core interface, staged application and ordinary capture fix remain separate. The ACK and work-priority changes remain separate too. RESET error policy The optional callback runs with the member's stream lock held and retains the common pointer and time handling through snd_pcm_lib_reset(). Zero allows the core to finish the position and appl_ptr rebase before unlock. It does not guarantee recovery from XRUN. A negative result skips core completion, so the callback must leave coherent pointers after any partial work. Drivers without the callback retain their existing path. The callback also runs after a successful prepare. After virtio-snd has performed the common pointer mutation, a late refill failure latches XRUN and permits core completion. RESET returns zero. With the notification worker delayed, a nonblocking read can first return -EAGAIN and later -EPIPE; a paused stream's resume can return -EPIPE. Applications need prepare or reopen recovery. This changes the observable late-failure behavior from v8's immediate refill error, which could leave the rebase incomplete. No new userspace ioctl or structure is introduced. The internal snd_pcm_ops addition requires out-of-tree modules to rebuild. Linked RESET and prepare stop on the first error without rollback. Earlier callback members may already have completed; mixed legacy members retain their existing post_action policy. An error does not imply the group is unchanged. Applications must recover the group before relying on its positions. The callback contract makes this partial failure clear. Validation and remaining limits The candidate's runtime code was built as an ARM64 Image and modules with W=1, KASAN and lockdep. ARM32 LLVM object builds also passed. The final API-contract refinement only changes comments. Packaging checks apply every patch in order and compare the result with the validated candidate. The QEMU regressions cover native and restart lifecycle handling, rejected STOP and PAUSE, successful RELEASE followed by an RX wait timeout, stale reset epochs, failed prepare, suspend, delayed replies and virtqueue reset. The fault matrix passed 14 cases. The linked RESET/prepare fixtures passed 40 cases across atomic and nonatomic locking. Four delayed-worker cases covered RUNNING/PAUSED and managed/free-running capture, then recovery and reopen. The partial-progress alternatives were compared in both locking modes. KASAN and lockdep reported no diagnostics in these targeted runs. A forced 90 ms interval after the RESET pointer observation reproduced -EPIPE with the earlier staged accounting. The corrected path matched 48,000 subsequent deterministic frames and passed reopen. Deterministic ordinary MMAP capture and a 70-second recording also passed. These tests use synthetic sources; they do not establish physical-device acceptance. The reordered prerequisites were also boot-tested independently. An injected RX wait failure after successful RELEASE reproduced two RELEASE attempts with the earlier patch-2 stage. Each corrected stage from 2 through 8 made one attempt and passed prepare, capture and reopen. Stages 4 through 8 passed eight direct message-boundary checks. An additional stage-4 run rejected three malformed hw_params cases before any SET_PARAMS request, including a fractional-byte period. These nine QEMU runs passed their expected outcomes with no KASAN or lockdep reports. Fault hooks are isolated from the submitted patches. The malformed-format case tests validation logic and does not claim ADPCM hardware support. High-load TCG capture still fails. In an alternating A-B-B-A comparison using submitted v8 and this candidate with the same guest configuration, two vCPUs, two busy loops and four dsnoop clients, both versions failed both 70-second runs. Reopen passed once in two v8 runs and zero times in two candidate runs. Observed reader gaps reached 165-283 ms against 160 ms client buffers. All failures remain in the test evidence. In separate instrumented 20-second runs, both versions failed. All four candidate errors reached dsnoop's client_threshold check. The v8 run also reached direct_check, where a later RUNNING snapshot cannot exclude an earlier slave XRUN. Host scheduling and load varied between runs. This comparison does not establish performance equivalence or rule out a performance regression. Buffers, priorities and expected outcomes were not changed to turn these failures into passes. The work-priority patch provides no hard real-time guarantee. This revision has no VZ/MOTU physical-input acceptance yet. ADPCM hardware negotiation, other MMAP layouts and formats, multichannel capture, ARM32 runtime and all physical ALSA drivers remain outside these tests. The partial-progress API and linked RESET contract still need maintainer review. The current revision has not received a Sashiko service review. Thanks, Joonho base-commit: a4311e9447bbb219044db38897f95be112f46a8a