[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC] vhost: fix vhost force with msix=off
From: |
Christian Borntraeger |
Subject: |
Re: [Qemu-devel] [PATCH RFC] vhost: fix vhost force with msix=off |
Date: |
Thu, 18 Apr 2013 09:55:12 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 |
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?