From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:51800)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1TRQEB-0001bs-Pm
	for qemu-devel@nongnu.org; Thu, 25 Oct 2012 12:24:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1TRQE3-0002Yw-3X
	for qemu-devel@nongnu.org; Thu, 25 Oct 2012 12:24:15 -0400
Received: from mx1.redhat.com ([209.132.183.28]:44960)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1TRQE2-0002Yc-Sq
	for qemu-devel@nongnu.org; Thu, 25 Oct 2012 12:24:07 -0400
Message-ID: <5089679C.9000405@redhat.com>
Date: Thu, 25 Oct 2012 18:23:56 +0200
From: Avi Kivity <avi@redhat.com>
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>
	<CAJnKYQ=5Bs1Ckzsps_M1wHNDL_S_u2xqOhjGuSH+a5L+2Gd6UQ@mail.gmail.com>
	<50893FD4.3080102@siemens.com>
In-Reply-To: <50893FD4.3080102@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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Liu Ping Fan <pingfank@linux.vnet.ibm.com>, Stefan Hajnoczi <stefanha@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, liu ping fan <qemulist@gmail.com>, Anthony Liguori <anthony@codemonkey.ws>, Paolo Bonzini <pbonzini@redhat.com>

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.

-- 
error compiling committee.c: too many arguments to function