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 <[email protected]> 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?
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
