From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRQqq-000667-En for qemu-devel@nongnu.org; Thu, 25 Oct 2012 13:04:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRQqp-0006az-9d for qemu-devel@nongnu.org; Thu, 25 Oct 2012 13:04:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRQqo-0006at-WC for qemu-devel@nongnu.org; Thu, 25 Oct 2012 13:04:11 -0400 Message-ID: <508970EB.7080901@redhat.com> Date: Thu, 25 Oct 2012 19:03:39 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1350897839-29593-1-git-send-email-pingfank@linux.vnet.ibm.com> <1350897839-29593-13-git-send-email-pingfank@linux.vnet.ibm.com> <50865DB9.1060106@siemens.com> <50893FD4.3080102@siemens.com> <5089679C.9000405@redhat.com> <50896BA0.9000400@siemens.com> In-Reply-To: <50896BA0.9000400@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [patch v4 12/16] e1000: apply fine lock on e1000 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Liu Ping Fan , Stefan Hajnoczi , Marcelo Tosatti , "qemu-devel@nongnu.org" , liu ping fan , Anthony Liguori , Paolo Bonzini On 10/25/2012 06:41 PM, Jan Kiszka wrote: > On 2012-10-25 18:23, Avi Kivity wrote: >> On 10/25/2012 03:34 PM, Jan Kiszka wrote: >> >>>>> Second, it clearly shows that we need to address lock-less IRQ delivery. >>>>> Almost nothing is won if we have to take the global lock again to push >>>>> an IRQ event to the guest. I'm repeating myself, but the problem to be >>>>> solved here is almost identical to fast IRQ delivery for assigned >>>>> devices (which we only address pretty ad-hoc for PCI so far). >>>>> >>>> Interesting, could you show me more detail about it, so I can google... >>> >>> No need to look that far, just grep for pci_device_route_intx_to_irq, >>> pci_device_set_intx_routing_notifier and related functions in the code. >> >> We can address it in the same way the memory core supports concurrency, >> by copying dispatch information into rcu or lock protected data structures. >> >> But I really hope we can avoid doing it now. > > I doubt so as the alternative is taking the BQL while (still) holding > the device lock. Sorry, doesn't parse. > But that creates ABBA risks. -- error compiling committee.c: too many arguments to function