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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Hello Stefan,

On 20.09.2023 00:10, Stefan Hajnoczi wrote:

As an aside, here are two other statements that have a similar issue:

- "the driver MAY release any resource associated with that
virtqueue" (instead should have something like "After a queue has
been reset by the driver, the device MUST NOT access any resource associated
with a virtqueue").

- "[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:

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
Virtualization mailing list

[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux