[RFC PATCH v2 0/1] ALSA: virtio: stage capture for VZ backends

[Joonho Lee <mynameisjune111@gmail.com>]

Hi,

This updates the VZ capture RFC with an explicit public base and its
prerequisite series. The implementation is unchanged from v1. The core
prerequisite is now the capture-drain RFC v3, including the notify=false
pointer update discussed with Takashi.

The patch adds request-owned capture staging, validates completion sizes,
and accounts for captured data independently of fixed-size requests. It
also adds an opt-in pause/restart path using RELEASE and reprepare.

The five module parameters default to off: capture_staging,
capture_packed_status, capture_allow_short, capture_allow_empty, and
capture_pause_restart. Enabling the profile is still an explicit choice.
Automatic VZ detection, a negotiated feature and Docker Desktop host-audio
routing are outside this patch.

Please apply the following on base 8d70e364e866, in this order:

1. The five virtio-snd lifetime/error-recovery v3 patches:
   https://lore.kernel.org/all/cover.1791881787.git.mynameisjune111@gmail.com/
2. The generic teardown wait RFC v2:
   https://lore.kernel.org/all/rfc-v2-generic-control-wait-0.2eddd58a796e497f@gmail.com/
3. Both core capture-drain RFC v3 patches:
   https://lore.kernel.org/all/rfc-v3-core-capture-drain-0.cf2e307fcac34b6a@gmail.com/
4. This VZ patch.

The trailers below identify all eight prerequisites in application order.
The three prerequisite-message-id hints identify the public Lore threads
containing them. I fetched those threads, checked every stable patch ID,
and applied the stack from the declared base. The resulting nine changed
source files match the kernel and modules used for the tests below.
Use core v3 in place of core v2; the two revisions must not be stacked.

Core v3 refreshes capture pointers inside the drain action and suppresses
nested stop actions during that update. Its proposed error policy ends a
failing capture member in SETUP while allowing a healthy linked member to
retain its tail in DRAINING. A blocking capture-only drain returns 0 if
the action otherwise succeeds. Whether it should instead report EPIPE
after stopping all members remains a question in the core discussion:
https://lore.kernel.org/all/core-drain-linked-lock-reply.cf2e307fcac34b6a@gmail.com/
This generic core behavior also applies with the VZ parameters disabled.

Validation with the complete stack above:

- Rebuilt the ARM64 Image and modules with W=1, KASAN, lockdep and
  atomic-sleep debugging. There were no build errors or sound warnings;
  the base emitted 517 -Woverride-init warnings outside sound/.
- Passed 10 QEMU scenarios: short capture tails, drop, delayed
  PREPARE/START/STOP/RELEASE, pending RX after RELEASE, and held STOP and
  RELEASE requests followed by SIGKILL, timeout, reset and I/O recovery.
- Passed 24 synthetic linked capture cases across atomic and nonatomic
  locking, covering pointer faults, tail reads and reopen/recovery.
  Two additional unlinked controls also passed.
- Candidate runs produced no KASAN or lockdep diagnostics.

The QEMU tests use modified fault-injection and backend-reset fixtures.
The rebuilt stack has not been tested with a physical microphone or VZ.
Earlier AirPods results used a different kernel/module set. Input
switching, sleep/wake, freeze/restore, physical non-coherent DMA, NOMMU,
other Docker VMMs and mixed capture/playback linked groups still need
coverage. Nonblocking drain behavior has only been code-reviewed.

The existing public test package is at:
https://github.com/whatisyourname0/virtio-snd-reproducer/tree/64fa85f3260b45e7dbb85c4eee68a5b4a8b064e1/rfc/vz-capture-20261014/sashiko-followup
That snapshot contains the earlier core v2 source. The prerequisite mails
above provide the exact updated stack. The new linked capture fixture and
comparison logs are still local.

I would appreciate feedback on these points before splitting this up:

- Which observed behaviors should be fixed in Apple's backend?
- What activation mechanism would be acceptable for the compatibility
  profile? The module parameters are experimental.
- Is RELEASE/reprepare an acceptable way to implement pause for this
  backend, and what constraints should it have?
- How should capture staging and lifecycle handling be split for review?

Thanks,
Joonho

Changes in v2:
- Pin the public base, list the eight prerequisite patch IDs, and add
  Message-ID hints for the three public prerequisite series.
- Use core capture-drain v3 and report tests on that integrated stack.
- Preserve the VZ implementation and its existing human signoff.

Assisted-by: LLM

base-commit: 8d70e364e866bdfca81eee24d0688fac9472cfb9
prerequisite-patch-id: 39fb327a004c966ab90f66a34a64bbdbb3ffb475
prerequisite-patch-id: 7c6bc344656fd839ae0d697ba18d66ac0b47827a
prerequisite-patch-id: 9dd290ac3147fa7b49a475d7df8a6172778f2860
prerequisite-patch-id: f4c24a5e441343a690f4ac2437f181c815bc23d0
prerequisite-patch-id: ab4a5b770247a65272ab7af18a75a147daf81287
prerequisite-patch-id: cfe3e7000e695a2fda27993f4d9acf0a637cf24e
prerequisite-patch-id: 0fc5fec2c6ac5d3043cf2210570472ed4ce32952
prerequisite-patch-id: fa5c13a4c698a82bdce335a34c22e66bf72960d8
prerequisite-message-id: cover.1791881787.git.mynameisjune111@gmail.com
prerequisite-message-id: rfc-v2-generic-control-wait-0.2eddd58a796e497f@gmail.com
prerequisite-message-id: rfc-v3-core-capture-drain-0.cf2e307fcac34b6a@gmail.com