[PATCH v8 00/14] ALSA: virtio: staged capture recovery and PCM RESET synchronization

[Joonho Lee <mynameisjune111@gmail.com>]

Hi Takashi,

This is a local draft of the next complete revision of the staged capture
series, based on sound.git for-next at
a4311e9447bbb219044db38897f95be112f46a8a.
It supersedes the submitted v7 series and includes all of its unmerged
prerequisites. Please apply this series directly to the base, rather than
on top of v7. Targeting 7.5 or later still works for me.

I consolidated the staged capture implementation and its follow-up fixes
into patch 9. The request-lifetime and ACK changes remain separate, as do
the notification priority change and the three RESET changes at the end.
The capture compatibility options remain opt-in and disabled by default.

Series layout

  1-6: ACK errors, START recovery and request/DMA lifetime.
  7:   Mark core stop-threshold accesses used by capture policy sampling.
  8:   Send STOP and synchronize teardown when leaving PAUSED.
  9:   Staged capture, dsnoop policy and lifecycle recovery.
  10:  Staged capture period-work priority.
  11:  Capture compatibility option documentation.
  12:  Optional PCM reset operation under the stream lock.
  13:  Staged capture RESET accounting.
  14:  Ordinary indirect capture RESET accounting.

Patch 8 extends the earlier paused-stop change to invoke the driver's
STOP trigger. Marking stop_operating alone left the device paused while
subsequent teardown expected it to have stopped. This is a core behavior
change affecting drivers beyond virtio-snd.

Patch 12 retains the common pointer update, time accounting and XRUN path
in snd_pcm_lib_reset(). The optional operation runs with the PCM stream
lock held through core position and appl_ptr completion. Drivers without
it keep their existing ioctl RESET path. The same operation runs after a
successful prepare.

A successful callback member completes its reset before its lock is
released. If a later linked member fails, the first error is returned;
there is no group rollback. Earlier members can already be reset, and a
failing callback may have changed state. Mixed legacy/callback groups
retain the legacy members' existing post_action policy. Applications must
recover the group before relying on its positions after an error.

Patch 13 preserves RX completions arriving after the common pointer
observation. A refill failure finishes the core rebase and then reports
XRUN through period work. Patch 14 fixes ordinary capture accounting after
RESET, including MMAP capture. It discards the requested unread samples
while preserving the device's ring offsets. A refill failure returns an
error and stops transfers, requiring drop/prepare or reopen recovery.

Validation

The full ARM64 Image and modules were built from the new base with KASAN,
lockdep and W=1. Core and virtio-snd objects also built at every one of the
14 intermediate stages. ARM32 LLVM core/virtio-snd object builds passed;
ARM32 was not booted.

The new-base QEMU runs covered normal and staged capture, playback, policy
changes, linked RESET/prepare partial failures, delayed control replies,
failed prepare, RELEASE retry, suspend and virtqueue reset recovery.
The linked synthetic fixtures cover atomic and nonatomic streams with
all callback combinations, including errors after pointer changes and
later-member prepare failure.

MMAP_INTERLEAVED capture was checked at 48 kHz, mono S16_LE with both
RUNNING and PAUSED RESET, managed and free-running stop thresholds, XRUN
recovery and reopen. Seven VM runs produced 21 capture segments and
8,016,000 frames matching the deterministic sample oracle, including two
70-second one-vCPU recordings. Fault hooks are confined to separate test
builds.

The two earlier TCG failures were followed by 22 comparison runs using
the previous and current kernel bases. Both used two vCPUs, 512 MiB, the
same QEMU and rootfs, four dsnoop clients at 16, 44.1, 48 and 96 kHz,
and a 48 kHz mono slave with a 160 ms buffer. Kernel configurations
differed only in LOCALVERSION. The main and initialization kernel text
ranges and the executable/text-relocation sections of virtio_snd, snd-
pcm and snd were identical.

In alternating 70-second TCG runs with two CPU busy loops, the previous
base failed three of four runs and the current base failed all four.
Lowering only the busy loops to nice 19 still failed both runs on each
base. Host load varied substantially and was not controlled. These
counts alone do not establish a performance regression.

The diagnostics distinguish two paths. A client can exceed its dsnoop
stop_threshold and receive -EPIPE while the hardware keeps running. With
more severe delay, the driver rejects completion when capture progress
since the last PCM pointer observation reaches a full ring
(pointer_window). dsnoop can recover the slave before reporting the
error to a client, so a later RUNNING state does not rule out a
preceding driver XRUN.

An instrumented 70-second TCG run on the previous base hit
client_threshold at 7680 or 8640 unread frames against a 7680-frame
limit. The current base completed all four rates in the corresponding
run, totaling 14,287,000 frames. In HVF controls both bases completed 20
seconds. Delaying only the 96 kHz reader by 240 ms produced
client_threshold XRUN on both bases while the other three readers
completed their requested frames.

These results support delayed consumption and pointer observation under
CPU contention as the observed failure conditions. They provide no
evidence of an executable-code performance regression in this
configuration, but do not establish identical performance under all host
loads. The original two failures had no branch-level instrumentation;
their exact return sites cannot be established retrospectively. All
failed runs are retained. The pointer-window protection and buffer sizes
were left unchanged.

All 22 runs completed input-integrity and module-hash checks without
KASAN or lockdep diagnostics. Four runs separately recorded
pointer_window warnings. The instrumented and uninstrumented fixtures
are reported separately because instrumentation can affect timing. This
is not a lossless-capture guarantee for overloaded TCG guests.

Scope and remaining review

This revision has only been run in QEMU. VZ/MOTU acceptance is still
pending. Other MMAP layouts, sample formats, multichannel capture and
concurrent RESET between mmap_begin and mmap_commit were not covered.
The new callback's linked partial-failure contract and the general
paused-STOP behavior need ALSA core maintainer review. NOMMU and 32-bit
runtime behavior are not established by the ARM64 tests.

The public Sashiko review criteria were used for a local audit. This
revision has not been reviewed by the Sashiko service. Physical-device
acceptance and ALSA core review remain outstanding.

Thanks,
Joonho

base-commit: a4311e9447bbb219044db38897f95be112f46a8a