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

[Anton Yakovlev <anton.yakovlev@opensynergy.com>]

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