From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v4 0/9] KVM: Improve IRQ assignment for device passthrough Date: Wed, 17 Nov 2010 10:25:32 +0200 Message-ID: <4CE3917C.6090703@redhat.com> References: <20101116165506.GA20186@amt.cnet> <4CE2CCC3.2040502@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm , Alex Williamson , "Michael S. Tsirkin" To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:62360 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933102Ab0KQIZj (ORCPT ); Wed, 17 Nov 2010 03:25:39 -0500 In-Reply-To: <4CE2CCC3.2040502@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/16/2010 08:26 PM, Jan Kiszka wrote: > Am 16.11.2010 17:55, Marcelo Tosatti wrote: > > On Mon, Nov 08, 2010 at 12:21:44PM +0100, Jan Kiszka wrote: > >> Nine patches (yeah, it's getting more and more) to improve "classic" > >> device assigment /wrt IRQs. Highlight is the last one that resolves the > >> host IRQ sharing issue for all PCI 2.3 devices. Quite essential when > >> passing non-MSI-ready devices like many USB host controllers. > >> > >> As there were concerns regarding the overhead of IRQ masking via the PCI > >> config space, I did some micro-benchmarks. Well, the concerns are valid: > >> > >> disable_irq_nosync: ~600 cycles > >> pci_2_3_irq_check_and_mask: ~6000 cycles (EHCI) > >> ~22000 cycles (AR9287, with peaks>100000) > >> > >> Specifically the varying impact of the device like in the Atheros case > >> is worrying (this device is actually known to cause horrible latencies > >> to the host, but who knows what other devices do). So I decided to go > >> with PCI-2.3 masking as default off in the to-be-sent qemu-kvm patch. > >> Maybe something to consider vor VFIO as well. > > > > Looks fine to me. Michael, Alex? > > > > Also needs a rebase. > > I think Avi wanted to explore possibilities to avoid host_pci_2_3=on|off > by switching between both modes on demand. I've some ideas, but still > need to look into design details. Given that this would have impact on > the ABI, I guess we better wait with merging 9/9. Indeed. > Moreover, Avi preferred to skip the srcu conversion and run with a > simply lock across kvm_set_irq (just like we do now). Yes. It was predicated on agreeing that deferring broadcast/multicast IPIs to a workqueue is possible. -- error compiling committee.c: too many arguments to function