Hello Roman,
On 02.02.2022 00:57, Roman Kiryanov wrote:
Hello,
I work in Android Studio Emulator and I am currently implementing a
virtio-snd device. We found a spec draft here:
https://github.com/oasis-tcs/virtio-spec/commit/e73c8cdf3e822fd83c26c6de964a947670f93cc3#diff-73045e70aeaf45f93087610437b705e2d320c82a9d29b4027721f5f5f3918dc5
<https://github.com/oasis-tcs/virtio-spec/commit/e73c8cdf3e822fd83c26c6de964a947670f93cc3#diff-73045e70aeaf45f93087610437b705e2d320c82a9d29b4027721f5f5f3918dc5>
It mentions four virtqueues: ctl, event, rx and tx. It is not very clear
where a virtio-snd device should put responses to the ctl requests from
the linux kernel driver. There is a kernel driver implementation and we
have a virtio-snd device implemented in another emulator, it uses the
same virtqueue (ctl) to put ctl responses and the current kernel driver
seems happy with this.
Do you know if this is expected behavior? I am far from an expert here,
but I believe the device and the kernel will race here by reading from
the same virtqueue: the device could read VirtQueueElement produced by
itself before the kernel if the kernel is not fast enough.
Yes, this is the expected behavior of the device and you are doing
everything right.
The virtio specification describes kind of single-producer single-
consumer lockless queue way to work with virtqueues. And if both the
device and the driver (in this case, the Linux kernel) follow the
specification, then you don't have to worry about a possible race
condition.
--
Anton Yakovlev
Senior Software Engineer
OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
