Matias Ezequiel Vara Larsen
2023-Sep-18 12:50 UTC
[virtio-comment] virtio-sound linux driver conformance to spec
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. Thanks, Matias.
Stefan Hajnoczi
2023-Sep-18 18:20 UTC
[virtio-comment] virtio-sound linux driver conformance to spec
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20230918/bfc907b2/attachment.sig>