All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
To: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	virtualization@lists.linux-foundation.org,
	virtio-comment@lists.oasis-open.org,
	anton.yakovlev@opensynergy.com, stefanha@redhat.com,
	mst@redhat.com, jasowang@redhat.com
Subject: Re: [virtio-comment] virtio-sound linux driver conformance to spec
Date: Mon, 18 Sep 2023 14:50:09 +0200	[thread overview]
Message-ID: <ZQhHgTxoUAnfYaiC@fedora> (raw)
In-Reply-To: <CAAjaMXbjRn27fpZHK982m4MyJGXWQTR99WHPAZQfcun+pe3GBw@mail.gmail.com>

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.


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


WARNING: multiple messages have this Message-ID (diff)
From: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
To: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Cc: mst@redhat.com, virtualization@lists.linux-foundation.org,
	stefanha@redhat.com, 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:50:09 +0200	[thread overview]
Message-ID: <ZQhHgTxoUAnfYaiC@fedora> (raw)
In-Reply-To: <CAAjaMXbjRn27fpZHK982m4MyJGXWQTR99WHPAZQfcun+pe3GBw@mail.gmail.com>

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.

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

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

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-13 15:04 [virtio-comment] virtio-sound linux driver conformance to spec Matias Ezequiel Vara Larsen
2023-09-13 15:04 ` Matias Ezequiel Vara Larsen
2023-09-13 15:50 ` [virtio-comment] " Paolo Bonzini
2023-09-13 15:50   ` Paolo Bonzini
2023-09-13 15:58   ` Manos Pitsidianakis
2023-09-18 12:50     ` Matias Ezequiel Vara Larsen [this message]
2023-09-18 12:50       ` Matias Ezequiel Vara Larsen
2023-09-18 18:20       ` Stefan Hajnoczi
2023-09-18 18:20         ` Stefan Hajnoczi
2023-09-18 11:13   ` Matias Ezequiel Vara Larsen
2023-09-18 11:13     ` Matias Ezequiel Vara Larsen
2023-09-18 11:26     ` Matias Ezequiel Vara Larsen
2023-09-18 11:26       ` Matias Ezequiel Vara Larsen
2023-09-19  0:35 ` [virtio-comment] " Anton Yakovlev
2023-09-19  0:35   ` Anton Yakovlev via Virtualization
2023-09-19  6:58   ` [virtio-comment] " Paolo Bonzini
2023-09-19  6:58     ` Paolo Bonzini
2023-09-19 15:10     ` Stefan Hajnoczi
2023-09-19 15:10       ` Stefan Hajnoczi
2023-09-25  0:37       ` Anton Yakovlev
2023-09-25  0:37         ` Anton Yakovlev via Virtualization
2023-09-25  0:24     ` Anton Yakovlev
2023-09-25  0:24       ` Anton Yakovlev via Virtualization
2023-09-19  9:43 ` Michael S. Tsirkin
2023-09-19  9:43   ` Michael S. Tsirkin
2023-09-19 14:18   ` [virtio-comment] " Matias Ezequiel Vara Larsen
2023-09-19 14:18     ` Matias Ezequiel Vara Larsen
2023-09-19 15:52     ` [virtio-comment] " Michael S. Tsirkin
2023-09-19 15:52       ` Michael S. Tsirkin
2023-09-20 13:18       ` [virtio-comment] " Matias Ezequiel Vara Larsen
2023-09-20 13:18         ` Matias Ezequiel Vara Larsen
2023-09-25  1:04         ` [virtio-comment] " Anton Yakovlev
2023-09-25  1:04           ` Anton Yakovlev via Virtualization
2023-09-25 14:33           ` [virtio-comment] " Matias Ezequiel Vara Larsen
2023-09-25 14:33             ` Matias Ezequiel Vara Larsen
2023-09-25  0:55       ` [virtio-comment] " Anton Yakovlev
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=ZQhHgTxoUAnfYaiC@fedora \
    --to=mvaralar@redhat.com \
    --cc=anton.yakovlev@opensynergy.com \
    --cc=jasowang@redhat.com \
    --cc=manos.pitsidianakis@linaro.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=stefanha@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.