From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzvHV-0004Cx-AL for qemu-devel@nongnu.org; Wed, 25 Jun 2014 18:03:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzvHN-0001TF-Kz for qemu-devel@nongnu.org; Wed, 25 Jun 2014 18:03:05 -0400 Received: from cantor2.suse.de ([195.135.220.15]:57505 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzvHN-0001T4-Da for qemu-devel@nongnu.org; Wed, 25 Jun 2014 18:02:57 -0400 Message-ID: <53AB470E.3000606@suse.de> Date: Thu, 26 Jun 2014 00:02:54 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1401695374-4287-1-git-send-email-eric.auger@linaro.org> <1401695374-4287-11-git-send-email-eric.auger@linaro.org> <53AB4094.20201@suse.de> <1403733241.31091.56.camel@ul30vt.home> In-Reply-To: <1403733241.31091.56.camel@ul30vt.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v3 10/10] vfio: Add irqfd support in platform device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: peter.maydell@linaro.org, kim.phillips@freescale.com, eric.auger@st.com, Eric Auger , patches@linaro.org, a.rigo@virtualopensystems.com, qemu-devel@nongnu.org, stuart.yoder@freescale.com, christophe.barnichon@st.com, a.motakis@virtualopensystems.com, kvmarm@lists.cs.columbia.edu, christoffer.dall@linaro.org 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