virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
Cc: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>,
	mst@redhat.com, virtualization@lists.linux-foundation.org,
	virtio-comment@lists.oasis-open.org,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [virtio-comment] virtio-sound linux driver conformance to spec
Date: Mon, 18 Sep 2023 14:20:02 -0400	[thread overview]
Message-ID: <20230918182002.GA1460476@fedora> (raw)
In-Reply-To: <ZQhHgTxoUAnfYaiC@fedora>


[-- Attachment #1.1: Type: text/plain, Size: 1572 bytes --]

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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 183 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2023-09-18 18:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-13 15:04 virtio-sound linux driver conformance to spec Matias Ezequiel Vara Larsen
2023-09-13 15:50 ` [virtio-comment] " Paolo Bonzini
2023-09-18 11:13   ` Matias Ezequiel Vara Larsen
2023-09-18 11:26     ` Matias Ezequiel Vara Larsen
     [not found]   ` <CAAjaMXbjRn27fpZHK982m4MyJGXWQTR99WHPAZQfcun+pe3GBw@mail.gmail.com>
2023-09-18 12:50     ` Matias Ezequiel Vara Larsen
2023-09-18 18:20       ` Stefan Hajnoczi [this message]
2023-09-19  0:35 ` Anton Yakovlev via Virtualization
2023-09-19  6:58   ` [virtio-comment] " Paolo Bonzini
2023-09-19 15:10     ` Stefan Hajnoczi
2023-09-25  0:37       ` Anton Yakovlev via Virtualization
2023-09-25  0:24     ` Anton Yakovlev via Virtualization
2023-09-19  9:43 ` Michael S. Tsirkin
2023-09-19 14:18   ` Matias Ezequiel Vara Larsen
2023-09-19 15:52     ` Michael S. Tsirkin
2023-09-20 13:18       ` Matias Ezequiel Vara Larsen
2023-09-25  1:04         ` Anton Yakovlev via Virtualization
2023-09-25 14:33           ` Matias Ezequiel Vara Larsen
2023-09-25  0:55       ` Anton Yakovlev via Virtualization

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230918182002.GA1460476@fedora \
    --to=stefanha@redhat.com \
    --cc=manos.pitsidianakis@linaro.org \
    --cc=mst@redhat.com \
    --cc=mvaralar@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).