Thread (29 messages) 29 messages, 2 authors, 12h ago

[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)
  1. v8
  2. 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help