Re: [Qemu-devel] [PATCH] virtio: Implement userspace forwarding for host notifiers

[Pavel Fedin <p.fedin@samsung.com>]

 Hello!

> If I read this correctly, memory regions already keep track of
> ioeventfds and this patch can simply trigger them manually if that had
> not already been done?

 Yes, exactly, and this is the new idea.

> Only that we don't have such a nice tracking structure that memory
> regions already have.
> 
> The intercept handler for diagnose 500 already ends up at the correct
> device (its id is one of the parameters), so I'd need to check for an
> existing notifier on the virtqueue and trigger that instead of calling
> virtio_queue_notify directly?

 Yes, absolutely correct, but only if the notifier has actually been installed. Pure userspace virtio will not do it, AFAIK, if we
don't have KVM_CAP_IOEVENTFD. Take a careful look at virtio-mmio.c, you'll see that host notifiers are actually installed from two
places:
1. virtio_mmio_start_ioeventfd()
2. virtio_mmio_set_host_notifier()

 Userspace implementation of virtio uses (1) path, while vhost uses (2). Note also that (1) does not do anything at all if KVM does
not support ioeventfds. So, (1) case breaks up into two:
 1a. userspace virtio, notifications triggered by handling MMIO writes in userspace
 1b. userspace virtio, notifications triggered by ioeventfds, which are bound to MMIO in kernel
 I don't know why we have (1b) at all, because i'm in doubt there would be any noticeable performance advantage. But, i believe,
there was some reason to implement it.

 Both (1) and (2) end up in the same internal routine, and the only difference is 'bool set_handler', which is set to false for
vhost. This is what i rely on, and this is what you should detect too.

 PCI backend is a little bit more complicated to read, but it works absolutely in the same way.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia