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

[Alex Williamson <alex.williamson@redhat.com>]

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,

Alex