Re: [Qemu-devel] [PATCH RFC] vhost: fix vhost force with msix=off

[Christian Borntraeger]

On 17/04/13 15:42, Michael S. Tsirkin wrote:
[...]
>> +static int virtio_ccw_set_guest_notifier(VirtioCcwDevice *dev, int n,
>> +                                         bool assign, bool with_irqfd)
>> +{
>> +    VirtQueue *vq = virtio_get_queue(dev->vdev, n);
>> +    EventNotifier *notifier = virtio_queue_get_guest_notifier(vq);
>> +
>> +    if (assign) {
>> +        int r = event_notifier_init(notifier, 0);
>> +
>> +        if (r < 0) {
>> +            return r;
>> +        }
>> +        virtio_queue_set_guest_notifier_fd_handler(vq, true, with_irqfd);
>> +        /* We do not support irqfd for classic I/O interrupts, because the
>> +         * classic interrupts are intermixed with the subchannel status, 
>> that
>> +         * is queried with test subchannel. We want to use vhost, though.
>> +         * Lets make sure to have vhost running and wire up the irq fd to 
>> +         * land in qemu (and only the irq fd) in this code.
> 
> Still, this is not optimal.

Correct. This is just to make vhost work.
We still get a decent performance improvement, though. (iperf gets 2.5x faster)
So it is actually a good idea to allow vhost even if there is no kernel side irq
injection as long as we have somebody listening on the eventfd for this irq.

> Isn't there some way to actually use irqfd to bypass qemu?

We had some thoughs about having irqfd for the I/O interrupts and every idea had
its downside (e.g. putting all the channel I/O code in the kernel, having
a big qemu/kernel shared memory data structure, ...). We are still looking for
some good ideas to also provide kernel I/O interrupt injection.

> Is there some other kind of interrupt virtio can use that
> works fine with irqfd?

Yes, there is a lightweight form of I/O interrupts that is also used for the
real network cards (OSA) which does not require a TSCH we are currently also
investigating this approach.

[...]
>> So it might be an alternative to have a look at vhost code,which currently
>> requires the virtio transport to actively maintain the masking thing .
>>
>> Christian
> 
> I suggest we merge your code as is, then look for
> similiarities with PCI to move into virtio core.

Ok. Conny can you refresh the patches so that we can have a look?