From: Anton Yakovlev <anton.yakovlev@opensynergy.com>
To: Stefan Hajnoczi <stefanha@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>,
virtualization@lists.linux-foundation.org,
virtio-comment@lists.oasis-open.org, mst@redhat.com,
jasowang@redhat.com
Subject: Re: [virtio-comment] Re: virtio-sound linux driver conformance to spec
Date: Mon, 25 Sep 2023 09:37:01 +0900 [thread overview]
Message-ID: <e7e1eb3c-cbc2-4b2c-aecc-dde1a71cbcc4@opensynergy.com> (raw)
In-Reply-To: <20230919151041.GA1515067@fedora>
Hello Stefan,
On 20.09.2023 00:10, Stefan Hajnoczi wrote:
>> As an aside, here are two other statements that have a similar issue:
>>
>> - 2.6.1.1.2 "the driver MAY release any resource associated with that
>> virtqueue" (instead 2.6.1.1.1 should have something like "After a queue has
>> been reset by the driver, the device MUST NOT access any resource associated
>> with a virtqueue").
>>
>> - 2.7.5.1 "[the device] MAY do so for debugging or diagnostic purposes"
>> (this is not normative and can be just "may")
>
> The spec should not make an exception for virtio-sound because the
> virtqueue model was not intended as a shared memory mechanism. Allowing
> it would prevent message-passing implementations of virtqueues.
>
> Instead the device should use Shared Memory Regions:
> https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html#x1-10200010
>
> BTW, the virtio-sound spec already has VIRTIO_SND_PCM_F_SHMEM_HOST and
> VIRTIO_SND_PCM_F_SHMEM_GUEST bits reserved but they currently have no
> meaning. I wonder what that was intended for?
In the original version of the design it was proposed to use shared memory for
the buffer. But since not all architectures allow the use of shared memory, it
was decided to make message-passing the basis. For shared memory, stream
features were reserved for further work on the spec.
--
Anton Yakovlev
Senior Software Engineer
OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin
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/
next prev parent reply other threads:[~2023-09-25 0:37 UTC|newest]
Thread overview: 19+ 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:50 ` Paolo Bonzini
2023-09-13 15:58 ` Manos Pitsidianakis
2023-09-18 12:50 ` Matias Ezequiel Vara Larsen
2023-09-18 18:20 ` Stefan Hajnoczi
2023-09-18 11:13 ` 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 6:58 ` Paolo Bonzini
2023-09-19 15:10 ` Stefan Hajnoczi
2023-09-25 0:37 ` Anton Yakovlev [this message]
2023-09-25 0:24 ` Anton Yakovlev
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
2023-09-25 14:33 ` Matias Ezequiel Vara Larsen
2023-09-25 0:55 ` Anton Yakovlev
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=e7e1eb3c-cbc2-4b2c-aecc-dde1a71cbcc4@opensynergy.com \
--to=anton.yakovlev@opensynergy.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=mvaralar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox