Re: [virtio-comment] virtio-sound linux driver conformance to spec

[Stefan Hajnoczi <stefanha@redhat.com>]

On Mon, Sep 18, 2023 at 02:50:09PM +0200, Matias Ezequiel Vara Larsen wrote:
> On Wed, Sep 13, 2023 at 06:58:30PM +0300, Manos Pitsidianakis wrote:
> > Hello Matias,
> > 
> > Please show and refer to code snippets from the kernel tree that you
> > think are related to your question. It'd help us make sure we all talk
> > about the same thing.
> > 
> 
> In this discussion, I am referring to the way in which the virtio-sound
> driver is manipulating buffers that have been consumed by the device,
> e.g., used-ring in the tx queue. My understanding is the driver builds a
> ring-buffer that is shared with the user application in the guest. As
> soon as the device returns a buffer to the used ring, the driver puts
> the request in the available ring again. This is my understanding from
> sound/virtio/virtio_pcm_msg.c#L324. The user application updates the
> content of the buffer at sound/virtio/virtio_pcm_msg.c#L322, but this
> task is deferred by using schedule_work(). The update of the buffer may
> happen once the buffers are already in the available ring.

The driver cannot rely on the device accessing the buffer via shared
memory at a specific time. The device may process the buffer as soon as
the driver marks the buffer available and/or the buffer may not be in
shared memory (there is a discussion about virtio over TCP).

I haven't looked at the code myself, but based on your interpretation it
seems the driver is buggy. Buffers should only be submitted when the
buffer contents are no longer subject to change.

Stefan

Attachment: signature.asc
Description: PGP signature