Re: [virtio-dev] virtio-snd spec question

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Feb 02, 2022 at 10:43:38AM -0800, Roman Kiryanov wrote:
> Sure. This is how I expect the device side ctl listening loop should look like:
> 
> while (...) {
>     request = virtqueue_pop(ctl_vq, ...);  //1
>         response = virtqueue_pop(ctl_vq, ...);  //2
>         virtqueue_push(ctl_vq, response, response_size):  //3
>     virtqueue_push(ctl_vq, request, 0):  //4
> }
> 
> My understanding is that line 1 could read output from line 3 if the kernel is
> not fast enough fetching the response.

Is this code from qemu then? In that case I don't see how. virtqueue_pop gets
an available buffer. virtqueue_push adds a used buffer, not an available
one. I think it's just the API that's confusing.

> On Tue, Feb 1, 2022 at 11:44 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> 
>     On Tue, Feb 01, 2022 at 03:57:10PM -0800, 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
>     >
>     > 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.
>     >
>     > Thank you.
>     >
>     > Regards,
>     > Roman.
> 
>     Could you explain a bit more? which function in the kernel driver are
>     you referring to?
> 
> 
>