From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SW6zq-00044x-ML for qemu-devel@nongnu.org; Sun, 20 May 2012 10:20:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SW6zp-0000Co-0g for qemu-devel@nongnu.org; Sun, 20 May 2012 10:20:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33182) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SW6zo-0000Cg-Oo for qemu-devel@nongnu.org; Sun, 20 May 2012 10:20:32 -0400 Message-ID: <4FB8FDA6.3070001@redhat.com> Date: Sun, 20 May 2012 17:20:22 +0300 From: Avi Kivity MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH v2 00/11] uq/master: irqfd-based interrupt injection for virtio/vhost List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Marcelo Tosatti , qemu-devel , kvm@vger.kernel.org, "Michael S. Tsirkin" On 05/17/2012 04:32 PM, Jan Kiszka wrote: > [ changes in v2: rebase over uq/master ] > > This series is another major milestone of merging qemu-kvm into > upstream. It implements the required interfaces and logic to directly > inject MSI-X interrupts generated by the vhost-net kernel module into > the KVM in-kernel irqchip. This involves > - establishing MSI vector notifiers, so far triggered on relevant MSI-X > configuration changes of subscribed PCI devices > - support for static vIRQ-to-MSI routes > - an API for linking an IRQFD with such a vIRQ > - the usage of these services in virtio-pci to enable direct injection > > The series also contains some smaller refactorings of the KVM IRQ > routing API such as automatic committing of route changes. It applies on > top of the KVM MSI support series [1] posted recently. The complete > stack is available at > > git://git.kiszka.org/qemu-kvm.git queues/kvm-msi-irqfd > > If the proposes API is acceptable, I will also provide some morphing > patches for qemu-kvm to make the merge of both trees smoother. > > After this series, to only reasons to still use qemu-kvm for production > purposes will be PCI device assignment and potential dependencies on > legacy command line switches as well as vmstate formats (when requiring > backward migration support). However, the majority of users should be > able to switch to upstream QEMU seamlessly and finally receive the same > level of performance on x86. > > Thanks, applied. -- error compiling committee.c: too many arguments to function