Re: [Qemu-devel] [RFC v3 10/10] vfio: Add irqfd support in platform device

[Alexander Graf <agraf@suse.de>]

On 25.06.14 23:54, Alex Williamson wrote:
> On Wed, 2014-06-25 at 23:35 +0200, Alexander Graf wrote:
>> On 02.06.14 09:49, Eric Auger wrote:
>>> This patch aims at optimizing IRQ handling using irqfd framework.
>>> It brings significant performance improvement over "traditional" IRQ
>>> handling introduced in :
>>> "vfio: Add initial IRQ support in platform device".
>>>
>>> This new IRQ handling method depends on kernel KVM irqfd/GSI routing
>>> capability.
>>>
>>> The IRQ handling method can be dynamically chosen (default is irqfd,
>>> if kernel supports it obviously).  For example to disable irqfd
>>> handling, use:
>>>
>>> -device vfio-platform,vfio_device="fff51000.ethernet",\
>>> compat="calxeda/hb-xgmac",mmap-timeout-ms=110,irqfd=false\
>>>
>>> Performances are improved for the following reasons:
>>> - eventfds signalled by the VFIO platform driver are handled on
>>>     kernel side by the KVM irqfd framework.
>>> - the end of interrupt(EOI) is trapped at GIC level and not at MMIO
>>>     region level. As a reminder, in traditional IRQ handling QEMU
>>>     assumed the first guest access to a device MMIO region after IRQ
>>>     hit was the IRQ status register reset. This trap was approximate
>>>     and obliged to swap to slow path after IRQ hit. A mmap timer
>>>     mechanism enabled to swap back to fast path after the mmap period
>>>     introducing extra complexity. Now GIC detects the completion of
>>>     the virtual IRQ and signals a resampler eventfd on maintenance
>>>     IRQ. The corresponding handler re-enables the physical IRQ.
>> Ah, so if you're using irqfd you do unmask the interrupt on EOI. Why not
>> without irqfd? And if the answer is "because it's too difficult" - why
>> support VFIO without irqfd at all then?
> Yes, it's too difficult, or at least it doesn't have sufficient ROI to
> try to plumb it through QEMU.  What the hack in patch 5 enables is IRQ
> support that doesn't rely on a KVM irqchip.  By not supporting it, we
> drop any hope of running tcg targets.  I'll admit that a tcg target with
> an assigned device is mostly an unsupportable toy, but it's potentially
> useful for development and things like driver or even hardware
> debugging.  IMHO, the EOI on device access is a nice, self contained
> solution, even if it ends up being rather sloppy with interrupts.
> Thanks,

Yeah, I didn't realize that this is the same mechanism we use for PCI. 
You convinced me :).


Alex