From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: plan for device assignment upstream Date: Wed, 04 Jul 2012 14:24:45 +0300 Message-ID: <4FF427FD.1010804@redhat.com> References: <20120702091813.GF8268@redhat.com> <4FF16A21.7050309@siemens.com> <4FF16D54.3020801@redhat.com> <20120704104224.GA21704@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , Marcelo Tosatti , kvm , Michael Tokarev , "qemu-devel@nongnu.org" To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:9083 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751495Ab2GDLY4 (ORCPT ); Wed, 4 Jul 2012 07:24:56 -0400 In-Reply-To: <20120704104224.GA21704@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/04/2012 01:42 PM, Michael S. Tsirkin wrote: > On Mon, Jul 02, 2012 at 12:43:48PM +0300, Avi Kivity wrote: >> On 07/02/2012 12:30 PM, Jan Kiszka wrote: >> > On 2012-07-02 11:18, Michael S. Tsirkin wrote: >> >> I've been thinking hard about Jan's patches for device >> >> assignment. Basically while I thought it makes sense >> >> to make all devices: assignment and not - behave the >> >> same and use same APIs for injecting irqs, Anthony thinks there is huge >> >> value in making irq propagation hierarchical and device assignment >> >> should be special cased. >> > >> > On the long term, we will need direct injection, ie. caching, to allow >> > making it lock-less. Stepping through all intermediate layers will cause >> > troubles, at least performance-wise, when having to take and drop a lock >> > at each stop. >> >> So we precalculate everything beforehand. Instead of each qemu_irq >> triggering a callback, calculating the next hop and firing the next >> qemu_irq, configure each qemu_irq array with a function that describes >> how to take the next hop. Whenever the configuration changes, >> recalculate all routes. >> >> For device assignment or vhost, we can have a qemu_irq_irqfd() which >> converts a qemu_irq to an eventfd. If the route calculations determine >> that it can be serviced via a real irqfd, they also configure it as an >> irqfd. Otherwise qemu configures a poll on this eventfd and calls the >> callback when needed. > > This is more or less what I had in mind and what Anthony objects to. Can you post an interface that supports this? Then we can see exactly what is objectionable. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmNhZ-0004Oc-AH for qemu-devel@nongnu.org; Wed, 04 Jul 2012 07:25:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmNhT-000800-24 for qemu-devel@nongnu.org; Wed, 04 Jul 2012 07:24:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmNhS-0007zs-QB for qemu-devel@nongnu.org; Wed, 04 Jul 2012 07:24:50 -0400 Message-ID: <4FF427FD.1010804@redhat.com> Date: Wed, 04 Jul 2012 14:24:45 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20120702091813.GF8268@redhat.com> <4FF16A21.7050309@siemens.com> <4FF16D54.3020801@redhat.com> <20120704104224.GA21704@redhat.com> In-Reply-To: <20120704104224.GA21704@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] plan for device assignment upstream List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Jan Kiszka , Marcelo Tosatti , Michael Tokarev , "qemu-devel@nongnu.org" , kvm On 07/04/2012 01:42 PM, Michael S. Tsirkin wrote: > On Mon, Jul 02, 2012 at 12:43:48PM +0300, Avi Kivity wrote: >> On 07/02/2012 12:30 PM, Jan Kiszka wrote: >> > On 2012-07-02 11:18, Michael S. Tsirkin wrote: >> >> I've been thinking hard about Jan's patches for device >> >> assignment. Basically while I thought it makes sense >> >> to make all devices: assignment and not - behave the >> >> same and use same APIs for injecting irqs, Anthony thinks there is huge >> >> value in making irq propagation hierarchical and device assignment >> >> should be special cased. >> > >> > On the long term, we will need direct injection, ie. caching, to allow >> > making it lock-less. Stepping through all intermediate layers will cause >> > troubles, at least performance-wise, when having to take and drop a lock >> > at each stop. >> >> So we precalculate everything beforehand. Instead of each qemu_irq >> triggering a callback, calculating the next hop and firing the next >> qemu_irq, configure each qemu_irq array with a function that describes >> how to take the next hop. Whenever the configuration changes, >> recalculate all routes. >> >> For device assignment or vhost, we can have a qemu_irq_irqfd() which >> converts a qemu_irq to an eventfd. If the route calculations determine >> that it can be serviced via a real irqfd, they also configure it as an >> irqfd. Otherwise qemu configures a poll on this eventfd and calls the >> callback when needed. > > This is more or less what I had in mind and what Anthony objects to. Can you post an interface that supports this? Then we can see exactly what is objectionable. -- error compiling committee.c: too many arguments to function