From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45583) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRQUa-0007US-L3 for qemu-devel@nongnu.org; Thu, 25 Oct 2012 12:41:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRQUZ-0007uG-LK for qemu-devel@nongnu.org; Thu, 25 Oct 2012 12:41:12 -0400 Received: from david.siemens.de ([192.35.17.14]:34016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRQUZ-0007uA-Br for qemu-devel@nongnu.org; Thu, 25 Oct 2012 12:41:11 -0400 Message-ID: <50896BA0.9000400@siemens.com> Date: Thu, 25 Oct 2012 18:41:04 +0200 From: Jan Kiszka 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> In-Reply-To: <5089679C.9000405@redhat.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: Avi Kivity Cc: Liu Ping Fan , Stefan Hajnoczi , Marcelo Tosatti , "qemu-devel@nongnu.org" , liu ping fan , Anthony Liguori , Paolo Bonzini 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. But that creates ABBA risks. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux